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 Mohan Etikela <mo...@yahoo.com> on 2006/05/18 04:04:11 UTC

Re: I would like to contribute...

Hi,
   
  I would like to contribute to the development of James.  Can I choose subtopic/ feature I am interested?
   
  Could you let me know the procedure to get involved?
   
  Thanks,
  Mohan Etikela

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@joachim-draeger.de>.

Stefano Bagnara wrote:

> Did you plan to obtain a real javamail folder when you lookup the 
> MailStore or an object implementing a James interface very similar to 
> the Javamail folder ?

The MailStore has to implement the FolderAware interface which offers a 
getFolder() method which returns a real Javamail folder.

Joachim

>> Totally agree and already done. :-) The only thing that actually was 
>> changed in the core of James was hard coding that in memory store.
>> It now only depends on a James MailStore that can offer a Javamail 
>> Folder.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@joachim-draeger.de>.

Stefano Bagnara wrote:

>>> FolderAware: why does a mailRepository implements a FolderAware 
>>> interface that returns a Folder that is then incapsulated in a 
>>> JavaMailImapMailbox ? Can't we change the FolderAware to directly 
>>> return an ImapMailbox  so we don't have direct access to the 
>>> underlying Javamail Folder interface at this level?
>>
>> That is only an interim solution to allow access from the James side 
>> and from the imap server side until we are sure how to design the new 
>> MailStore. Then ImapMailbox  and ImapStore interfaces will be obsolete 
>> and James MailStore could be used directly.
> 
> Can you reply to the question itself? I understand your points but the 
> answer to the question will help me better understand if I learned 
> enough of that part ;-)

JamesImapStore could take place of JavaMailImapStore which looks up the 
MailRepository for the corresponding user and calls getImapMailbox() or 
maybe getImapMailbox(String folderName) on it.

>>> getUidValidity, getUidNext, getMsn: what are intended for?
>>
>> uidValidity is a (random or current time?) number that is generated 
>> when the store is created. The first message stored get's the uid 1 
>> the next 2. If the store is created again from scratch (maybe because 
>> of a system crash) that uidvalidity changes and the client knows that 
>> he can't depend on the now outdated uids. getUidNext is the uid the 
>> next new message will get.
>> getMsn translates Uid to message number
> 
> Currently repositories do not have a persistent place to remember this 
> thing, but maybe we simply have to create an hash of the repository 
> configuration so it changes only when the repository configuration is 
> change. We probably don't need to make it to change in different 
> circumstances.

uidValidity has to change when the last assigned uid is not known 
anymore. When you don't have an old value of uid you can increment you 
set uid=1 again and chang uidValidiry so everybody knows that has happened.

Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Joachim Draeger wrote:
> Stefano Bagnara wrote:
> 
>> FolderAware: why does a mailRepository implements a FolderAware 
>> interface that returns a Folder that is then incapsulated in a 
>> JavaMailImapMailbox ? Can't we change the FolderAware to directly 
>> return an ImapMailbox  so we don't have direct access to the 
>> underlying Javamail Folder interface at this level?
> 
> That is only an interim solution to allow access from the James side and 
> from the imap server side until we are sure how to design the new 
> MailStore. Then ImapMailbox  and ImapStore interfaces will be obsolete 
> and James MailStore could be used directly.

Can you reply to the question itself? I understand your points but the 
answer to the question will help me better understand if I learned 
enough of that part ;-)

>> What is the relation between users and store/mailboxes ? Is it like 
>> pop3 where we can keep it totally separated and simply have a method 
>> to lookup a repository associated to a given user (to store mail in 
>> localdelivery and to retrieve it in pop3server)?
> 
> I think yes by now. But for future enhancements we should keep in mind 
> the possibiltiy of implementing ACLs which would allow reading mailbox 
> of other users or group mailboxes.
> But this would be a feature to implement when everything else works stable.

Ok, the important thing is that there is no direct association from a 
mailbox to an user. Given a user we simply have to provide a method to 
find the mailbox/mailboxes he can see.

