You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2008/01/21 08:42:18 UTC
Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
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 mature project.
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 would you suggest better structure?
Also we could give some nicer name to AHC. What about Superluminal?
(http://en.wikipedia.org/wiki/Faster-than-light)
Cheers,
Trustin
On Jan 21, 2008 4:13 PM, Jeff Genender <jg...@apache.org> wrote:
>
>
> 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:05 AM, Alex Karasulu <ak...@apache.org> wrote:
> >> 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 asycweb functionality.
> >>
> >> What is the intention for asyncweb as a subproject if it's functionality is
> >> being moved over to MINA core?
> >>
> >> Thanks,
> >> Alex
> >>
> >
> >
> >
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Alex Karasulu <ak...@apache.org>.
+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
This means we're going to have to do some work on the site to make it
accommodate multiple subprojects but we can get to that in due course.
I can start working on moving over the Asyncweb site as well as refactoring
it and cleaning up in there.
Thanks,
Alex
On Jan 21, 2008 2:04 PM, Trustin Lee <tr...@gmail.com> wrote:
> I missed the first +1. :)
>
> Trustin
>
> On Jan 22, 2008 3:50 AM, David M. Lloyd <da...@redhat.com> wrote:
> > 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 fragment it some
> >
> > I like this one the best, so for what it's worth, +1 from me.
> >
> > - DML
> >
>
>
>
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Niklas Gustavsson <ni...@protocol7.com>.
> 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 fragment it some
This one makes perfect sense to me. +1. I would not like having parts of
FtpServer in two different versioning (trunk/tags) structures.
/niklas
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Trustin Lee <tr...@gmail.com>.
I missed the first +1. :)
Trustin
On Jan 22, 2008 3:50 AM, David M. Lloyd <da...@redhat.com> wrote:
> 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 fragment it some
>
> I like this one the best, so for what it's worth, +1 from me.
>
> - DML
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by "David M. Lloyd" <da...@redhat.com>.
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 fragment it some
I like this one the best, so for what it's worth, +1 from me.
- DML
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Emmanuel Lecharny <el...@gmail.com>.
+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 /mail, and put them all in there.
> * i agree that HTTP code does not belong in the core, and that
> asyncweb should not be languishing in the sandbox.
>
> -pete
>
>
> --proyal@apache.org - http://fotap.org/~osi
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by peter royal <pr...@apache.org>.
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 would you suggest better structure?
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 fragment it some
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 /mail, and put them all in there.
* i agree that HTTP code does not belong in the core, and that
asyncweb should not be languishing in the sandbox.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 replying to every sentence.
The thing is that the point we don't agree on are to be clarified,
because they are important. May be another thread would be good.
> What we really want to see
> is the best scalable directory layout that will last for another
> century. So, let me try again to restructure the directory layout
> from most reasonable and orthogonal point of view. ;)
>
> What a usual protocol codec (including HTTP codec) currently depends on is:
>
> * MINA IoBuffer
> * MINA IoSession (to access properties, not to perform a real I/O operation)
> * MINA codec infra
>
> IIRC, we discussed about providing a separate artifact for buffer
> utilities and codec infrastructure, but users didn't like to have
> extra JARs in their classpath. From this point of view, MINA is
> actually a mix of codec infra and network framework. So... we have
> two different things in one core, and that's the root cause of all
> these problems.
>
> Therefore, it seems like there's some chasm between what's most
> reasonable and what users feel most comfortable with. I'm not sure
> what will be the best choice for us. Anyways, the most reasonable
> layout will look like this then:
>
> / - core - codec-framework (name tbd, IoBuffer + existing codec infra)
> - mina (pure network framework, shall we rename? :)
>
well, "mina" is ok as a name for the core.
> - codec - HTTP codec (all depends on codec-framework only)
> - FTP codec
> - SMTP codec
> - frontend - ahc (name tbd, my preference - Superluminal)
>
"superluminal" is a little bit too long, and considering that nothing
can exceed light speed ... Do we have to find acronym for every project?
Is this just me ? Is everyone confortable with the idea of using an
HashMap to remember the relation between a obscure acronym and a project
? (cayenne, felix, james, lenya, geronimo, gump, santuario, shale,
tiles...)
> - ftpserver (name tbd if Niklas wants something cool :D)
> - asyncweb (if Alex wants to work on it)
>
This sounds ok to me, assuming that each codec has its own version and
jar. There is nothing wrong to have a codec top level pom.xml, pointing
on each codec project, as soon as one can compile and package a specific
codec easily.
> It's somewhat complicated, but it's most scalable layout IMHO. Does
> it look much better guys?
It does.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Trustin Lee <tr...@gmail.com>.
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. What we really want to see
is the best scalable directory layout that will last for another
century. So, let me try again to restructure the directory layout
from most reasonable and orthogonal point of view. ;)
What a usual protocol codec (including HTTP codec) currently depends on is:
* MINA IoBuffer
* MINA IoSession (to access properties, not to perform a real I/O operation)
* MINA codec infra
IIRC, we discussed about providing a separate artifact for buffer
utilities and codec infrastructure, but users didn't like to have
extra JARs in their classpath. From this point of view, MINA is
actually a mix of codec infra and network framework. So... we have
two different things in one core, and that's the root cause of all
these problems.
Therefore, it seems like there's some chasm between what's most
reasonable and what users feel most comfortable with. I'm not sure
what will be the best choice for us. Anyways, the most reasonable
layout will look like this then:
/ - core - codec-framework (name tbd, IoBuffer + existing codec infra)
- mina (pure network framework, shall we rename? :)
- codec - HTTP codec (all depends on codec-framework only)
- FTP codec
- SMTP codec
- frontend - ahc (name tbd, my preference - Superluminal)
- ftpserver (name tbd if Niklas wants something cool :D)
- asyncweb (if Alex wants to work on it)
It's somewhat complicated, but it's most scalable layout IMHO. Does
it look much better guys? If everyone is fine with this big
refactoring, I am ready to make it happen by myself, and I want to
make it happen before we release 2.0.0-M1.
If you think it's a nice layout, please allow me to give my favorite
name to the codec framework. ;)
Cheers,
Trustin
PS: BTW, should we rename IoBuffer again? I'd like to avoid that even
if we are going to create a separate subproject for implementing a
protocol codec.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Emmanuel Lecharny <el...@gmail.com>.
>>> 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 dependency.
>>
>> This is a dangerous approach which will be a real problem when
>> protocol's codecs will flourish, as you will have difficult time
>> synchronizing all of them when you will want to release a new MINA version.
>>
>
> We have only one codec (or two including Netty? :) so far and didn't
> experience any problem yet.
Should we have to wait until we get hit by a problem to fix it ?
> I'd rather wait and see more codecs to
> appear before we say that it will be a real problem. It doesn't hurt
> anyone. :)
>
That's not a good position, IMHO. This is likely to become a problem,
but more than that, it is clear that having the HTTP codec with MINA
code is wrong, from the 'separation of concern' POV. MINA is a network
framework, HTTP is a protocol which can be built on top on a framework.
I see no point for HTTP to be part of a network framework.
>> Codecs should be seen as plugins, and should have there own life, and
>> own versioning scheme.
>>
>> Does it make sense to you, guys ?
>>
>
> Then what about other submodules like filter-compression,
> integration-*, statemachine and transport-*?
filter-compression, etc are not codecs for which you have existing RFCs.
Http does. That's why it's really different. But anyway, at some point,
yes, those filters might be seen as separated projects.
> Should they all be
> thought as plugins in the same context? Some components doesn't
> change a line when we cut a new release. What makes codecs so
> special?
Because they are in no way linked to MINA, whatsoever. They have their
own separate life, and cycle. They make them totally different
components. What if LDAP protocol codec was a part of MINA ? HTTP codec
is exactly the same kind of codec than LDAP codec is, and deserves to be
put in a different project.
That it's under MINA hat is a different question.
> I see codecs as submodules that deeply depends on MINA
> constructs like other submodules does.
>
I don't share this vision. It's the way it's implemented atm which make
you think they are part of mina. Again, LDAP codec is not implemented
this way, and it works pretty fine, so far...
> A protocol implementation consists of a codec, message flow and
> business logic. A codec itself can't do anything at all. Codecs are
> very low-level component - you need something more on top of it to
> comply with the protocol, and that's why I think it should be a
> submodule of MINA distribution.
A codec does a lot : it encodes and decode the messages. And I don't
think that :
if (query != null && query.length() > 0) {
buf.put((byte) '?');
buf.putString(query, asciiEncoder);
}
buf.putString(" HTTP/1.1", asciiEncoder);
as nothing to do in MINA. It's so HTTP-ish...
> Those only who understand how to use
> MINA API can use the codec.
That does not imply codecs should be part of MINA.
> What's the use of providing it as a
> separate distribution?
I think I already replied to this question : because protocol's cycles
are different from MINA cycle. And a codec should be linked to a version
of MINA, not the opposite. It should be possible to modify a codec
without changing the MINA version used, when the opposite is clearly
more complex. What will we do if we change MINA and we have to change N
versions of codecs just because MINA's API has been changed ? You have
no idea of the impact of such modifications can have on projects which
uses the codecs, when the codec's implementors know what they are doing
when switching the underlying MINA layer. Remember that it's what we are
doing for ADS for years right now : we decide when and why we should
switch from MINA x to MINA y.
> What's more important IMHO is whether we are
> going to provide the codec as a separate JAR file or not, and we are
> doing so already.
>
It's not only about the jar, it's about the version.
HTTP != MINA, as LDAP != MINA. It would hurt to depend on MINA to be
able to release ADS, and it would hurt AsyncWeb to depend on MINA to
release a version too. Working with snapshots is not the way to go, and
it is the clear path we are taking if we keep codecs within mina. That's
why I do think that they deserves to be considered as sub-projects.
And it's not complex at all, as the codec is already a separated
project. It's just a question to separate it from MINA trunk.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Trustin Lee <tr...@gmail.com>.
On Jan 21, 2008 6:39 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
<snip/>
> 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 put it back to trunk.
Absolutely, if he wants to start to work on AsyncWeb.
> > 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 dependency.
>
> This is a dangerous approach which will be a real problem when
> protocol's codecs will flourish, as you will have difficult time
> synchronizing all of them when you will want to release a new MINA version.
We have only one codec (or two including Netty? :) so far and didn't
experience any problem yet. I'd rather wait and see more codecs to
appear before we say that it will be a real problem. It doesn't hurt
anyone. :)
> > I think it would be very cool if MINA could be a repository for codec
> > implementations like this and I think that has been your intention
> > from the very start Trustin, right? We (Trillian AB) would be willing
> > to contribute initial (and in some areas incomplete) codec
> > implementations for POP3, SMTP and IMAP. I know there are others out
> > there using MINA for various types of mail servers and clients.
> > Together we could build complete and very usable implementations for
> > these protocols.
>
> Codecs should be seen as plugins, and should have there own life, and
> own versioning scheme.
>
> Does it make sense to you, guys ?
Then what about other submodules like filter-compression,
integration-*, statemachine and transport-*? Should they all be
thought as plugins in the same context? Some components doesn't
change a line when we cut a new release. What makes codecs so
special? I see codecs as submodules that deeply depends on MINA
constructs like other submodules does.
A protocol implementation consists of a codec, message flow and
business logic. A codec itself can't do anything at all. Codecs are
very low-level component - you need something more on top of it to
comply with the protocol, and that's why I think it should be a
submodule of MINA distribution. Those only who understand how to use
MINA API can use the codec. What's the use of providing it as a
separate distribution? What's more important IMHO is whether we are
going to provide the codec as a separate JAR file or not, and we are
doing so already.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 the project and
>> Niclas Hedman told me it's pretty mature project.
>>
>> 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 would you suggest better structure?
I would add some more subprojects :
- http-codec
- tags
- branches
- trunk
(any codec as well)
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 put it back to trunk.
> 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 dependency.
This is a dangerous approach which will be a real problem when
protocol's codecs will flourish, as you will have difficult time
synchronizing all of them when you will want to release a new MINA version.
> 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-ftp. Is that doable?
Sure !
>
> I think it would be very cool if MINA could be a repository for codec
> implementations like this and I think that has been your intention
> from the very start Trustin, right? We (Trillian AB) would be willing
> to contribute initial (and in some areas incomplete) codec
> implementations for POP3, SMTP and IMAP. I know there are others out
> there using MINA for various types of mail servers and clients.
> Together we could build complete and very usable implementations for
> these protocols.
Codecs should be seen as plugins, and should have there own life, and
own versioning scheme.
Does it make sense to you, guys ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Trustin Lee <tr...@gmail.com>.
On Jan 21, 2008 5:03 PM, Niklas Therning <ni...@trillian.se> 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 the project and
> > Niclas Hedman told me it's pretty mature project.
> >
> > 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 would you suggest better structure?
> >
>
> 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-ftp. Is that
> doable?
Probably Niklas G could answer your question. My idea is that we can
do that somehow because it's technically not difficult in theory :)
> I think it would be very cool if MINA could be a repository for codec
> implementations like this and I think that has been your intention from
> the very start Trustin, right? We (Trillian AB) would be willing to
> contribute initial (and in some areas incomplete) codec implementations
> for POP3, SMTP and IMAP. I know there are others out there using MINA
> for various types of mail servers and clients. Together we could build
> complete and very usable implementations for these protocols.
That's really a nice idea, Niklas. :) I think POP3 and SMTP will be
very useful. Regarding IMAP, I'm not sure though. What would be a
generic use case for IMAP other than just providing access to mail
boxes?
> > Also we could give some nicer name to AHC. What about Superluminal?
> > (http://en.wikipedia.org/wiki/Faster-than-light)
> >
> I like that name! Of course we would have to live up to it as well! :-)
Otherwise we will have to change the project name eventually due to
enormous requests from users. :D
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Niklas Therning <ni...@trillian.se>.
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 ftpserver and become
>> filter-codec-ftp. Is that doable?
>
>
> Yes, that would most certainly be doable. However, not incredibly
> useful I'm afraid. FTP commands are very simplistic when compared to,
> for example, HTTP. For example, there is nothing like HTTP headers in
> FTP commands, only the command and an argument. For example:
> STOR myfile.txt
>
> That being said, if you still would like a separate FTP codec I'll
> have a go at doing the coding :-)
>
> /niklas
>
Well, I see your point and I totally agree that it wouldn't be very
useful to do this with the FTP stuff. My main concern was to simplify
for users to integrate HTTP/FTP/whatever functionality into their apps.
But it seems like just having the codec won't be very useful. I guess it
would make more sense to make sure ftpserver, AsyncWeb, etc are easily
embeddable. AsyncWeb in particular (e.g. admin interface, web service
interface). Maybe they already are?
/Niklas (T)
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Trustin Lee <tr...@gmail.com>.
On Jan 22, 2008 7:40 AM, Maarten Bosteels <mb...@gmail.com> 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 hope that they can stay where they are now ?
> Since they're very basic and not the implementation of some RFC etc
Sure we will let them stay there. :)
Love and peace? :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Maarten Bosteels <mb...@gmail.com>.
+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 implementation of some RFC etc
Maarten
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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-ftp. Is that
> doable?
Yes, that would most certainly be doable. However, not incredibly useful
I'm afraid. FTP commands are very simplistic when compared to, for
example, HTTP. For example, there is nothing like HTTP headers in FTP
commands, only the command and an argument. For example:
STOR myfile.txt
That being said, if you still would like a separate FTP codec I'll have
a go at doing the coding :-)
/niklas
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Mark <el...@gmail.com>.
Thanks for the information...
On Jan 22, 2008 12:15 PM, Niklas Therning <ni...@trillian.se> 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 moment. As I mention below
> there are some MINA based open source projects I'm aware of which
> implement SMTP and POP3. Maybe they can provide what you are looking for?
>
> If you're looking for SMTP you could have a look at SubEthaSMTP,
> http://subethasmtp.tigris.org/. They have a MINA codec for SMTP commands
> based on MINA's text codec. Also, HausMail,
> http://hausmail.safehaus.org/, has code to decode POP3 and SMTP
> commands. HausMail doesn't seem to use ProtocolCodecFilter but rather a
> custom decoder filter.
>
> HTH
>
> /Niklas
>
> >
> > On Jan 21, 2008 3:03 AM, Niklas Therning <ni...@trillian.se> 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 the project and
> >>> Niclas Hedman told me it's pretty mature project.
> >>>
> >>> 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 would you suggest better structure?
> >>>
> >>>
> >> 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-ftp. Is
> that
> >> doable?
> >>
> >> I think it would be very cool if MINA could be a repository for codec
> >> implementations like this and I think that has been your intention from
> >> the very start Trustin, right? We (Trillian AB) would be willing to
> >> contribute initial (and in some areas incomplete) codec implementations
> >> for POP3, SMTP and IMAP. I know there are others out there using MINA
> >> for various types of mail servers and clients. Together we could build
> >> complete and very usable implementations for these protocols.
> >>
> >>
> >>> Also we could give some nicer name to AHC. What about Superluminal?
> >>> (http://en.wikipedia.org/wiki/Faster-than-light)
> >>>
> >>>
> >> I like that name! Of course we would have to live up to it as well! :-)
> >>
> >> /Niklas
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> Niklas Therning
> www.spamdrain.net
>
--
--------------------------------
Talent hits a target no one else can hit; Genius hits a target no one else
can see.
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Niklas Therning <ni...@trillian.se>.
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 they can provide what you are looking for?
If you're looking for SMTP you could have a look at SubEthaSMTP,
http://subethasmtp.tigris.org/. They have a MINA codec for SMTP commands
based on MINA's text codec. Also, HausMail,
http://hausmail.safehaus.org/, has code to decode POP3 and SMTP
commands. HausMail doesn't seem to use ProtocolCodecFilter but rather a
custom decoder filter.
HTH
/Niklas
>
> On Jan 21, 2008 3:03 AM, Niklas Therning <ni...@trillian.se> 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 the project and
>>> Niclas Hedman told me it's pretty mature project.
>>>
>>> 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 would you suggest better structure?
>>>
>>>
>> 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-ftp. Is that
>> doable?
>>
>> I think it would be very cool if MINA could be a repository for codec
>> implementations like this and I think that has been your intention from
>> the very start Trustin, right? We (Trillian AB) would be willing to
>> contribute initial (and in some areas incomplete) codec implementations
>> for POP3, SMTP and IMAP. I know there are others out there using MINA
>> for various types of mail servers and clients. Together we could build
>> complete and very usable implementations for these protocols.
>>
>>
>>> Also we could give some nicer name to AHC. What about Superluminal?
>>> (http://en.wikipedia.org/wiki/Faster-than-light)
>>>
>>>
>> I like that name! Of course we would have to live up to it as well! :-)
>>
>> /Niklas
>>
>>
>>
>
>
>
--
Niklas Therning
www.spamdrain.net
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Posted by Mark <el...@gmail.com>.
Niklas,
Are these codecs that you mention (POP3, SMTP, IMAP) publicly available
right now?
Thanks
On Jan 21, 2008 3:03 AM, Niklas Therning <ni...@trillian.se> 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 the project and
> > Niclas Hedman told me it's pretty mature project.
> >
> > 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 would you suggest better structure?
> >
>
> 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-ftp. Is that
> doable?
>
> I think it would be very cool if MINA could be a repository for codec
> implementations like this and I think that has been your intention from
> the very start Trustin, right? We (Trillian AB) would be willing to
> contribute initial (and in some areas incomplete) codec implementations
> for POP3, SMTP and IMAP. I know there are others out there using MINA
> for various types of mail servers and clients. Together we could build
> complete and very usable implementations for these protocols.
>
> > Also we could give some nicer name to AHC. What about Superluminal?
> > (http://en.wikipedia.org/wiki/Faster-than-light)
> >
> I like that name! Of course we would have to live up to it as well! :-)
>
> /Niklas
>
>
--
--------------------------------
Talent hits a target no one else can hit; Genius hits a target no one else
can see.
Re: Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http
and asyncweb)
Posted by Niklas Therning <ni...@trillian.se>.
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 told me it's pretty mature project.
>
> 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 would you suggest better structure?
>
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-ftp. Is that
doable?
I think it would be very cool if MINA could be a repository for codec
implementations like this and I think that has been your intention from
the very start Trustin, right? We (Trillian AB) would be willing to
contribute initial (and in some areas incomplete) codec implementations
for POP3, SMTP and IMAP. I know there are others out there using MINA
for various types of mail servers and clients. Together we could build
complete and very usable implementations for these protocols.
> Also we could give some nicer name to AHC. What about Superluminal?
> (http://en.wikipedia.org/wiki/Faster-than-light)
>
I like that name! Of course we would have to live up to it as well! :-)
/Niklas