Re: Mailbox(Manager)
Hi Tim, I agree it should get moved out of the imap namespace. I delayed that to make it not do complicated by just introduce another dependency on a mini-library. But yeah its something we should do... Bye, Norman 2010/5/29 Tim-Christian Mundt d...@tim-erwin.de: Hi, since both IMAP and POP3 use the same backend, now (https://issues.apache.org/jira/browse/JAMES-983), shouldn't the storage packages rather be moved from the IMAP library to the server module? They are not IMAP specific any more. Maybe, they could get their own mailstore library which both the IMAP library and the server depend on. Regards Tim - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Mailbox(Manager)
Hey, when doing this, we could as well unify the artifact names. We have names like apache-james-imap-* (both, apache and james) james-server-* (only james) apache-mailet-* (only apache) I'm aware that this is no particularly helpful/urgent contribution of mine, but in the long term consistency and a clear structure pay out, I think. Let me know if I can be of any help with this. Tim Am Samstag, den 29.05.2010, 09:36 +0200 schrieb Norman Maurer: Hi Tim, I agree it should get moved out of the imap namespace. I delayed that to make it not do complicated by just introduce another dependency on a mini-library. But yeah its something we should do... Bye, Norman 2010/5/29 Tim-Christian Mundt d...@tim-erwin.de: Hi, since both IMAP and POP3 use the same backend, now (https://issues.apache.org/jira/browse/JAMES-983), shouldn't the storage packages rather be moved from the IMAP library to the server module? They are not IMAP specific any more. Maybe, they could get their own mailstore library which both the IMAP library and the server depend on. Regards Tim - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
GSOC/Maildir
Hi, for keeping a log of my GSOC project and gathering all related material (including source code) I set up a Trac: http://maildir.tim-erwin.de/ There's not too much going on, yet, however, this will change soon. I did some research on the file transaction stuff and javamaildir. a) The commons-transaction project is dormant because they say file transaction is impossible: +pWe have decided to move the project to dormant as we are convinced that the main +advertised feature emtransactional file access/em can not be implemented reliably. +We are convinced that no such implementation can be possible on top of an ordinary file system. +Although there are other useful parts (as multi +level locking including deadlock detection) the transactional file +system is the main reason people use this library for. As it simply +can not be made fully transactional, it does not work as advertised. +/p I don't want to introduce dead dependencies into James. An alternative would be xadisk. However, this seems to be a one man, one commit show. I don't really feel comfortable with it. Instead of using a TransactionManager in the first place, I'd start with regular file operations and later add some minimal transaction support or what ever is needed to make James reliable. Any opinions? b) Although I read a whole bunch of emails and comments the former attempt to introduce maildir into James, I don't really get the whole thing what happened back then. I feel kinda dumb, because I'm supposed to implement a maildir library and don't know about the already existing javamaildir library. Could anybody sum up in a few words why javamaildir was not used? All I know is, that it didn't support all functions needed for IMAP. Thanks in advance, Tim - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Mailbox(Manager)
Hi, I also personally found that the 2 mentioned goals would be fine before 3.0 release: 1.- Migrate imap projects/packages to store and protocol. 2.- Uniform the current apache-... james-... namings. And, yes, in the middle-term, it would be much cleaner. Now, when you talk about apache-james-imap-store, you need to translate the project responsible to access the different mail stores. During some time, I was really confused about this. On the other hand, mailet and jsieve projects are just released with current naming and the amount of work to migrate/rename is really huge without any user functionality counterpart. As Tim, I was also asking-party for a migration and uniform naming. But I just feel now that we should concentrate on releasing 3.0, trying to find and solve bugs in trunk. If we release, we should have more users, helping us to solve issues. The migration and renaming could be strong goals for 3.1 in a near future. Maybe we should in priority have a list of JIRA still to solve before releasing. I also find that the website documentation needs some urgent updates (how to setup and use james 3.0). Tks, Eric On 05/29/2010 12:08 PM, Tim-Christian Mundt wrote: Hey, when doing this, we could as well unify the artifact names. We have names like apache-james-imap-* (both, apache and james) james-server-* (only james) apache-mailet-* (only apache) I'm aware that this is no particularly helpful/urgent contribution of mine, but in the long term consistency and a clear structure pay out, I think. Let me know if I can be of any help with this. Tim Am Samstag, den 29.05.2010, 09:36 +0200 schrieb Norman Maurer: Hi Tim, I agree it should get moved out of the imap namespace. I delayed that to make it not do complicated by just introduce another dependency on a mini-library. But yeah its something we should do... Bye, Norman 2010/5/29 Tim-Christian Mundtd...@tim-erwin.de: Hi, since both IMAP and POP3 use the same backend, now (https://issues.apache.org/jira/browse/JAMES-983), shouldn't the storage packages rather be moved from the IMAP library to the server module? They are not IMAP specific any more. Maybe, they could get their own mailstore library which both the IMAP library and the server depend on. Regards Tim - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: GSOC/Maildir
Hi Tim, comments inside... 2010/5/29 Tim-Christian Mundt d...@tim-erwin.de: Hi, for keeping a log of my GSOC project and gathering all related material (including source code) I set up a Trac: http://maildir.tim-erwin.de/ There's not too much going on, yet, however, this will change soon. I did some research on the file transaction stuff and javamaildir. a) The commons-transaction project is dormant because they say file transaction is impossible: +pWe have decided to move the project to dormant as we are convinced that the main +advertised feature emtransactional file access/em can not be implemented reliably. +We are convinced that no such implementation can be possible on top of an ordinary file system. +Although there are other useful parts (as multi +level locking including deadlock detection) the transactional file +system is the main reason people use this library for. As it simply +can not be made fully transactional, it does not work as advertised. +/p I don't want to introduce dead dependencies into James. An alternative would be xadisk. However, this seems to be a one man, one commit show. I don't really feel comfortable with it. Instead of using a TransactionManager in the first place, I'd start with regular file operations and later add some minimal transaction support or what ever is needed to make James reliable. Any opinions? Yeah I think we should be ok without transactions here most of the times. Even in JCR implementation we don't use transactions. So implement something easy is a good idee.. b) Although I read a whole bunch of emails and comments the former attempt to introduce maildir into James, I don't really get the whole thing what happened back then. I feel kinda dumb, because I'm supposed to implement a maildir library and don't know about the already existing javamaildir library. Could anybody sum up in a few words why javamaildir was not used? All I know is, that it didn't support all functions needed for IMAP. To make it short javamail suxx when used as server component. javamail needs to load the whole message into memory most of all times, so its not really a good fit for high traffic / performance. The other problem is, javamail is to strict on malformated messages. Thats why we dedicited to not use any javamail based storage. The other problem with the maildir javamail lib was the lack of some methods (as you found out already). Thanks in advance, Tim Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