>> To name them in a James style I would rename ImapMailbox to 
>> MessageRepository. ImapStore functionality could be instead integrated 
>> in our current Store.
> 
> I Agree. But I'm not sure if we should adopt it 1:1.

As you proposed we may introduce a "simple" MessageRepository with 
limited capabilities and an ImapMessageRepository (or 
HierarchicalMessageRepository, or AdvancedMessageRepository) exposing 
the current functionalities of ImapMailbox.

>> getUidValidity, getUidNext, getMsn: what are intended for?
> 
> uidValidity is a (random or current time?) number that is generated when 
> the store is created. The first message stored get's the uid 1 the next 
> 2. If the store is created again from scratch (maybe because of a system 
> crash) that uidvalidity changes and the client knows that he can't 
> depend on the now outdated uids. getUidNext is the uid the next new 
> message will get.
> getMsn translates Uid to message number

Currently repositories do not have a persistent place to remember this 
thing, but maybe we simply have to create an hash of the repository 
configuration so it changes only when the repository configuration is 
change. We probably don't need to make it to change in different 
circumstances.

>>> It is hard to foresee all the requirements without understanding the 
>>> whole thing.
> 
>> I know I can't understand the whole thing if I don't soil my hands in 
>> the mud...
> 
> I'm not deep enough, either. :-) Nobody is, so it's hard to make decisions.
> 
> Joachim

Let's follow the best path with what we currently have and let's hope 
our instinct will bring us on the right way ;-)

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@gmx.de>.

Stefano Bagnara wrote:

> FolderAware: why does a mailRepository implements a FolderAware 
> interface that returns a Folder that is then incapsulated in a 
> JavaMailImapMailbox ? Can't we change the FolderAware to directly return 
> an ImapMailbox  so we don't have direct access to the underlying 
> Javamail Folder interface at this level?

That is only an interim solution to allow access from the James side and 
from the imap server side until we are sure how to design the new 
MailStore. Then ImapMailbox  and ImapStore interfaces will be obsolete 
and James MailStore could be used directly.

> What is the relation between users and store/mailboxes ? Is it like pop3 
> where we can keep it totally separated and simply have a method to 
> lookup a repository associated to a given user (to store mail in 
> localdelivery and to retrieve it in pop3server)?

I think yes by now. But for future enhancements we should keep in mind 
the possibiltiy of implementing ACLs which would allow reading mailbox 
of other users or group mailboxes.
But this would be a feature to implement when everything else works stable.

> appendMessage(...): why does this interface take an additional Flags 
> parameter? Aren't Flags already part of the MimeMessage structure?

I don't know. :-) Maybe it's reflecting the imap protocol and messages 
are stored with flags and to avoid an additional msg.setFlags() line, 
but I'm not sure.

> Can you give me an explanation of name and fullname ? Sorry for my 
> ignorance in IMAP :-(

My IMAP knowledge is not that substantiated, too. I guess fullname 
contains namespace information. name is just like "trash" or "drafts".

> getFirstUnseen/getUnseenCount: is this user specific or a folder has the 
> seen/unseen concept in a user-agnostic way?

As of my experience it's not user-agnostic. If anybody has open a 
message it is read.

> To name them in a James style I would rename ImapMailbox to 
> MessageRepository. ImapStore functionality could be instead integrated 
> in our current Store.

I Agree. But I'm not sure if we should adopt it 1:1.

> getUidValidity, getUidNext, getMsn: what are intended for?

uidValidity is a (random or current time?) number that is generated when 
the store is created. The first message stored get's the uid 1 the next 
2. If the store is created again from scratch (maybe because of a system 
crash) that uidvalidity changes and the client knows that he can't 
depend on the now outdated uids. getUidNext is the uid the next new 
message will get.
getMsn translates Uid to message number

>> It is hard to foresee all the requirements without understanding the 
>> whole thing.

> I know I can't understand the whole thing if I don't soil my hands in 
> the mud...

I'm not deep enough, either. :-) Nobody is, so it's hard to make decisions.

Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Joachim Draeger wrote:
>> I'll try to define a new James interface (MessageFolder or 
>> MessageRepository) based on a subinterface of the Javamail Folder 
>> interface. I'll start putting there all the commands we really use 
>> from the Javamail folder.
> 
> And there you touched another big design deficiency of Javamail. There 
> isn't a Folder interface! That could really be a knock out against 
> Javamail because we would be very limited in inheritance. So I'm really 
> not sure about that. At the moment I propagate Javamail because it's 
> actually there and has a working implementation that fit's all needs of 
> imap.
> The imap2 proposal already has own interfaces for ImapStore and 
> ImapMailbox (Folder). ImapMailbox is similar to Folder from Javamail.
> I've created JavaMailImapStore and JavaMailImapMailbox which aren't much 
> more than wrapper classes. So the Javamail approach is enough capsulated.
> However the final store will look like. It's like a prototype we can 
> learn from in the future.

