Hi,
MINA 2.0 is pushing the inclusion of specific protocol codecs into the core:
I am specifically referring to the filter-codec-http module.
Who decided on this policy and why? Trustin, according to SVN logs you
commit this and it seems as though some of it was extracted from or overlaps
the asy
Trustin Lee wrote:
BTW providing AHC as a subproject might be a good idea - for now it's
included as a MINA submodule, but we can provide it as a separate
subproject. I'd like to know what Jeff thinks about it.
+1...I like the idea of it being a sub project ;-)
Trustin
On Jan 21, 2008 3
With the discussion of Dave (the original author of AsyncWeb), we
agreed to include the HTTP message model and codec into MINA, and make
AsyncWeb focus on more high-level features like session management and
proper error handling that turn a mere codec into a real world web
server component. It's
Trustin,
On Jan 21, 2008 2:07 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> With the discussion of Dave (the original author of AsyncWeb), we
> agreed to include the HTTP message model and codec into MINA, and make
> AsyncWeb focus on more high-level features like session management and
> proper e
On Jan 21, 2008 1:07 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> And, I personally think providing the codecs for essential protocols
> such as HTTP, FTP and SMTP as a part of the main MINA distribution
> makes a developer's life much easier when what he wants is just a
> minimal client / server.
Hi Timothy !
Timothy Bennett wrote:
On Jan 21, 2008 1:07 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
And, I personally think providing the codecs for essential protocols
such as HTTP, FTP and SMTP as a part of the main MINA distribution
makes a developer's life much easier when what he want
Actually I think as with FTPServer the people on the Asyncweb project should
also be on the PMC to have binding votes. Or else they cannot vote to
release etc.
Alex
On Jan 21, 2008 2:33 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi Timothy !
>
> > Timothy Bennett wrote:
> >
> > On Jan 2
This was a bit unclear. When you bring in a project through incubation or
through an IP clearance as we have done the communities are merged into the
PMC. Hence the reason why the committers are absorbed in one shot.
Alex
On Jan 21, 2008 2:36 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> Actu
Alex,
Dave is already a PMC member. We could invite Dan and Timothy.
Should the invitation as easy as modification of the authorization
file and sending a message to the board, because we forgot to invite
them to the PMC when we import AsyncWeb?
PS: Of course we need to add them to the committer
Sounds good to me thanks Trustin.
Alex
On Jan 21, 2008 2:47 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Alex,
>
> Dave is already a PMC member. We could invite Dan and Timothy.
> Should the invitation as easy as modification of the authorization
> file and sending a message to the board, becau
Okay. Then it's time for restructuring. (Excited :) We have
ftpserver, AHC and Asyncweb. FtpServer and AsyncWeb are under
sandbox, but I think FtpServer is mature enough to bring it up to the
subproject right away because Niklas G is working on the project and
Niclas Hedman told me it's pretty m
Trustin Lee wrote:
Okay. Then it's time for restructuring. (Excited :) We have
ftpserver, AHC and Asyncweb. FtpServer and AsyncWeb are under
sandbox, but I think FtpServer is mature enough to bring it up to the
subproject right away because Niklas G is working on the project and
Niclas Hedman
On Jan 21, 2008 5:03 PM, Niklas Therning <[EMAIL PROTECTED]> wrote:
> Trustin Lee wrote:
> > Okay. Then it's time for restructuring. (Excited :) We have
> > ftpserver, AHC and Asyncweb. FtpServer and AsyncWeb are under
> > sandbox, but I think FtpServer is mature enough to bring it up to the
> >
Hi !
Niklas Therning wrote:
Trustin Lee wrote:
Okay. Then it's time for restructuring. (Excited :) We have
ftpserver, AHC and Asyncweb. FtpServer and AsyncWeb are under
sandbox, but I think FtpServer is mature enough to bring it up to the
subproject right away because Niklas G is working on
On Jan 21, 2008 6:39 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> and I also think it's time to get asyncweb out of sandbox. Sandbox is
> supposed to be a place where we do experiments, or personal stuff. If
> Alex wants to work on asyncweb, it may be time to 'wake up' the project
> and pu
It makes sense I think! Would we still keep codec implementations in
subprojects under mina/ (like filter-codec-http)?
I think that each codec should have its own sub-project, with its own
versioning scheme. There is no reason why it should depend on MINA in
any way, except through a dep
I agree with some points Emmanuel made, but it doesn't mean that I
totally agree with him for all points he made such as versioning,
similarity between LDAP and HTTP, and HTTP-ish codec.
However, I don't want to drag this thread spending each other's energy
unnecessarily replying to every sentence
Trustin Lee wrote:
I agree with some points Emmanuel made, but it doesn't mean that I
totally agree with him for all points he made such as versioning,
similarity between LDAP and HTTP, and HTTP-ish codec.
However, I don't want to drag this thread spending each other's energy
unnecessarily reply
On Jan 20, 2008, at 11:42 PM, Trustin Lee wrote:
So... I'd like to suggest the following directory structure:
/ - mina - trunk
- tags
- branches
- ahc - trunk
- tags
- branches
- ftpserver - trunk
- tags
- branches
Does it make sense, or
peter royal wrote:
i propose something different..
/mina/(trunk|tags|branches) - core, examples, transports, statematchine
/http/(trunk|tags|branches) - filter-codec-http, protocol-http-client,
asyncweb
/ftp/(trunk|tags|branches) - ftpserver (and a separate codec if its
desired to fra
+1.
Peter, thanks for this calm and sane proposal.
a few key points:
* no protocols in the "core" (/mina)
* generic filters only in the "core"
* organize based on "functional area" .. i think having /codecs/ is
wrong, its too broad. if we get a bunch of mail-related code, we can
create /
I missed the first +1. :)
Trustin
On Jan 22, 2008 3:50 AM, David M. Lloyd <[EMAIL PROTECTED]> wrote:
> peter royal wrote:
> > i propose something different..
> >
> > /mina/(trunk|tags|branches) - core, examples, transports, statematchine
> >
> > /http/(trunk|tags|branches) - filter-codec-htt
+1 this is great presuming:
[repeatinig what was already said a bit on IRC for the list]
(1) this independent true are for the various MINA TLP sub-projects
(2) if protocol projects their codecs are contained in the same tree
(3) releases of these projects can occur independently of MINA releases
peter royal wrote:
i propose something different..
/mina/(trunk|tags|branches) - core, examples, transports, statematchine
/http/(trunk|tags|branches) - filter-codec-http, protocol-http-client,
asyncweb
/ftp/(trunk|tags|branches) - ftpserver (and a separate codec if its
desired to fragme
Niklas Therning wrote:
It makes sense I think! Would we still keep codec implementations in
subprojects under mina/ (like filter-codec-http)? I think that's a nice
separation. It would be great if the codec parts of ftpserver could be
separated from its use in ftpserver and become filter-codec-
+1 for Peter's proposal
and +1 for staying calm and peaceful :-)
But what about
org.apache.mina.filter.codec.serialization
org.apache.mina.filter.codec.textline
org.apache.mina.filter.codec.prefixedstring
I hope that they can stay where they are now ?
Since they're very basic and not the impleme
On Jan 22, 2008 7:40 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> +1 for Peter's proposal
>
> and +1 for staying calm and peaceful :-)
>
> But what about
> org.apache.mina.filter.codec.serialization
> org.apache.mina.filter.codec.textline
> org.apache.mina.filter.codec.prefixedstring
>
> I hop
Niklas Gustavsson wrote:
Niklas Therning wrote:
It makes sense I think! Would we still keep codec implementations in
subprojects under mina/ (like filter-codec-http)? I think that's a
nice separation. It would be great if the codec parts of ftpserver
could be separated from its use in ftpserve
Niklas,
Are these codecs that you mention (POP3, SMTP, IMAP) publicly available
right now?
Thanks
On Jan 21, 2008 3:03 AM, Niklas Therning <[EMAIL PROTECTED]> wrote:
> Trustin Lee wrote:
> > Okay. Then it's time for restructuring. (Excited :) We have
> > ftpserver, AHC and Asyncweb. FtpServ
Mark wrote:
Niklas,
Are these codecs that you mention (POP3, SMTP, IMAP) publicly available
right now?
Thanks
Hi Mark,
No they are not publicly available at the moment. As I mention below
there are some MINA based open source projects I'm aware of which
implement SMTP and POP3. Maybe th
e.org
Envoyé le : Mardi, 22 Janvier 2008, 18h15mn 40s
Objet : Re: Directory restructuring (Re: [Asyncweb] Motives behind
filter-codec-http and asyncweb)
Mark
wrote:
>
Niklas,
>
>
Are
these
codecs
that
you
mention
(POP3,
SMTP,
IMAP)
publicly
available
>
right
now?
>
>
Than
Thanks for the information...
On Jan 22, 2008 12:15 PM, Niklas Therning <[EMAIL PROTECTED]> wrote:
> Mark wrote:
> > Niklas,
> >
> > Are these codecs that you mention (POP3, SMTP, IMAP) publicly available
> > right now?
> >
> > Thanks
> >
>
> Hi Mark,
>
> No they are not publicly available at the
y developping, which contains
> it's own nio POP3
> server based on MINA (POP3 code has been designed to be very loosely
> coupled with the main app).
>
> Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
>
> - Message d'origin
Alex and all,
I understand and respect your concern about MINA project as a PMC
member of the project.
We had to have discussed about these issues earlier. Late is better
than never, so let me clarify something.
* We should not force any subprojects to strip any existing server
down to a protoc
Trustin,
I wished you just left this thread alone. I don't want to stir anything up
so I will just point out the facts.
I'm being diligent as a concerned ASF member and part of the MINA PMC. MINA
has a young PMC that barely understands the rules. Some are missing. 90%
of the code/commits were
Alex,
Comments inline...
On Jan 22, 2008 4:44 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>
> I'm being diligent as a concerned ASF member and part of the MINA PMC. MINA
> has a young PMC that barely understands the rules. Some are missing. 90%
> of the code/commits were from you in the past
>> You're displeasure in hearing my assumptions is not my problem.
>>
>
> Let me correct here. It is other less-involved community members'
> displeasure as well as my displeasure.
So, wtf ? People pleasure or displeasure is not a measurement for
success nor for correctness. What is important
Hi,
Before we proceed with the agreed new directory structure, we need to
decide what groupId and artifactId each components should have. It's
pretty evident for existing mina-* artifact (except for HTTP stuff),
but It's somewhat unclear for ftp and http directory.
1) Should all three's groupId
38 matches
Mail list logo