Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > > > From the other side developers maybe just don't need a full featured
> > > > ImapSession for their needs and want to use an easier interface.
> > > >
> > > > That was the intention for providing different "flavors" of
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > Think of a mbox and pop3. The backend opens the file and indexes it.
>
> that is not conversational state but an optimization
Right, but without a session there
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
> > > > Think of a mbox and pop3. The backend opens the file and indexes it.
> > >
> > > that is not conversational state but an optimization
> >
> > Right, but without a session there is no possibility for that
> > optimiza
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
> > > > Think of a mbox and pop3. The backend opens the file and indexes it.
> > >
> > > that is not conversational state but an optimization
> >
> > Right, but withou
robert burrell donkin wrote:
>
>
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert
> burrell donkin:
>
>
>
> > > > Think of a mbox and pop3. The backend opens the file
> and indexes it.
> > >
> > > that is not conversational state
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > In fact sessions bring a bit inconvenience for the developer. But in the
> > past stateless MailRepositories made problems. They were solved by
> > putting it in
Am Donnerstag, den 11.01.2007, 20:14 + schrieb robert burrell
donkin:
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
> > donkin:
> >
> > > > > > Think of a mbox and pop3. The backend opens the file and indexes it.
>
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, den 11.01.2007, 20:14 + schrieb robert burrell
donkin:
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
> > donkin:
> >
> > > > > > Think of a mb
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
> > > this is a good example of why i claim that state needs to considered
> > > more carefully. hopefully it may also illustrate why i claim that
> > > session is harmful.
> >
> > That's not fair. :-( It's just an example for
On 1/13/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
> > > this is a good example of why i claim that state needs to considered
> > > more carefully. hopefully it may also illustrate why i claim that
> > > session is harmfu
robert burrell donkin wrote:
manage the state more clearly. allow the backend access to more
information about the conversational state. the parsing layer should
manage the conversational state but this should be done through an
interface. the implementation should be provided by the backend
allo
On 1/13/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> manage the state more clearly. allow the backend access to more
> information about the conversational state. the parsing layer should
> manage the conversational state but this should be done through an
> inter
robert burrell donkin wrote:
>
> if there's interest, maybe i'll pull together some UML
Get on with it then :)
Cheers
-- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Steve Brewin schrieb:
> robert burrell donkin wrote:
>
>
>> if there's interest, maybe i'll pull together some UML
>>
>
> Get on with it then :)
>
> Cheers
>
> -- Steve
>
>
+1
Norman
-
To unsubscribe, e-mail: [EMAIL
On 1/13/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Steve Brewin schrieb:
> robert burrell donkin wrote:
>
>
>> if there's interest, maybe i'll pull together some UML
>>
>
> Get on with it then :)
>
> Cheers
>
> -- Steve
>
>
+1
i've taken the liberty to create:
http://svn.apache.org/repos/as
> -Original Message-
> From: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Sent: 15 January 2007 20:30
> To: James Developers List
> Subject: Re: MailboxManager API and session orientation was: Jsieve
> Configuration
>
>
> On 1/13/07, Norman Maure
robert burrell donkin wrote:
i've taken the liberty to create:
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
house speculations such as this.
i've added something very basic to
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/imap/messaging-api/.
it
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> i've taken the liberty to create:
> http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
> house speculations such as this.
>
> i've added something very basic to
>
http://svn.apache.org/repos
robert burrell donkin wrote:
I think this is a step back from the current design or it simply regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is just one way to fix it.
Let me better approach this discussion: what is your kn
On 1/17/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
+1.
ATM you have an inefficien
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think this is a step back from the current design or it simply regards
>> something we already trying to solve differently with the handlerapi.
>
> the current API design is flawed: this is just one way to fi
Danny Angus schrieb:
> On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> robert burrell donkin wrote:
>> >> I think this is a step back from the current design or it simply
>> regards
>> >> something we already trying to solve differently with the handlerapi.
>> >
>> > the current API desig
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
"hooks" in POP3
Danny Angus wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Let me better approach this discussion: what is your knowledge of the
whole james code (in particular the smtpserver/handler), how it changed
in 2.3.0, how it changed in trunk, then in the 2 experimental branches
and now i
On 1/18/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
IMHO "handlerapi" should not be smtp specific: we use handler for every
protocol. Maybe someone doesn't share this view, but I thought this was
the main intent in calling "handler api". At least the pattern (if not
the code) can be (and IMHO
Stefano Bagnara wrote:
> Danny Angus wrote:
> > On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> PS: I don't understand why this thread seems a me against robert or
> danny. I'm simply trying to understand robert ideas, and to ask him
> explanations. I did this with Joachim when he prov
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think that a command pattern having an ImapCommand as the command
>> cannot be the api to the backend (the MailboxManager). The
>> MailboxManager shoudl be able to provide results for Imap, for POP3, and
On 1/18/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
Stefano Bagnara wrote:
> Danny Angus wrote:
> > On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> PS: I don't understand why this thread seems a me against robert or
> danny. I'm simply trying to understand robert ideas, and to ask hi
On 1/18/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
> I think our goal is to share as most handler-api code as possible. So
> why we should not try to create an handler-api which fit all needs
> (POP3,IMAP,SMTP) ?
> In SMTP it is called fa
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I try to restart from scratch and summarize.
I think our main layers are
1) Protocol handling
2) Message processing
3) Message storage
Most of the Joachim work is about the message storage.
IMHO no
but at moment the implementation log
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> About the command pattern applied to our services we are already working
>> on a common infrastructure to reuse part of our network layer between
>> services and prepare for asynchronous handling: you can
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
"hooks" in POP3 or
robert burrell donkin wrote:
one of the tricky points about IMAP is that reasonable performance
requires that commands be executed in parallel but there are complex
rules that must be applied to the scheduling. to support concurrent
access to the same mailbox by multiple clients requires understa
robert burrell donkin wrote:
What you propose have IMAP all the way: I don't understand how you can
say it is more generic and less coupled. Am I missing the whole point?
perhaps one of them at least :-)
I was sure :-)
IMAP is a difficult protocol. making a implementation which performs
ok
robert burrell donkin wrote:
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
the diagram concerns the interface between the handler and processor
layers (as defined above)
i think that i now understand the reason for this confusio
robert burrell donkin wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> About the command pattern applied to our services we are already
working
>> on a common infrastructure to reuse part of our network layer between
>> services and prepare for
On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> one of the tricky points about IMAP is that reasonable performance
> requires that commands be executed in parallel but there are complex
> rules that must be applied to the scheduling. to support concurrent
> a
robert burrell donkin wrote:
commands that rely on or change message ID must be serialized and
executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption that IMAP commands have to be executed synchronously
and se
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in your inbox. You move ema
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are asynchronous. I would presume this is why
someone like Andy will question th
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> commands that rely on or change message ID must be serialized and
> executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption tha
Serge Knystautas wrote:
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in
On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> Initially I thought this thread was about 3, while your diagrams seems
>> to me about 1: this is why I'm confused.
>
> the diagram concerns the interface between the handler and processor
> layers (as defined a
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> robert burrell donkin wrote:
(i've had a chance to take a look at the rfc)
> What about multiple IMAP clients accessing the same imap folder? Are
> message identifiers diffe
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
> I would suggest looking briefly at the raw IMAP protocol. It makes
> the protocol nasty, but every command gets a unique token so that
> requests and responses are asynchrono
On 1/25/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
>
>
>
> > I would suggest looking briefly at the raw IMAP protocol. It makes
> > the protocol nasty, but every command g
t; Von: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 27. Januar 2007 12:37
> An: James Developers List; Serge Knystautas
> Betreff: RESTful email [WAS Re: MailboxManager API and session
> orientation was: Jsieve Configuration]
>
> On 1/25/07, Serge Knystautas &
On 1/27/07, Jürgen Hoffmann <[EMAIL PROTECTED]> wrote:
Hi Robert,
and who would want that sort of feature, when he can have imap?
IMAP is a great example of a very bad protocol totally unsuitable for
the internet
RSS/Atom is
more for webapps, which want to inform a user of site updates.
th
tas
Betreff: RESTful email [WAS Re: MailboxManager API and session
orientation was: Jsieve Configuration]
On 1/25/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]>
wrote:
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wr
On 1/28/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
RESTfulness is a red herring.
not so much a red herring as an orthogonal kipper ;-)
yes, i admit i used a lie of juxaposition
It is not lack of "RESTfulness" that
makes IMAP suck. It is that it is a complex and inspecific protocol
with
the resources that i think are of interest are emails, meta-data about
emails, collections of emails and meta-data about collections of
emails. these concepts already have natural correspondents in HTTP and
WebDAV
U/F it looks like although WEBDAV would be natural, just getting a list
O'stuff
smooth operation means being able to feed information about changes
back to the client which needs a little more thought
With HTTP 1.1 persistent connections this is possible and still allows
some of that pool magic. It can be a configurational pain (timeouts on
routers and stuff) but possi
On 1/31/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
>
> the resources that i think are of interest are emails, meta-data about
> emails, collections of emails and meta-data about collections of
> emails. these concepts already have natural correspondents in HTTP and
> WebDAV
>
U/F it looks l
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
had a talk with some of the DAV folks last year. AIUI the right way to
do it would be to standardize a small amount of emai
On 2/1/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
yeh (but i'm trying to learn as little as possible about it). i
suspe
55 matches
Mail list logo