Ok, I just looked at the ImapStore and ImapMailbox interfaces: If I 
understood right those are the interfaces I intended we should have 
created ;-)

I have a few questions:

FolderAware: why does a mailRepository implements a FolderAware 
interface that returns a Folder that is then incapsulated in a 
JavaMailImapMailbox ? Can't we change the FolderAware to directly return 
an ImapMailbox  so we don't have direct access to the underlying 
Javamail Folder interface at this level?

What is the relation between users and store/mailboxes ? Is it like pop3 
where we can keep it totally separated and simply have a method to 
lookup a repository associated to a given user (to store mail in 
localdelivery and to retrieve it in pop3server)?

store(MailImpl): imho we should think at this new "repository" as a 
Message repository and not Mail repository, so we can remove the 
store(MailImpl) thing (as we would not store envelope informations 
anyway) and only keep the appendMessage(MimeMessage).

appendMessage(...): why does this interface take an additional Flags 
parameter? Aren't Flags already part of the MimeMessage structure?

Can you give me an explanation of name and fullname ? Sorry for my 
ignorance in IMAP :-(

getFirstUnseen/getUnseenCount: is this user specific or a folder has the 
seen/unseen concept in a user-agnostic way?

To name them in a James style I would rename ImapMailbox to 
MessageRepository. ImapStore functionality could be instead integrated 
in our current Store.

getUidValidity, getUidNext, getMsn: what are intended for?

copyMessage(long uid, ImapMailbox toMailbox): I always thought we need a 
similar method but I always thought at it reversed: 
copyMessage(ImapMailbox fromMailbox, long uid). I also thought that a 
moveMessage would be useful to increase the optimization opportunities. 
I just wanted to share a thought... nothing important right now.

>> This is a first step: I'll try to do this in the trunk in the next 
>> weeks, then we'll move to the next issue.
>> The new interface will be experimental, but we discussed about this 
>> repository change for years, we should put something in, and then 
>> we'll refactor/tune it in future!
> 
> I'm pro starting a discussion about the backend. And it is always better 
> to have some experimental code than just talk about it. But I don't 
> think we should start implementing an own imap compatible store or 
> making irreversible design decisions at this time.

I agree! As you see I already had a lot of doubt to clear up before 
starting anything.

> It is hard to foresee all the requirements without understanding the 
> whole thing.

I know I can't understand the whole thing if I don't soil my hands in 
the mud...

> On the other hand i don't want to slow down. I actually love Java 
> because of refactoring.
> 
> Joachim

I hope I'll be helpful and not only someone that makes a lot of 
questions and doesn't understand ;-)

I will have a lot of questions about the users also, as I already did a 
few thoughts about usersrepository refactoring for James, and I'd like 
to understand better the imap requirements for that. But more on this 
later...

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@gmx.de>.

Stefano Bagnara schrieb:

>>> Did you plan to obtain a real javamail folder when you lookup the 
>>> MailStore or an object implementing a James interface very similar to 
>>> the Javamail folder ?
>>
>> The MailStore has to implement the FolderAware interface which offers a
>> getFolder() method which returns a real Javamail folder.
> 
> Ok, so I think we should start making this more James-ish.

Of course that is not James-ish. It's an interim solution.

> I'll try to define a new James interface (MessageFolder or 
> MessageRepository) based on a subinterface of the Javamail Folder 
> interface. I'll start putting there all the commands we really use from 
> the Javamail folder.

