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 Stefano Bagnara <ap...@bago.org> on 2005/08/19 15:15:36 UTC
Re: IMAP
> Along with the refactoring, can we begin including tiny bits
> of IMAP support code and marking those experiment, and turned
> off by default?
IIRC current IMAP support does not persist messages.
This is a blocking issue. We can add it when it is at least working (also
with limits).
> Currently, I am looking at pulling the
> IMAP code out of Foedus
> [ http://sourceforge.net/projects/foedus ] and maybe
> integrating with MINA and using that as a base for a simple
> IMAP only server. Alternatively, we can work together.
I don't understand what is the Foedus License. Do you know that?
I don't know much of our experimental IMAP but it seems to me that our imap
is more advanced than the code inside foedus. BTW foedus does use avalon too
and should be not too difficul to create a block working inside james.
> Having IMAP locked away in its own
> branch secludes the effort from the rest of the project and I
> think that's at least partly why it hasn't been done yet.
> That, and the fact that there hasn't been an *authorative*
> detailed plan on how to get that subproject completed.
I don't have many interests in IMAP and I don't know much of IMAP protocol,
BTW I am here if you need support about james and hints on james
architecture.
Indeed, It would be cool to have preliminary IMAP support in the next james
release.
I've seen many developers asking for the status in this list, maybe there is
only needs for a lead.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Stefano,
I'd like to make a few quick suggestions about the
store interface.
Maybe the message interface should be refactored first?
Stefano Bagnara wrote:
> (Flags? Date? long Uid? Message attributes?)
> in ImapMessageAttributes I see: getInternalDate, getInternalDateAsString,
> getSize, getEnvelope, getBodyStructure.
>
I like the way MAPI takes care of this, ie...
GenericMessage
{
value GetProperty(id);
SetProperty(id, value);
[...]
}
There are
generic "properties" which have id/name,type values.
Some properties may be manatory by a backend, others
may not. eg. IMAP Server may always set the SEEN/boolean
property on a message in the store while the POP
Server may not. They both though may set CREATED/date
and the UID/binary properties though.
I think doing things this way would simply the
message store interface a good bit.
Is there really a good reason to have protocol specific
code in the MessageStore/Repository layer?
A generic message interface would abstract the protocol
specific code entirely, leaving it to the protocol handlers.
>
> Do the client runs query over this attributes?
>
I believe so. Through the "SEARCH" command...
http://ietfreport.isoc.org/idref/rfc3501/#page-49
> Are this attributes sent to the client without the body?
>
Yes. See FETCH
http://ietfreport.isoc.org/idref/rfc3501/#page-54
The message header only, body only, flags only, etc.
can be fetched.
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by Stefano Bagnara <ap...@bago.org>.
I'm trying to refactoring our current MailRepositories but I never used IMAP
and I don't have time to read the related RFC now. Can you help me answering
what do we need for Imap?
(Flags? Date? long Uid? Message attributes?)
in ImapMessageAttributes I see: getInternalDate, getInternalDateAsString,
getSize, getEnvelope, getBodyStructure.
Do we need to provide them in the MailRepository (or in my proposal
MessageRepository) interface?
Do the client runs query over this attributes?
Are this attributes sent to the client without the body?
Should we cache this fields in a repository or we can read the informations
while sending the message to the client?
Are there performance/size problems by using the folder path as string a
repository_name ? Does IMAP uses this string to point folders? How long can
be the path?
Do you ever need to access multiple folders in the same query by using IMAP?
IIRC IMAP has the concept of shared folders: can anyone explain how does it
works? Are they seen as subfolders of my own personal root folder or what?
> > The core of 2) is as I said: Support hierarchical stores
> and all the
> > required methods on them (delete & rename). How the hierarchical
> > stores work is another matter and, as long as it works with minimum
> > changes to the current method, it is up to you. When IMAP
> references a
> > store it uses notation like:
>
> Ok, I see. The current James message store interface does
> not support folder hierarchies, and that needs to be done next?
>
> In other words, there needs to be a class that implements the
> 'ImapStore' interface like 'InMemoryStore' but serializes the
> messages and mailboxes?
> http://svn.apache.org/repos/asf/james/server/branches/imap-dev
> /proposals/imap2/java/org/apache/james/imapserver/store/InMemo
> ryStore.java
>
> How does MailRepository relate to a MailStore? Seems to me
> those should be the same thing.
>
> What interface is POP3 server going to use? 'ImapStore'
> as well? Should the store object export an additonal
> interface for POP3?
>
> Regards,
> Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Jason Webb wrote:
>
> The core of 2) is as I said: Support hierarchical stores and all the
> required methods on them (delete & rename). How the hierarchical stores work
> is another matter and, as long as it works with minimum changes to the
> current method, it is up to you. When IMAP references a store it uses
> notation like:
Ok, I see. The current James message store interface
does not support folder hierarchies, and that needs to
be done next?
In other words, there needs to be a class that implements
the 'ImapStore' interface like 'InMemoryStore' but
serializes the messages and mailboxes?
http://svn.apache.org/repos/asf/james/server/branches/imap-dev/proposals/imap2/java/org/apache/james/imapserver/store/InMemoryStore.java
How does MailRepository relate to a MailStore? Seems to
me those should be the same thing.
What interface is POP3 server going to use? 'ImapStore'
as well? Should the store object export an additonal
interface for POP3?
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Kervin L. Pierre [mailto:kervin@adevsoft.com]
> Sent: 22 August 2005 13:35
> To: James Developers List
> Subject: Re: IMAP
>
> Hello Jason,
>
> Jason Webb wrote:
> > 2) Support hierarchical stores and all the required methods on them
> (delete
> > & rename)
> > 3) Add attributes to users so we can store mailbox subscriptions.
> >
> > I have done 3, but not committed it yet.
> > 2 is in progress. At the moment I can show the contents of an existing
> > mailbox as POP3 or IMAP as long as it is a file:// based store. You
> can't do
> > much else. As far as a timeframe goes, who knows.
> >
>
> Once again, progress.
>
> Jason, I take it you're the point person
> for IMAP?
>
> Questions...
> (i) Can 2 be tackled before 3 is checked in?
Yes
>
> (ii)Can you specify a specific sub-task or list
> of sub-tasks that you would like to delegate?
> Hopefully something that can be isolated and
> has clear requirements?
Hmm. I'd like to say yes, there is, but I sort of made it up as I found
things.
The core of 2) is as I said: Support hierarchical stores and all the
required methods on them (delete & rename). How the hierarchical stores work
is another matter and, as long as it works with minimum changes to the
current method, it is up to you. When IMAP references a store it uses
notation like:
#mail.jw.INBOX which is translated to jw/ (this is also the same path as the
POP3 mailbox as well) , or
#mail.jw.Drafts which is translated to jw/Drafts/
So you need to be able to get a user's main repository (inbox) and
list/edit/delete all the repositories beneath it. POP3 doesn't support this
so James doesn't support it either.
Hope this makes sense, but feel free to ask more questions.
-- Jason
>
>
> Regards,
> Kervin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Hello Jason,
Jason Webb wrote:
> 2) Support hierarchical stores and all the required methods on them (delete
> & rename)
> 3) Add attributes to users so we can store mailbox subscriptions.
>
> I have done 3, but not committed it yet.
> 2 is in progress. At the moment I can show the contents of an existing
> mailbox as POP3 or IMAP as long as it is a file:// based store. You can't do
> much else. As far as a timeframe goes, who knows.
>
Once again, progress.
Jason, I take it you're the point person
for IMAP?
Questions...
(i) Can 2 be tackled before 3 is checked in?
(ii)Can you specify a specific sub-task or list
of sub-tasks that you would like to delegate?
Hopefully something that can be isolated and
has clear requirements?
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Kervin L. Pierre [mailto:kervin@adevsoft.com]
> Sent: 19 August 2005 14:51
> To: James Developers List
> Subject: Re: IMAP
>
> Stefano Bagnara wrote:
> >
> > IIRC current IMAP support does not persist messages.
> > This is a blocking issue. We can add it when it is at least working
> (also
> > with limits).
> >
>
> This is good. What's involved in persisting the IMAP
> messages? Why is persisting IMAP messages different
> than persisting POP messages? Shouldn't they be
> writing to the same store object and/or database?
They should be. The rules are simple:
1) Don't break any current stores if at all possible
2) Support hierarchical stores and all the required methods on them (delete
& rename)
3) Add attributes to users so we can store mailbox subscriptions.
I have done 3, but not committed it yet.
2 is in progress. At the moment I can show the contents of an existing
mailbox as POP3 or IMAP as long as it is a file:// based store. You can't do
much else. As far as a timeframe goes, who knows.
If you want to help/make comments then I suggest you *really* understand how
James stores mail.
>
> Hopefully we can document the remaining issues
> and requirements necessary for getting preliminary
> IMAP support in.
>
> >
> > I don't understand what is the Foedus License. Do you know that?
>
> Yeah, he doesn't seem to have it anywhere on the site.
> I emailed him, he said we can treat it as public domain.
>
> > I don't know much of our experimental IMAP but it seems to me that our
> imap
> > is more advanced than the code inside foedus.
>
> But James has a large learning curve, and there is
> the question of whether the changes are even going
> to get into the tree. An IMAP authorative IMAP
> roadmap is really needed if that is to be done.
>
> >
> > I've seen many developers asking for the status in this list, maybe
> there is
> > only needs for a lead.
> >
>
> I agree. I think that's the case. If very basic
> IMAP support goes in as experimental. I suspect
> adoptors would eventually, over time, add the
> important missing pieces.
>
> Regards,
> Kervin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Stefano Bagnara wrote:
>
> IIRC current IMAP support does not persist messages.
> This is a blocking issue. We can add it when it is at least working (also
> with limits).
>
This is good. What's involved in persisting the IMAP
messages? Why is persisting IMAP messages different
than persisting POP messages? Shouldn't they be
writing to the same store object and/or database?
Hopefully we can document the remaining issues
and requirements necessary for getting preliminary
IMAP support in.
>
> I don't understand what is the Foedus License. Do you know that?
Yeah, he doesn't seem to have it anywhere on the site.
I emailed him, he said we can treat it as public domain.
> I don't know much of our experimental IMAP but it seems to me that our imap
> is more advanced than the code inside foedus.
But James has a large learning curve, and there is
the question of whether the changes are even going
to get into the tree. An IMAP authorative IMAP
roadmap is really needed if that is to be done.
>
> I've seen many developers asking for the status in this list, maybe there is
> only needs for a lead.
>
I agree. I think that's the case. If very basic
IMAP support goes in as experimental. I suspect
adoptors would eventually, over time, add the
important missing pieces.
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP
Posted by Ahmed Mohombe <am...@yahoo.com>.
> IIRC current IMAP support does not persist messages.
> This is a blocking issue. We can add it when it is at least working (also
> with limits).
Does anyone from the developers know what is really missing in JAMES in
order to persist messages? (now that you integrated Derby 'as default' :) ).
I read the message archive but really can't figure out from there.
> I don't have many interests in IMAP and I don't know much of IMAP protocol,
> BTW I am here if you need support about james and hints on james
> architecture.
> Indeed, It would be cool to have preliminary IMAP support in the next james
> release.
Not just cool: the only feature required for companies to take JAMES
seriously. In many of may previous projects, something else was chosen
(despite my recommendation for JAMES), because of missing IMAP :).
> I've seen many developers asking for the status in this list, maybe there is
> only needs for a lead.
Exactly. I couldn't say it better :).
Thanks in advance,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org