Robert Burrell Donkin ha scritto:
On Tue, Sep 16, 2008 at 12:20 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Mon, Sep 15, 2008 at 2:04 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
(note that imap.message.request.base+imap4rev1 and
imap.command.imap4rev1 can be moved in both "groups").
3b) maybe we could even shorten package names: codec.encode => encode and
codec.decode => decode
+1
probably want to shorten imapserver -> imap as well
I thought you decided for imap when the code was not client/server specific
and imapserver when the code was for the server-side, but if this is not the
case maybe imap is better.
going forward, i think it'd be best for james server to use imapserver
and the component to use imap
ok
i'm not sure whether it's worthwhile including 'imap4rev1' in the
package since it's the only revision in common use
I think it should be removed. I don't like too much nested package trees.
please dive in
ok
3c) another option would be to extract the imap.message package to its
own
module (message). codec (or both decode/encode if it is splitted) would
then
depend on this message module). If I'm not wrong processor would so
depend
only on "message" and not on codec(decode/encode).
a separate message module makes sense
this area is a little messy and hope it can be resolved more elegantly
once some of the deprecated structure's removed.
I created a message module but I also moved there the "encode" part of the
codec.
I did this temporarily because I don't know how you want to deal with the
ant api-library-function-deployment layering and the above separation
allowed me to not introduce another layer.
i'll take a look at this once you've finished
How would you handle this in the self imposed layer rule?
no real need to keep the rule for IMAP
when decomposing a project as large and coupled as james, the tendency
is to create a mess of modules with deep and complex interdependencies
rather than working to correctly separate concerns. the
api/library/function split (plus deployment) prevents this from
happening. in order to fit the modules into this constraint it's
necessary to separate concerns and adopt a relatively coursely grained
and simple system of coupling.
So, how do you propose me to solve the "message" module issue?
A) move .message. to api?
B) create a new layer (between api and libraries) for .message. ?
C) leave as is (message+encode in a module, decode in the other module).
D) revert (merge again message and codec).
I'll give a try to the api module to understand if some class can be
moved from api to message in order to make the 2 modules indipendend,
but I doubt this is possible.
Maybe the whole "message" package should be moved to imap-api instead?
Looking again at it I don't fully understand why some of "imap.message"
should be in api and something else should be in codec (now message)
library. Can you give me any hint?
i was planning to review this post M1 so it's probably that stuff's
just badly organised
I find the current "message"+"codec" module better than before (even if
encode is in message module.
Maybe we should simply rename "codec" to "decoder" and release M1.
(I say this because I understand you want to do M1 early..)
4) What about removing the "experimental" string from seda packages? I
think
the "0.1" release version makes it already "experimental".
+1
I opened a JIRA assigned to me for this, will do another day.
great
thanks for the hard work :-)
You did most of it :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