And there you touched another big design deficiency of Javamail. There 
isn't a Folder interface! That could really be a knock out against 
Javamail because we would be very limited in inheritance. So I'm really 
not sure about that. At the moment I propagate Javamail because it's 
actually there and has a working implementation that fit's all needs of 
imap.
The imap2 proposal already has own interfaces for ImapStore and 
ImapMailbox (Folder). ImapMailbox is similar to Folder from Javamail.
I've created JavaMailImapStore and JavaMailImapMailbox which aren't much 
more than wrapper classes. So the Javamail approach is enough capsulated.
However the final store will look like. It's like a prototype we can 
learn from in the future.

> This is a first step: I'll try to do this in the trunk in the next 
> weeks, then we'll move to the next issue.
> The new interface will be experimental, but we discussed about this 
> repository change for years, we should put something in, and then we'll 
> refactor/tune it in future!

I'm pro starting a discussion about the backend. And it is always better 
to have some experimental code than just talk about it. But I don't 
think we should start implementing an own imap compatible store or 
making irreversible design decisions at this time.
It is hard to foresee all the requirements without understanding the 
whole thing.
On the other hand i don't want to slow down. I actually love Java 
because of refactoring.

Joachim

PS: sorry for that duplicate mails

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Joachim Draeger wrote:
> Stefano Bagnara wrote:
> 
>> Did you plan to obtain a real javamail folder when you lookup the 
>> MailStore or an object implementing a James interface very similar to 
>> the Javamail folder ?
> 
> The MailStore has to implement the FolderAware interface which offers a
> getFolder() method which returns a real Javamail folder.
> 
> Joachim

Ok, so I think we should start making this more James-ish.
I'll try to define a new James interface (MessageFolder or 
MessageRepository) based on a subinterface of the Javamail Folder 
interface. I'll start putting there all the commands we really use from 
the Javamail folder.

This is a first step: I'll try to do this in the trunk in the next 
weeks, then we'll move to the next issue.

The new interface will be experimental, but we discussed about this 
repository change for years, we should put something in, and then we'll 
refactor/tune it in future!

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@gmx.de>.

Stefano Bagnara wrote:

> Did you plan to obtain a real javamail folder when you lookup the 
> MailStore or an object implementing a James interface very similar to 
> the Javamail folder ?

The MailStore has to implement the FolderAware interface which offers a
getFolder() method which returns a real Javamail folder.

Joachim

>> Totally agree and already done. :-) The only thing that actually was 
>> changed in the core of James was hard coding that in memory store.
>> It now only depends on a James MailStore that can offer a Javamail 
>> Folder.



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

The it's better than I thought!

I'll wait for you to submit your work (hope as soon as possible) so I 
can review it and I hope I can help finding its way to the main codebase.

Did you plan to obtain a real javamail folder when you lookup the 
MailStore or an object implementing a James interface very similar to 
the Javamail folder ?

Stefano

Joachim Draeger wrote:
> Stefano Bagnara schrieb:
> 
>> I have a different idea on the steps and their priority, more tightly 
>> coupled to the developing cycle: we should try to make it working as a 
>> module with no changes to the rest of James, so we should make first 
>> the necessary modularizations James needs for this to happen, then we 
>> should create a sandbox project with the module: integrating it to 
>> James should be only a matter of adding the james-imap jar the 
>> assembly declarations and the config.xml stuff.
> 
> Totally agree and already done. :-) The only thing that actually was 
> changed in the core of James was hard coding that in memory store.
> 
> It now only depends on a James MailStore that can offer a Javamail Folder.
> 
> Joachim


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@joachim-draeger.de>.

Stefano Bagnara schrieb:

> I have a different idea on the steps and their priority, more tightly 
> coupled to the developing cycle: we should try to make it working as a 
> module with no changes to the rest of James, so we should make first the 
> necessary modularizations James needs for this to happen, then we should 
> create a sandbox project with the module: integrating it to James should 
> be only a matter of adding the james-imap jar the assembly declarations 
> and the config.xml stuff.

