You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Darrell DeBoer <da...@apache.org> on 2002/11/11 06:04:10 UTC
Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
G'day,
I thought I'd better (re)introduce myself, as I've been inactive in James
since February or so, and there seem to be a few new names around (which is
fantastic). I'm currently looking for work in Brisbane, Australia, and given
the state of the job market I might have a fair bit of time for open-source
coding coming up.
I started working on James mid-last-year, when I contributed some patches to
the UsersRepository; I then helped to make database storage simpler by using
direct JDBC with the SQL defined in a single resource file
(sqlResources.xml).
Around Christmas last year, I did a big bunch of refactoring on the IMAP
proposal, as I continually swayed between rewriting it from scratch and
working with what was there. I ripped up some HUUUUGE classes and pulled the
code for handling individual commands into separate classes. At the same
time, I setup a file-based testing framework for protocol testing, which is
very similar to (but not as nice as) what Harmeet has recently added as the
ProtocolSimulator. I haven't had a chance to look closely at the changes that
have been made since I dropped off the radar, but will do shortly.
I'm ashamed to admit that I was the cause of that horrible hard-coded
"daz2000" reference that was removed recently from one of the source files.
Obviously committed that without proper perusal.
I plan to do a bit more work on the IMAP proposal in the next few months. How
much work, I can't be sure, and please feel free to help out, with
contributions to code, constructive criticism, or flame mail ;).
ciao,
Daz
On Mon, 11 Nov 2002 14:44, darrell@apache.org wrote:
> darrell 2002/11/10 20:44:41
>
> Modified: proposals/imap build-test.xml build.xml
> proposals/imap/conf james-assembly.xml james-config.xml
> james-server.xml
> proposals/imap/java/org/apache/james/imapserver
> BaseCommand.java CommandFetch.java FileMailbox.java
> SimpleMessageAttributes.java
> proposals/imap/java/org/apache/james/imapserver/commands
> CommandTemplate.java
> Added: proposals/imap/java/org/apache/james/imapserver
> BaseConnectionHandler.java
> Removed: proposals/imap build-imap.xml
> Log:
> IMAP Proposal updates.
>
> * Synchronized build.xml, james-comfig.xml, james-server.xml and
> james-assembly.xml with latest versions from main tree.
> * Removed build-imap.xml, which duplicated build.xml, and was hopelessly
> out of date.
> * Build now compiles directly from main and proposal source trees,
> rather than first copying source to build/src and then compiling.
> * Added BaseConnectionHandler, recently removed from main tree, into IMAP
> proposal, as it was still used. Need to look at AbstractJamesService,
> which seems to replace this functionality.
> * IMAP proposal now compiles and builds, and starts successfully. Next
> I'll have to try running the tests to see what's actually working.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
>
> May I humbly siggest that you and other developers add some personal
> info about themselves on their homepage?
I worry about privacy.
>From mailing lists one can extract user information and from page extract
personal info. The former is already a problem to some extent.
Just my security paranoia. On the other hand there is no privacy. Either way
privacy issue may be something to keep in mind.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands
CommandTemplate.java)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> I did mine a while back. It contains no more than anyone actually might
> need. ;-)
>
> In Nicola Ken's case, more might be needed. ;-) At least one knows that he
> isn't Nico Laken, from Finland. <<ducking>>
ROTFL!!! :-DDD
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Noel J. Bergman" <no...@devtech.com>.
I did mine a while back. It contains no more than anyone actually might
need. ;-)
In Nicola Ken's case, more might be needed. ;-) At least one knows that he
isn't Nico Laken, from Finland. <<ducking>>
--- Noel
-----Original Message-----
Nicola,
> May I humbly siggest that you and other developers add some personal
> info about themselves on their homepage?
>
> It's because I will probably start linking them from a page that lists
> all Apache committers.
>
> Yours should be http://cvs.apache.org/~darrell/ ;
>
> For example mine is:
> http://cvs.apache.org/~nicolaken/
>
> Log into cvs.apache.org and look in my home dir as a "template" if you
> wish.
>
> Anyway, just a suggestion.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Nicola,
> May I humbly siggest that you and other developers add some personal
> info about themselves on their homepage?
>
> It's because I will probably start linking them from a page that lists
> all Apache committers.
>
> Yours should be http://cvs.apache.org/~darrell/ ;
>
> For example mine is:
> http://cvs.apache.org/~nicolaken/
>
> Log into cvs.apache.org and look in my home dir as a "template" if you
> wish.
>
> Anyway, just a suggestion.
Probably a reasonable idea. I'll throw one together for myself after
2.1.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands
CommandTemplate.java)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Charles Benett wrote:
> Good to see you are back, Darrell.
> Charles
:-)
May I humbly siggest that you and other developers add some personal
info about themselves on their homepage?
It's because I will probably start linking them from a page that lists
all Apache committers.
Yours should be http://cvs.apache.org/~darrell/ ;
For example mine is:
http://cvs.apache.org/~nicolaken/
Log into cvs.apache.org and look in my home dir as a "template" if you wish.
Anyway, just a suggestion.
> Darrell DeBoer wrote:
>
>> G'day,
>>
>> I thought I'd better (re)introduce myself,
[...]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands
CommandTemplate.java)
Posted by Charles Benett <ch...@apache.org>.
Good to see you are back, Darrell.
Charles
Darrell DeBoer wrote:
>G'day,
>
>I thought I'd better (re)introduce myself, as I've been inactive in James
>since February or so, and there seem to be a few new names around (which is
>fantastic). I'm currently looking for work in Brisbane, Australia, and given
>the state of the job market I might have a fair bit of time for open-source
>coding coming up.
>
>I started working on James mid-last-year, when I contributed some patches to
>the UsersRepository; I then helped to make database storage simpler by using
>direct JDBC with the SQL defined in a single resource file
>(sqlResources.xml).
>
>Around Christmas last year, I did a big bunch of refactoring on the IMAP
>proposal, as I continually swayed between rewriting it from scratch and
>working with what was there. I ripped up some HUUUUGE classes and pulled the
>code for handling individual commands into separate classes. At the same
>time, I setup a file-based testing framework for protocol testing, which is
>very similar to (but not as nice as) what Harmeet has recently added as the
>ProtocolSimulator. I haven't had a chance to look closely at the changes that
>have been made since I dropped off the radar, but will do shortly.
>
>I'm ashamed to admit that I was the cause of that horrible hard-coded
>"daz2000" reference that was removed recently from one of the source files.
>Obviously committed that without proper perusal.
>
>I plan to do a bit more work on the IMAP proposal in the next few months. How
>much work, I can't be sure, and please feel free to help out, with
>contributions to code, constructive criticism, or flame mail ;).
>
>ciao,
>Daz
>
>
>On Mon, 11 Nov 2002 14:44, darrell@apache.org wrote:
>
>
>>darrell 2002/11/10 20:44:41
>>
>> Modified: proposals/imap build-test.xml build.xml
>> proposals/imap/conf james-assembly.xml james-config.xml
>> james-server.xml
>> proposals/imap/java/org/apache/james/imapserver
>> BaseCommand.java CommandFetch.java FileMailbox.java
>> SimpleMessageAttributes.java
>> proposals/imap/java/org/apache/james/imapserver/commands
>> CommandTemplate.java
>> Added: proposals/imap/java/org/apache/james/imapserver
>> BaseConnectionHandler.java
>> Removed: proposals/imap build-imap.xml
>> Log:
>> IMAP Proposal updates.
>>
>> * Synchronized build.xml, james-comfig.xml, james-server.xml and
>>james-assembly.xml with latest versions from main tree.
>> * Removed build-imap.xml, which duplicated build.xml, and was hopelessly
>>out of date.
>> * Build now compiles directly from main and proposal source trees,
>> rather than first copying source to build/src and then compiling.
>> * Added BaseConnectionHandler, recently removed from main tree, into IMAP
>> proposal, as it was still used. Need to look at AbstractJamesService,
>>which seems to replace this functionality.
>> * IMAP proposal now compiles and builds, and starts successfully. Next
>>I'll have to try running the tests to see what's actually working.
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Darrell DeBoer <da...@apache.org>.
On Mon, 11 Nov 2002 18:09, Harmeet Bedi wrote:
> ----- Original Message -----
> From: "Darrell DeBoer" <da...@apache.org>
>
> > I plan to do a bit more work on the IMAP proposal in the next few months.
>
> How
>
> > much work, I can't be sure, and please feel free to help out, with
> > contributions to code, constructive criticism, or flame mail ;).
>
> Would it be possible to enumerate what needs to be done to run/test IMAP ?
> What is the current status and how can one help most effectively ?
>
> thanks,
> Harmeet
As Noel suggested, I'm going to need a bit of time before I can answer this.
Basically, I had treated the IMAP proposal as a bit of XP development
practice:- most of the work I did was setting up some tests, and refactoring
existing code.
>From what I recall, there was *heaps* of work required before it would be
fully functional, in particular a complete overhaul of the mail storage,
probably to sit on top of a standard MailRepository implementation.
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
Since Darrell is only just returned, we might want to give him some time to
catchup on changes. There have been several short lived attempts at moving
IMAP forward, which ought to be at least somewhat reflected in the CVS.
But it does sound as if he has started working on the build process, and
other things.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Monday, November 11, 2002 1:09
To: James Developers List
Subject: Re: Introduction (was Re: cvs commit:
jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands
CommandTemplate.java)
----- Original Message -----
From: "Darrell DeBoer" <da...@apache.org>
> I plan to do a bit more work on the IMAP proposal in the next few months.
> How much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).
Would it be possible to enumerate what needs to be done to run/test IMAP ?
What is the current status and how can one help most effectively ?
thanks,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Darrell DeBoer" <da...@apache.org>
> I plan to do a bit more work on the IMAP proposal in the next few months.
How
> much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).
Would it be possible to enumerate what needs to be done to run/test IMAP ?
What is the current status and how can one help most effectively ?
thanks,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commandsCommandTemplate.java)
Posted by Danny Angus <da...@apache.org>.
+1 G'day!
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Welcome back Darrell! Glad to have you around again.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands
CommandTemplate.java)
Posted by Serge Knystautas <se...@lokitech.com>.
Welcome back Darrell! Glad to have you around again.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Darrell DeBoer wrote:
> G'day,
>
> I thought I'd better (re)introduce myself, as I've been inactive in James
> since February or so, and there seem to be a few new names around (which is
> fantastic). I'm currently looking for work in Brisbane, Australia, and given
> the state of the job market I might have a fair bit of time for open-source
> coding coming up.
>
> I started working on James mid-last-year, when I contributed some patches to
> the UsersRepository; I then helped to make database storage simpler by using
> direct JDBC with the SQL defined in a single resource file
> (sqlResources.xml).
>
> Around Christmas last year, I did a big bunch of refactoring on the IMAP
> proposal, as I continually swayed between rewriting it from scratch and
> working with what was there. I ripped up some HUUUUGE classes and pulled the
> code for handling individual commands into separate classes. At the same
> time, I setup a file-based testing framework for protocol testing, which is
> very similar to (but not as nice as) what Harmeet has recently added as the
> ProtocolSimulator. I haven't had a chance to look closely at the changes that
> have been made since I dropped off the radar, but will do shortly.
>
> I'm ashamed to admit that I was the cause of that horrible hard-coded
> "daz2000" reference that was removed recently from one of the source files.
> Obviously committed that without proper perusal.
>
> I plan to do a bit more work on the IMAP proposal in the next few months. How
> much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).
>
> ciao,
> Daz
>
>
> On Mon, 11 Nov 2002 14:44, darrell@apache.org wrote:
>
>>darrell 2002/11/10 20:44:41
>>
>> Modified: proposals/imap build-test.xml build.xml
>> proposals/imap/conf james-assembly.xml james-config.xml
>> james-server.xml
>> proposals/imap/java/org/apache/james/imapserver
>> BaseCommand.java CommandFetch.java FileMailbox.java
>> SimpleMessageAttributes.java
>> proposals/imap/java/org/apache/james/imapserver/commands
>> CommandTemplate.java
>> Added: proposals/imap/java/org/apache/james/imapserver
>> BaseConnectionHandler.java
>> Removed: proposals/imap build-imap.xml
>> Log:
>> IMAP Proposal updates.
>>
>> * Synchronized build.xml, james-comfig.xml, james-server.xml and
>>james-assembly.xml with latest versions from main tree.
>> * Removed build-imap.xml, which duplicated build.xml, and was hopelessly
>>out of date.
>> * Build now compiles directly from main and proposal source trees,
>> rather than first copying source to build/src and then compiling.
>> * Added BaseConnectionHandler, recently removed from main tree, into IMAP
>> proposal, as it was still used. Need to look at AbstractJamesService,
>>which seems to replace this functionality.
>> * IMAP proposal now compiles and builds, and starts successfully. Next
>>I'll have to try running the tests to see what's actually working.
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (Darrel DeBoer)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Don't feel sorry for me - I went bushwalking on Tuesday, and surfing
> yesterday. I call it "embracing the IT downturn". ;)
Good on ya! :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (Darrel DeBoer)
Posted by Darrell DeBoer <da...@apache.org>.
On Tue, 12 Nov 2002 06:10, Noel J. Bergman wrote:
> Darrel,
>
> G'day, Mate. Welcome back, although I'm sorry to see it under the
> particular circumstances.
What circumstance? Proscribed holidays?
Don't feel sorry for me - I went bushwalking on Tuesday, and surfing
yesterday. I call it "embracing the IT downturn". ;)
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (Darrel DeBoer)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Darrel,
G'day, Mate. Welcome back, although I'm sorry to see it under the
particular circumstances.
I know that a bunch of folks will be happy to see more work on IMAP. It
would be nice to have full Exchange functionality.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Darrell,
> > 1) Conceptual misunderstanding of the role of the message sequence
> > numbers. MSNs cannot be associated with a mailbox object, because
they
> > are a per connection, not per mailbox, concept. It's more than
possible
> > for two different connections to have different MSN=>UID maps for a
> > given mailbox. Mailboxes should only know about UIDs.
>
> You may be right, but can you give an example of where 2 different
> connections
> would have different MSN's for the same underlying mailbox. From my
> understanding, the rule for mapping MSN=>UID is strictly a contiguous
> sequence in ascending order of UIDs. This doesn't allow allowing
different
> mappings. The MSN=>UID mapping may change between sessions when the
> underlying mailbox has changed, which may be what you meant by
> "connections".
It's a little more complicated than this. Consider the following
situation.
Two separate connections (sockets) are opened by clients. Over these
connections they log in, etc., and select the same mailbox.
One user proceeds to run a series of SEARCH commands. According to
section 7.4.1, no EXPUNGE response can be sent during this series of
commands. This is necessary so the msns can be kept in synch between
the client and the server. So this client maintains the original set of
msns as seen upon selection of the mailbox.
Meanwhile, the other user stores a \Deleted flag for some messages,
using a STORE. The user then executes an EXPUNGE command, which results
in these \Deleted messages being cleared from the mailbox and a series
of EXPUNGE responses being sent. This changes the set of msns.
Now we have two connections, with different MSN=>UID mappings.
What will happen, for a well behaved client, is that the client in the
first case will received an EXISTS response when the size of the mailbox
changes. After completing the last sent SEARCH command and before
sending the next one, it will issue a NOOP or other command that allows
the client to reset the msn sequence. But even this behavior isn't
required by spec. See section 5.5 for more discussion of this.
> > 11) Information is duplicated between the ImapRequest and
ImapSession
> > interfaces.
>
> 11a. ImapSession interface is a travesty. Originally, there was no
> interface
> between SingleThreadedConnectionHandler and the commands - at least
this
> makes it clear what the commands are using (and not).
I've actually fleshed out ImapSession some. I definitely don't think
the ImapCommands should be accessing SingleThreadedConnectionHandler
directly. Basically the ImapSession now allows the commands to access
session specific data (session state, current user, currently selected
mailbox, etc.) as well as provides some basic utilities used by multiple
commands (generate an untagged response, generate an expunge response,
get a mailbox, etc.)
> a) Every command without an rfc protocol test doesn't work.
> b) Some of the commands with rfc protocol tests may not work.
> - tests are incomplete
> - tests fail
> c) Many browsers may not work, even when the rfc protocol tests do.
> d) Licence headers need to be full Apache licence (I think).
> e) Test suite should be updated to use regular expressions rather than
> dinky
> custom codes. (All my fault, I'm afraid).
>
> Plenty to keep us busy, anyhow.
Definitely. :) I'm looking forward to it. But for now, 2.1 awaits
completion...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Darrell DeBoer <da...@apache.org>.
Hi Peter,
It's great to see so much energy and enthusiasm in the James development team
ATM. I'm looking forward to being a part of the v3 development effort.
Regarding the issues you enumerate:
On Tue, 12 Nov 2002 04:17, Peter M. Goldstein wrote:
>
> 1) Conceptual misunderstanding of the role of the message sequence
> numbers. MSNs cannot be associated with a mailbox object, because they
> are a per connection, not per mailbox, concept. It's more than possible
> for two different connections to have different MSN=>UID maps for a
> given mailbox. Mailboxes should only know about UIDs.
You may be right, but can you give an example of where 2 different connections
would have different MSN's for the same underlying mailbox. From my
understanding, the rule for mapping MSN=>UID is strictly a contiguous
sequence in ascending order of UIDs. This doesn't allow allowing different
mappings. The MSN=>UID mapping may change between sessions when the
underlying mailbox has changed, which may be what you meant by "connections".
That said, I agree that the mailbox shouldn't need to track MSN's. They can
and do change whenever a mailbox message is expunged, and are easily
generated by enumerating the messages in a mailbox.
>
> 2) Lack of handling for the "literal" string argument type. Basically,
> the spec allows (and requires in the case of
> internationalization/localization support, since quoted strings are
> restricted to US-ASCII) the use of {<number of bytes>} as an argument to
> specify that the server should send a continuation response and take the
> next <number of bytes> as the string data.
>
> 3) Mailbox name encoding (as per spec) is not supported
>
> 4) The Search command is not implemented
>
> 5) Support for the special "INBOX" mailbox alias is not present
Yep, to all these.
>
> 6) Three of the commands, for no reason I can discern, are not in the
> commands package. These commands also don't seem to take advantage of
> any of the encapsulated methods in SingleThreadedConnectionHandler.
> This led to at least one set of malformed NO responses, and a lot of
> duplicate code. I'm assuming these classes predate the others, and
> simply need to be modified/moved.
Your assumption is correct. Originally every command seemed to be implemented
via cut-and-paste of a single method. I refactored out the easier ones into
the separate command classes you see today, using the Template Method pattern
to handle to commonality between them. Some of the commands, I barely touched
at all - namely the ones that weren't moved into the commands package.
The main culprits are BaseCommand and it's derivatives - CommandStore,
SingleThreadedConnectionHandler, CopyCommand and CommandFetch. For some
reason CopyCommand was moved into the commands package, but wasn't moved over
to the new framework.
>
> 7) The SingleThreadedConnectionHandler class has bad code at the point
> where commands are read off the wire. The whole
> "setCanParse/getCanParse" concept violates basic threading techniques
> (if the connection handling is single threaded it's superfluous, if
> multi-threaded it's a race condition) and there is a busy loop at this
> point.
I'm sure you're right - the whole handling connections bit needed an overhaul.
>
> 8) EXPUNGE responses are being sent after command completion responses,
> in violation of spec.
Looks like I refactored the existing implementation into a separate command,
and left it at that. For all of the commands I actually worked on, I wrote a
protocol test file. All the others should be assumed to be broken.
The commands that have tests are: AUTHENTICATE, CAPABILITY, CREATE, DELETE,
EXAMINE, FETCH, LIST, LOGIN, LOGOUT, LSUB, SELECT, SUBSCRIBE. I'm not saying
that these all work, but anything else should be assume *not* to work. In
fact FETCH needs wholesale refactoring, but at least some tests are present
to aid the process.
>
> 9) MSN/UID set handling was incorrect - using a '-1' as an end delimiter
> in some cases as opposed to producing a correct range. No real reason
> to do this - the comment about Microsoft Outlook's behavior is not
> correct, as Outlook was behaving according to spec.
>
I'm not surprised. Needs fixing.
> 10) Comments are almost wholly absent.
>
Guilty as charged, although I *did* add some tests, so I plead for leniency.
;).
> 11) Information is duplicated between the ImapRequest and ImapSession
> interfaces.
11a. ImapSession interface is a travesty. Originally, there was no interface
between SingleThreadedConnectionHandler and the commands - at least this
makes it clear what the commands are using (and not).
>
> 12) Despite not being ConnectionHandlers, many of the command objects
> extended BaseConnectionHandler (all functionality was unused). The
> command hierarchy in general is a little confused, with both BaseCommand
> and CommandTemplate appearing to assert central roles. Usage and
> argument validation mechanisms are not unified and, in at least a few
> cases, will need to be redesigned to account for point 2 above.
See 6) above. BaseConnection and BaseCommand are in a "pre-refactored" state.
>
> 13) Lots and lots of "magic strings".
>
> 14) The partial fetch (allowing one to specify octets to be fetched) is
> not implemented.
>
> 15) The highest UID stuff is not currently implemented for mailboxes -
> highest UID is null on start.
Yeah, yeah, yeah... to these. ;)
>
> This is the "off the top of my head" list - I think there were a few
> other issues I ran into. I'll have to look at the code again to be
> sure. Any other issues you're aware of?
a) Every command without an rfc protocol test doesn't work.
b) Some of the commands with rfc protocol tests may not work.
- tests are incomplete
- tests fail
c) Many browsers may not work, even when the rfc protocol tests do.
d) Licence headers need to be full Apache licence (I think).
e) Test suite should be updated to use regular expressions rather than dinky
custom codes. (All my fault, I'm afraid).
Plenty to keep us busy, anyhow.
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Darrell,
> I thought I'd better (re)introduce myself, as I've been inactive in
James
> since February or so, and there seem to be a few new names around
(which
> is
> fantastic). I'm currently looking for work in Brisbane, Australia, and
> given
> the state of the job market I might have a fair bit of time for open-
> source
> coding coming up.
Nice to meet you. :) I'm Peter.
> I plan to do a bit more work on the IMAP proposal in the next few
months.
> How
> much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).
I'd love to coordinate with you and others on this one. I've been
looking at the IMAP code for a month or so now and have been working on
patches for a number of issues. Among the issues I've found are:
1) Conceptual misunderstanding of the role of the message sequence
numbers. MSNs cannot be associated with a mailbox object, because they
are a per connection, not per mailbox, concept. It's more than possible
for two different connections to have different MSN=>UID maps for a
given mailbox. Mailboxes should only know about UIDs.
2) Lack of handling for the "literal" string argument type. Basically,
the spec allows (and requires in the case of
internationalization/localization support, since quoted strings are
restricted to US-ASCII) the use of {<number of bytes>} as an argument to
specify that the server should send a continuation response and take the
next <number of bytes> as the string data.
3) Mailbox name encoding (as per spec) is not supported
4) The Search command is not implemented
5) Support for the special "INBOX" mailbox alias is not present
6) Three of the commands, for no reason I can discern, are not in the
commands package. These commands also don't seem to take advantage of
any of the encapsulated methods in SingleThreadedConnectionHandler.
This led to at least one set of malformed NO responses, and a lot of
duplicate code. I'm assuming these classes predate the others, and
simply need to be modified/moved.
7) The SingleThreadedConnectionHandler class has bad code at the point
where commands are read off the wire. The whole
"setCanParse/getCanParse" concept violates basic threading techniques
(if the connection handling is single threaded it's superfluous, if
multi-threaded it's a race condition) and there is a busy loop at this
point.
8) EXPUNGE responses are being sent after command completion responses,
in violation of spec.
9) MSN/UID set handling was incorrect - using a '-1' as an end delimiter
in some cases as opposed to producing a correct range. No real reason
to do this - the comment about Microsoft Outlook's behavior is not
correct, as Outlook was behaving according to spec.
10) Comments are almost wholly absent.
11) Information is duplicated between the ImapRequest and ImapSession
interfaces.
12) Despite not being ConnectionHandlers, many of the command objects
extended BaseConnectionHandler (all functionality was unused). The
command hierarchy in general is a little confused, with both BaseCommand
and CommandTemplate appearing to assert central roles. Usage and
argument validation mechanisms are not unified and, in at least a few
cases, will need to be redesigned to account for point 2 above.
13) Lots and lots of "magic strings".
14) The partial fetch (allowing one to specify octets to be fetched) is
not implemented.
15) The highest UID stuff is not currently implemented for mailboxes -
highest UID is null on start.
This is the "off the top of my head" list - I think there were a few
other issues I ran into. I'll have to look at the code again to be
sure. Any other issues you're aware of?
2.1 has been my first priority, so I haven't done as much here as I
would've liked. But I do have partial or complete fixes for much of the
above - as well as proper integration with the AbstractJamesService a la
the other services. Once 2.1 is actually out the door, I'll post my
changes to date for comment, etc. I'd really like to see some activity
on IMAP. Originally I was hoping to see it in 2.1, but with the number
of serious open issues and the lack of concerted effort it became clear
to me that this wouldn't be the case. At this point I'm hopeful that it
will be part of the next release.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Darrell DeBoer <da...@apache.org>.
On Thu, 5 Dec 2002 04:54, Sascha Kulawik wrote:
> > I plan to do a bit more work on the IMAP proposal in the next
> > few months. How
> > much work, I can't be sure, and please feel free to help out, with
> > contributions to code, constructive criticism, or flame mail ;).
>
> Hi Darrel,
>
> I've also done some stuff with the current IMAP code, and I'm also
> interesed to contribute in the future. Currently it's not possible for
> me, because of my daytime job - but I'm also interesed in UML Models, if
> you had made some of that I could think about it :)
>
> Regards,
>
> Sascha
Hi Sascha,
I did a bunch of work on the IMAP proposal earlier this year - mostly
refactoring work to pull all of the command methods into separate command
classes, and introducing the way that a command specifies it's arguments in
the constructor.
I was inactive on this list while you were contributing, but I've since had a
look at the new APPEND functionality. In seeing how much work there was
involved in getting the command going, I thought "there must be a better
way". I started coding, got carried away, and ended up with a brand-new
proposal.
You can have a look at the new proposal at:
http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/
My primary goal was to make it easier to add new functionality, and to fix
problems. In fact, once I got the core running, it only took a couple of days
to implement about 10 different commands. (I can't conclusively attribute
this ease of development to better design, or a better test infrastructure -
I reckon it's a bit of both).
On the test side of things - it's now possible to execute the protocol tests
without ever starting up Phoenix. This makes it *much* easier to run the
tests, and *much* easier to debug them when they fail. I did almost all of my
development using simple file-based protocol tests, and didn't connect an
Email client until every command was implemented (at least partially).
I was very pleased to find that it only took me a couple of hours to get KMail
to connect, create & delete mailboxes, append mail, copy mail, and set flags.
The only reason it didn't work straight off was stuff that wasn't fully
implemented in my rush to test a real client.
I'd love to hear your thoughts on the new proposal. I understand that you put
some effort into the old one, and I don't want to undermine those efforts.
But have a look, run the tests, and see what you reckon. There's a bunch of
stuff still to do, but we can have fun doing it!!
--
ciao,
Daz
PS: Yep, I'm hoping to get a few UML(esque) diagrams done at some stage. That
would definitely assist people to grasp the design more easily.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Sascha Kulawik <sa...@kulawik.de>.
> Sascha,
>
> Welcome back for the moment. :-) Do you think you'll have
> time soon to talk (even if you can't take time to code) about
> the IMAP service?
Hi Noel, I was missing the community :)
Yes, I think time for a good design pattern or a discussion about that
should be aviable. I think, after Xmas it should also be better in my
Job - and more time for me - got two greencard people for helping me :)
Regards,
Sascha
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sascha,
Welcome back for the moment. :-) Do you think you'll have time soon to
talk (even if you can't take time to code) about the IMAP service?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Posted by Sascha Kulawik <sa...@kulawik.de>.
> I plan to do a bit more work on the IMAP proposal in the next
> few months. How
> much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).
Hi Darrel,
I've also done some stuff with the current IMAP code, and I'm also
interesed to contribute in the future. Currently it's not possible for
me, because of my daytime job - but I'm also interesed in UML Models, if
you had made some of that I could think about it :)
Regards,
Sascha
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>