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 Javam
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
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
Javam
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 s
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
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
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 rea
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 <[EMAIL PROTECTED]> wrote: I will try to help as much as i can..
IMAP support is really a needed
feature for an "enterprise" mailse
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
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 que
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
-
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
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() meth
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... t
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
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 ther
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 c
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 interfa
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: [EMAIL PROTECTED]
For additional commands,
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 happe
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
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
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
On Tue, Apr 12, 2005 at 05:37:09AM -0400, Web Design by DraegoonZ wrote:
> Should I be building against the HEAD in cvs?
>
> Thanks.
I've been told that you should build with branch_2_1_fcs[1]. Someone
correct me if I'm wrong. :)
[1] http://svn.apache.org/repos/asf/james/server/branches/
--
GP
Well, according to my errors, most of the action is in
org\apache\james\security\KeyHolder.java.
Someone who has more experience with imap2 should take a look. I'm just
getting familiar with it and
can't make decisions on what functionality should and should not be there.
Should I be building
Hi folks,
I don't know the IMAP implementation at all but the BouncyCastle imports
look like tinkering with signing MimeMessage. If there are no other
dependency deleting the imports would be reasonable.
Cheers,
Siegfried Goeschl
Jason Webb wrote:
Well, possibly not!
I've only been building the
Well, possibly not!
I've only been building the IMAP2 tree against the HEAD in cvs (yes it is
that old) and this doesn't use the Bouncycastle stuff
-- Jason
> -Original Message-
> From: Web Design by DraegoonZ [mailto:[EMAIL PROTECTED]
> Sent: 11 April 2005 22:41
> To: server-dev@james.ap
---|
|
|
| To: "James Developers List" <[EMAIL PROTECTED]>
|
| cc:
> I'm very leery of distracting a push to get IMAP implemented to
> another extended design thread.
As long as we can keep it isolated, sure. I just want us to have the
flexiblity to look at our design decisions coherently down the road.
> > I would also like to see the system support better opt
Noel J. Bergman wrote:
defining a standard API for IMAP mail store is great.
Revising an API for mail stores, period. Right now we don't have one to
delete, for example, when a user is no longer served. However, I am not
entirely sure where best to do some of this. For example, if JNDI were
mand
> defining a standard API for IMAP mail store is great.
Revising an API for mail stores, period. Right now we don't have one to
delete, for example, when a user is no longer served. However, I am not
entirely sure where best to do some of this. For example, if JNDI were
mandatory for User Repos
Adam Fowler wrote:
I have now successfully managed to get Alex's Maildir code working with
James. Or at least I think it's working! My system uses IMAP so I need to
test it through that, unfortunately the IMAP2 proposal code uses an in
memory store instead of using the configured Maildir inboxRepos
32 matches
Mail list logo