Totally agree and already done. :-) The only thing that actually was 
changed in the core of James was hard coding that in memory store.

It now only depends on a James MailStore that can offer a Javamail Folder.

Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

The main problem is that most people failed the 1 hour test: they're 
interested in contributing, they try to understand something about 
james, something about avalon, something about the current imap2 vs imap 
proposals, something about what works and what not, somthing about IMAP4 
protocol... they understand it is too much work and they need too much 
time to even start.

So I hope we'll find a way-out to this problem revitalizing the imap2 
proposal and making more clear what has to be done, and how: I think 
we'll find more people willing to help then!

Stefano

Joachim Draeger wrote:
> 
>> Unfortunately I've seen too much people asking and volounteering for 
>> imap and disappearing after 3 questions in the last year, so even if I 
>> don't need imap and I don't know the protocol itself, I'll try to 
>> coordinate the efforts.
> 
> I hope there will be some people to focus on imap because there is much 
> work to do. I probably won't come far alone.
> 
> Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@gmx.de>.

> Unfortunately I've seen too much people asking and volounteering for 
> imap and disappearing after 3 questions in the last year, so even if I 
> don't need imap and I don't know the protocol itself, I'll try to 
> coordinate the efforts.

I hope there will be some people to focus on imap because there is much 
work to do. I probably won't come far alone.

Joachim


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Mohan Etikela <mo...@yahoo.com>.

I will also try to help as much as I can to this effort.  I look forward to see the starting point for development after you finalize the discussion.

Norman Maurer <nm...@byteaction.de> wrote:  I will try to help as much as i can.. IMAP support is really a needed
feature for an "enterprise" mailserver.

bye
Norman

Am Freitag, den 19.05.2006, 18:54 +0200 schrieb Joachim Draeger:
> > Unfortunately I've seen too much people asking and volounteering for 
> > imap and disappearing after 3 questions in the last year, so even if I 
> > don't need imap and I don't know the protocol itself, I'll try to 
> > coordinate the efforts.
> 
> I hope there will be some people to focus on imap because there is much 
> work to do. I probably won't come far alone.
> 
> Joachim
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> !EXCUBATOR:1,446df9d437021353513366!

Re: Imap2 proposal Was: I would like to contribute...

Posted by Norman Maurer <nm...@byteaction.de>.

I will try to help as much as i can.. IMAP support is really a needed
feature for an "enterprise" mailserver.

bye
Norman

Am Freitag, den 19.05.2006, 18:54 +0200 schrieb Joachim Draeger:
> > Unfortunately I've seen too much people asking and volounteering for 
> > imap and disappearing after 3 questions in the last year, so even if I 
> > don't need imap and I don't know the protocol itself, I'll try to 
> > coordinate the efforts.
> 
> I hope there will be some people to focus on imap because there is much 
> work to do. I probably won't come far alone.
> 
> Joachim
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> !EXCUBATOR:1,446df9d437021353513366!

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Noel J. Bergman wrote:
> As Jason mentioned more than once, the IMAP2 code is in pretty decent shape;
> the holdup is that we need to re-do the MailRepository interface.
> 
> 	--- Noel

Ok, I just took the Joachim efforts as a pretest to take this imap 
proposal stuff in hands and try to find a concrete place for it in our 
roadmap.

 From a very fast review of the code I see problems also related to the 
