Re: [MailboxManager] API Design
Robert Burrell Donkin ha scritto: > the problem is that session is used in two different senses: database > session and a session of a (session-oriented) protocol > > if you're using a transactional datastore then yes, you'll need a > datastore session to execute transactions but there is no necessity > for this to equal the MailboxAPI session Maybe there are *3* different sessions: the protocol session (for POP3, IMAP, SMTP), the mailboxapi session, the datastore session. Or you are saying that the MailboxAPI session will be the same as (or 1 to 1 to) the protocols session? >> Maybe the problem is that I don't know what the MailboxManager >> responsibility and API users are/will be so I don't know what layer of >> the architecture will be involved by this "API Design" thread. > > i agree that this is the major problem: we need to understand the use > cases better > > - robert Maybe you are the one that better know both the implementations we currently have and the requirement for IMAP. Do you think we should evolve some of the currently existing api or do you think it's better to start from scratch a new design? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMAP] MessageResult += Content
Robert Burrell Donkin ha scritto: >> I'm not sure I understand the size in octect. You write a StringBuffer, >> so it is an unicode string, how can you calculate the real octects if >> you don't know the charset/encoding that will be used when the buffer >> will be written out? > > the content must be prior encoded into US-ASCII. probably should be javadoc'd. At least SMTP supports 8bitmime feature and binary encoding. Do you mean that we'll have to re-encode that messages in order to store them using the MailboxManager API ? I've not even investigated this option, but before thinking what the real problems could be I want to be sure I'm understanding what you propose! Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source distribution 3.0 snapshot
On 11/1/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Oct 31, 2007 9:18 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > > Noel J. Bergman wrote: > > > Bernd Fondermann wrote: > > > > > >> Building the source distribution from the nightly build fails. Both top > > >> level properties files are missing and a lot of java source files are > > >> missing, too. > > > > > >> Shouldn't we build the source distribution from root directory (parent > > >> of phoenix-deployment and all other modules)? > > > > > > Arguably, we shouldn't bother to distribute source for the nightlies. > > > Just > > > binary, and let people come to SVN for anything else. > > > > Fine with me. > > > > As soon as we want to release something, we would need to fix that anyway. > > I'll create a blocking JIRA. > > mea culpa > i always create source distributions the old fashioned way: just clean > checkout the source then tar or zip manually is this the equivalent to B) below? > i'll fix but i can either > > A) remove the source distribution build > or B) ensure the source build includes all modules > > opinions? I'd favor B) Let's just package up everything coming out of svn and leave out the artefacts created by the build. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source distribution 3.0 snapshot
On Oct 31, 2007 9:18 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > Noel J. Bergman wrote: > > Bernd Fondermann wrote: > > > >> Building the source distribution from the nightly build fails. Both top > >> level properties files are missing and a lot of java source files are > >> missing, too. > > > >> Shouldn't we build the source distribution from root directory (parent > >> of phoenix-deployment and all other modules)? > > > > Arguably, we shouldn't bother to distribute source for the nightlies. Just > > binary, and let people come to SVN for anything else. > > Fine with me. > > As soon as we want to release something, we would need to fix that anyway. > I'll create a blocking JIRA. mea culpa i always create source distributions the old fashioned way: just clean checkout the source then tar or zip manually i'll fix but i can either A) remove the source distribution build or B) ensure the source build includes all modules opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MailboxManager] API Design
On Oct 31, 2007 9:49 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On Oct 30, 2007 2:16 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> Robert Burrell Donkin ha scritto: > >>> for example, in the current API to perform an operation, it's > >>> necessary to create a session. however, sessions are heavyweight: > >>> performing extensive pre-emptive caching. this is fine when dealing > >>> with heavyweight session oriented front ends but not so good for > >>> lightweight front ends. IMAP is session oriented but this design > >>> decision in the MailboxAPI results in poor performance for any calls > >>> that do not run against the selected session. > >> How do you handle transactions if you don't use a Session or a similar > >> concept? > > > > there are various ways that transactions can be handled and a session > > can mean many different things. equating transaction with session is > > an error. > > > > IMAP opens a mailbox session and may well leave it open for 30 minutes > > or more. if a transaction were associated with a session then this > > would probably time out but (more importantly) it would no deliver the > > correct semantics. commands are atomic and many can be issues within a > > single session. the results of each command should be immediately > > visible to all other users. > > I don't tell that a session should have a single transaction. It is > possible to manage multiple transactions in a session. My question was > how you manage transactions if you don't have a session at all. the problem is that session is used in two different senses: database session and a session of a (session-oriented) protocol if you're using a transactional datastore then yes, you'll need a datastore session to execute transactions but there is no necessity for this to equal the MailboxAPI session > >> IMHO one of the missing things in JAMES Server is transaction support. > >> When a processor run a mail through a single step (a mailet) it should > >> either completely fail or completely succeed. > >> > >> How do you plan to support a simple LIST, RETR, DELE scenario without a > >> session? The list gives you identifier that are valid only in that > >> session, the following retr and the dele must use the same numbers. > >> > >> Are you simply saying that MailboxManager should be stateless and the > >> session should be managed on top of this? > > > > a stateless Mailbox shared by many users would prevent confusion about > > what a mailbox session really is > > > > explicit data store session and transaction management would at least > > then be clear > > > > - robert > > Not sure I understand: so you tell we need a "data store session" that > is something different from the IMAP session. Well, if so, I agree with it. the question is whether MailboxAPI session should equal data store session > Maybe the problem is that I don't know what the MailboxManager > responsibility and API users are/will be so I don't know what layer of > the architecture will be involved by this "API Design" thread. i agree that this is the major problem: we need to understand the use cases better - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMAP] MessageResult += Content
On Oct 31, 2007 9:44 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > +1 for the interface. > > Maybe "writeTo" is better than "write" (the first thought when I read > write(StringBuffer) is that the method write the content of StringBuffer > somewhere and not viceversa). +1 > I'm not sure I understand the size in octect. You write a StringBuffer, > so it is an unicode string, how can you calculate the real octects if > you don't know the charset/encoding that will be used when the buffer > will be written out? the content must be prior encoded into US-ASCII. probably should be javadoc'd. IMO use of StringBuffer is a poor design choice (but some work would be required to change it) but has no negative practical effects. should probably deprecate. > Do we need to know the charset and the transfer encoding from the header > of this content to be able to correctly evaluate the content or the > content has already been correctly "decoded" ? the content needs to be appropriately prior encoded. if the content has been decoded by the backend then it needs to be appropriately re-encoded. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