creation/deletion of users, secure authentications (our SHA hashed 
passwords don't let the use of any algorythm but plain text passwords), 
and other similar problems.

Unfortunately I've seen too much people asking and volounteering for 
imap and disappearing after 3 questions in the last year, so even if I 
don't need imap and I don't know the protocol itself, I'll try to 
coordinate the efforts.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Joachim Draeger wrote:
>> - the list of subscribed folders is an user profile information.
> 
> And maybe that is detached from the MailStore. The list of subscribed 
> Folder could be namespace aware and lead to different types of 
> MailStores. (even nntp news)

This is exactly what I intended with my sentence! I'm happy I'm on the 
right way!

So I will keep this issue for later: it is not related to the message 
storage itself. Maybe this is related to the "unique repository 
identifier" we discussed 2 years ago: once we'll have introduced an 
unique identifier for repositories it will be easier to store repository 
refences in user profiles.

> I think we should start a Wiki-Page for collecting requirements.
> 
> Joachim

If you already have a good perception of the requirements please start 
such a page. Otherwise post here in the list the first things and let's 
see what arises.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@joachim-draeger.de>.

Stefano Bagnara wrote:
>>  - the mails need message numbers and uids
>>  - folders
>>  - keep a list of subscribed folders

> Please confirm/correct me:
> 
> - message numbers and uids are folder specific
> 
> - folders is a message repository, hierarchical

That's right.

> - the list of subscribed folders is an user profile information.

And maybe that is detached from the MailStore. The list of subscribed 
Folder could be namespace aware and lead to different types of 
MailStores. (even nntp news)

I think we should start a Wiki-Page for collecting requirements.

Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Joachim Draeger wrote:
> And there is much functionality needed:
> 
>  - the mails need message numbers and uids
>  - folders
>  - keep a list of subscribed folders
> 
> Joachim

Please confirm/correct me:

- message numbers and uids are folder specific

- folders is a message repository, hierarchical

- the list of subscribed folders is an user profile information.

is this right?

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@joachim-draeger.de>.

Noel J. Bergman wrote:

> the holdup is that we need to re-do the MailRepository interface.

And there is much functionality needed:

  - the mails need message numbers and uids
  - folders
  - keep a list of subscribed folders

Joachim


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: Imap2 proposal Was: I would like to contribute...

Posted by "Noel J. Bergman" <no...@devtech.com>.

As Jason mentioned more than once, the IMAP2 code is in pretty decent shape;
the holdup is that we need to re-do the MailRepository interface.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Stefano Bagnara <ap...@bago.org>.

Hi Joachim,

I'm happy to read your message: it seems to me you understand the 
current imap2 status better than most of the developers that approached 
the problem in the last year.

I just created a "parent issue" in JIRA to track the IMAP support in James.

http://issues.apache.org/jira/browse/JAMES-502

As I wrote in the issue I'll be happy to help with the James integration 
and reviewing anything that will be submitted.

Please, feel free to submit also incomplete/not working code: I think 
this would be useful anyway for anyone else working or studying IMAP on 
James.

I have a different idea on the steps and their priority, more tightly 
coupled to the developing cycle: we should try to make it working as a 
module with no changes to the rest of James, so we should make first the 
necessary modularizations James needs for this to happen, then we should 
create a sandbox project with the module: integrating it to James should 
be only a matter of adding the james-imap jar the assembly declarations 
and the config.xml stuff.

Stefano

Joachim Draeger wrote:
> Hi Stefano,
> 
> Stefano Bagnara wrote:
> 
>> I will try to submit soon an updated imap2 proposal (updated to build 
>> against the current trunk), so you'll have an updated source to start 
>> your work from!
> 
> I have already made some efforts in that direction. The main problem for 
> me was the in memory store because I need something to "touch" when 
> working with code. I guess many people feel the same and that's a reason 
> why there is so less success with it.
> So I began to fix it to let it compile against trunk and added a, guess 
> what, Javamail backend. For traceability I tried to touch as few of the 
> existing code as possible. I wanted to clean my code a bit before 
> publishing it. But if people are eager I could put out what I have in 
> the next week, okay?
> 
> At the moment my backend is not very stable and it is only supporting a 
> few operations.
> The existing frontend part of the Imap2 proposal looks quite 
> sophisticated even it is not easy to understand. But I think that is due 
>  to the fact that Imap is a *very* complex protocol. Pop3 is breeze 
> against that.
> I have seen a compatibility chart for the existing code that looks quite 
> impressive.
> 
> I suggest the following steps:
> 
> 1. Implementing a backend for the existing code. For me that is 
> unavoidable before further steps. Javamail has everything that is needed 
> for that and it shouldn't be too much work. Before starting a big 
> discussion: I'm just talking about a wrapper for the existing 
> interfaces. No serious design decision for Javamail is made at this point.
> 
> 2. Documentation for the existing code. Maybe some fancy UML, or just 
> prose. Just how it works and how components are interacting. I think it 
> is important to understand the existing code before making too much 
> changes to it.
> 
> 3. Discussing the existing architecture and talk about an adequate backend.
> 
> Joachim
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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: Imap2 proposal Was: I would like to contribute...

Posted by Joachim Draeger <jd...@gmx.de>.

Hi Stefano,

Stefano Bagnara wrote:

> I will try to submit soon an updated imap2 proposal (updated to build 
> against the current trunk), so you'll have an updated source to start 
> your work from!

I have already made some efforts in that direction. The main problem for 
me was the in memory store because I need something to "touch" when 
working with code. I guess many people feel the same and that's a reason 
why there is so less success with it.
So I began to fix it to let it compile against trunk and added a, guess 
what, Javamail backend. For traceability I tried to touch as few of the 
existing code as possible. I wanted to clean my code a bit before 
publishing it. But if people are eager I could put out what I have in 
the next week, okay?

At the moment my backend is not very stable and it is only supporting a 
few operations.
The existing frontend part of the Imap2 proposal looks quite 
sophisticated even it is not easy to understand. But I think that is due 
  to the fact that Imap is a *very* complex protocol. Pop3 is breeze 
against that.
I have seen a compatibility chart for the existing code that looks quite 
impressive.

I suggest the following steps:

1. Implementing a backend for the existing code. For me that is 
unavoidable before further steps. Javamail has everything that is needed 
for that and it shouldn't be too much work. Before starting a big 
discussion: I'm just talking about a wrapper for the existing 
interfaces. No serious design decision for Javamail is made at this point.

2. Documentation for the existing code. Maybe some fancy UML, or just 
prose. Just how it works and how components are interacting. I think it 
is important to understand the existing code before making too much 
changes to it.

3. Discussing the existing architecture and talk about an adequate backend.

Joachim

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Imap2 proposal Was: I would like to contribute...

Posted by Norman Maurer <nm...@byteaction.de>.

Am Freitag, den 19.05.2006, 12:40 +0200 schrieb Joachim Draeger:
> Hi Stefano,
> 
> Stefano Bagnara wrote:
> 
> > I will try to submit soon an updated imap2 proposal (updated to build 
> > against the current trunk), so you'll have an updated source to start 
> > your work from!
> 
> I have already made some efforts in that direction. The main problem for 
> me was the in memory store because I need something to "touch" when 
> working with code. I guess many people feel the same and that's a reason 
> why there is so less success with it.
> So I began to fix it to let it compile against trunk and added a, guess 
> what, Javamail backend. For traceability I tried to touch as few of the 
> existing code as possible. I wanted to clean my code a bit before 
> publishing it. But if people are eager I could put out what I have in 
> the next week, okay?

Sure upload your work to jira. We intressted in such work .. Maybe we
can help clear up things after read the sourcecode..

> 
> At the moment my backend is not very stable and it is only supporting a 
> few operations.
> The existing frontend part of the Imap2 proposal looks quite 
> sophisticated even it is not easy to understand. But I think that is due 
>   to the fact that Imap is a *very* complex protocol. Pop3 is breeze 
> against that.
> I have seen a compatibility chart for the existing code that looks quite 
> impressive.
> 
> I suggest the following steps:
> 
> 1. Implementing a backend for the existing code. For me that is 
> unavoidable before further steps. Javamail has everything that is needed 
> for that and it shouldn't be too much work. Before starting a big 
> discussion: I'm just talking about a wrapper for the existing 
> interfaces. No serious design decision for Javamail is made at this point.
> 
> 2. Documentation for the existing code. Maybe some fancy UML, or just 
> prose. Just how it works and how components are interacting. I think it 
> is important to understand the existing code before making too much 
> changes to it.
> 
> 3. Discussing the existing architecture and talk about an adequate backend.
> 
> Joachim

Bye
Norman