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 (JIRA)" <se...@james.apache.org> on 2006/06/02 16:56:29 UTC
[jira] Created: (JAMES-521) Mail/Spool/Message repositories
refactoring
Mail/Spool/Message repositories refactoring
-------------------------------------------
Key: JAMES-521
URL: http://issues.apache.org/jira/browse/JAMES-521
Project: James
Type: Task
Components: James Core, MailStore & MailRepository
Reporter: Stefano Bagnara
Assigned to: Stefano Bagnara
Fix For: 2.4.0
- Deprecated MailRepository
- Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
- Do some experimentation on the spoolrepository interface:
- MessageKey created while storing, and not userprovided.
- Split store in insert / update methods.
- Introduce message moving/cloning between repositories: moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be introduced at repository level when the 2 repositories share the storage medium.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Stefano Bagnara <ap...@bago.org>.
Joachim Draeger wrote:
>> - MessageKey created while storing, and not userprovided.
>
> This would make implementation of existing standard a lot easier. Are
> there disadvantages? When I store the same message into different
> repositories I've to care about the repository keys myself when I want
> to access them again. Instead of using my own. Does this happen in James
> reality?
Imho we don't use the repositories this way now. So it is safe to do
that change. But I also think that real problems are also found when we
put our hands in the code and try to do that.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Stefano Bagnara (JIRA) schrieb:
> - Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
The biggest design deficiency of Javamail is the lack of interfaces. That's why
using javamail means being limited in hierarchy, and being unable to completely
replace implementations.
Because we need only a subset of the Javamail capabilities it maybe better to
concentrate on the main requirements.
On the other hand we should always keep Javamail in mind to make a compatibility
layer possible.
There are also efforts made implementing Javamail for Apache. I think Geronimo
needs it to be fully JEE 1.4 compliant? Maybe it is an option not to use
Javamail API 1:1 as storing layer but share some code with them
> - MessageKey created while storing, and not userprovided.
This would make implementation of existing standard a lot easier. Are there
disadvantages? When I store the same message into different repositories I've to
care about the repository keys myself when I want to access them again. Instead
of using my own. Does this happen in James reality?
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Stefano Bagnara wrote:
>>> An alternative is (if we really care about switching implementations)
>>> is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
>>> we could code share (as you say), or whatever's appropriate.
>> There could be intersections. There are algorithms needed for IMAP
>> for searching folders and messages. This algorithms are required by
>> JavaMail, too. So maybe not use JavaMail directly, but share
>> implementations with Apache JavaMail in a subordinate API. That way we
>> could avoid the client overhead of JavaMail.
> I don't understand how this discussion may be related to geronimo
> javamail implementation. When I talk of Javamail *Store* implementation
> I talk about a "plugin" to javamail, not a Javamail implementation itself.
> We already use sun javamail implementation and most of James will
> currently don't work so fine with different implementations, btw we
> don't need it anyway (now).
I fully agree that there is no reason of talking about switching JavaMail
implementation. I only propose to look at the JavaMail efforts at Geronimo to
see if there are any intersections to share code. E.g. searching messages and
folders. I wouldn't like to utilize JavaMail for that directly.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Stefano Bagnara <ap...@bago.org>.
Joachim Draeger wrote:
> Serge Knystautas schrieb:
>
>>> The biggest design deficiency of Javamail is the lack of interfaces.
>>> That's why
>>> using javamail means being limited in hierarchy, and being unable to
>>> completely
>>> replace implementations.
>>
>> This is an interesting point... should we create interfaces that
>> mirror the method signature on JavaMail, and make a proxy impl that is
>> wraps the JavaMail impl?
>
> I don't think we need complete JavaMail in the background. But many
> things will be similar because of similar requirements. So we shouldn't
> do things completely different if there is no need to.
Imho we don't need a *JavaMail Implementation* but we may need to write
our own Javamail "Protocol provider" of type "Store" to access a local
message repository via standard interfaces.
You discussed this in 2003 (Noel proposed it).
I think that we should write James interfaces for the HIerarchical
message repository to be easily implemented as a wrapper over a javamail
store.
As Joachim already pointed out we don't need the event mechanism and
other features exposed by JavaMail, so we can simply expose our own
interface subset based on Javamail (this is a starting point: we can
refactor this if we need it).
This will make it much more easy to change things in future and we don't
bind too much to javamail (that is not under our control).
>> An alternative is (if we really care about switching implementations)
>> is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
>> we could code share (as you say), or whatever's appropriate.
>
> There could be intersections. There are algorithms needed for IMAP for
> searching folders and messages. This algorithms are required by
> JavaMail, too. So maybe not use JavaMail directly, but share
> implementations with Apache JavaMail in a subordinate API. That way we
> could avoid the client overhead of JavaMail.
>
> Joachim
I don't understand how this discussion may be related to geronimo
javamail implementation. When I talk of Javamail *Store* implementation
I talk about a "plugin" to javamail, not a Javamail implementation itself.
We already use sun javamail implementation and most of James will
currently don't work so fine with different implementations, btw we
don't need it anyway (now).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Serge Knystautas schrieb:
>> The biggest design deficiency of Javamail is the lack of interfaces.
>> That's why
>> using javamail means being limited in hierarchy, and being unable to
>> completely
>> replace implementations.
>
> This is an interesting point... should we create interfaces that
> mirror the method signature on JavaMail, and make a proxy impl that is
> wraps the JavaMail impl?
I don't think we need complete JavaMail in the background. But many things will
be similar because of similar requirements. So we shouldn't do things completely
different if there is no need to.
> An alternative is (if we really care about switching implementations)
> is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
> we could code share (as you say), or whatever's appropriate.
There could be intersections. There are algorithms needed for IMAP for
searching folders and messages. This algorithms are required by JavaMail, too.
So maybe not use JavaMail directly, but share implementations with Apache
JavaMail in a subordinate API. That way we could avoid the client overhead of
JavaMail.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Serge Knystautas <sk...@gmail.com>.
On 6/2/06, Joachim Draeger <jd...@joachim-draeger.de> wrote:
> The biggest design deficiency of Javamail is the lack of interfaces. That's why
> using javamail means being limited in hierarchy, and being unable to completely
> replace implementations.
This is an interesting point... should we create interfaces that
mirror the method signature on JavaMail, and make a proxy impl that is
wraps the JavaMail impl?
An alternative is (if we really care about switching implementations)
is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
we could code share (as you say), or whatever's appropriate.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-521) Mail/Spool/Message repositories
refactoring
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ http://issues.apache.org/jira/browse/JAMES-521?page=all ]
Stefano Bagnara updated JAMES-521:
----------------------------------
Fix Version/s: Trunk
(was: Next Major)
> Mail/Spool/Message repositories refactoring
> -------------------------------------------
>
> Key: JAMES-521
> URL: http://issues.apache.org/jira/browse/JAMES-521
> Project: James
> Issue Type: Task
> Components: MailStore & MailRepository, James Core
> Reporter: Stefano Bagnara
> Assigned To: Stefano Bagnara
> Fix For: Trunk
>
>
> - Deprecated MailRepository
> - Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
> - Do some experimentation on the spoolrepository interface:
> - MessageKey created while storing, and not userprovided.
> - Split store in insert / update methods.
> - Introduce message moving/cloning between repositories: moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be introduced at repository level when the 2 repositories share the storage medium.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-521) Mail/Spool/Message repositories
refactoring
Posted by Stefano Bagnara <ap...@bago.org>.
Well, I have so much things to do that I don't really know when I will
be able to look at this.
Maybe the best solution would be to use something like your scripting
mailets as a start because I'm not sure on the correct way to implement
placeholders and how to decide what placeholders to publish to that very
mailet.
Or maybe we should simply move the repository locator to an overridable
method of the ToMultiRepository and provide many overriding
implementations for the most common usages ToTimeBasedRepository,
ToDomainRepository, ToFullAddressRepository...
I really don't know... (too much things to think now, and maybe my
quarter of brain can't help you to reach a "full brain" ;-) ).
Stefano
Guillermo Grandes wrote:
> ohhhh :-)'', very cool, when? when? when? ;-)
> you need help with this? I have two hands! and half brain (~):-P
>
> --- Guillermo
>
>> Stefano Bagnara commented on JAMES-521:
>> ---------------------------------------
>>
>> Guillermo, I'd like to add the feature you're proposing to the
>> ToMultiRepository mailets I introduced in version 2.3.
>> Currently that mailet simply use the localpart of the recipient as
>> destination for the message but it would be cool to be able to specify
>> the destination using variables. People would need to use full email
>> address or simply the domain part as name of the repository, or could
>> use "file://var/incoming/${currentyear}${currentmonth}". By default it
>> would be ${inboxrepository}/${localpart}.
>> Please note that the ${variable} is only an example and we may use any
>> other way to dynamically declare the final repository.
>> (See comments in JAMES-414 about this)
>>
>>> Mail/Spool/Message repositories refactoring
>>> -------------------------------------------
>>>
>>> Key: JAMES-521
>>> URL: http://issues.apache.org/jira/browse/JAMES-521
>>> Project: James
>>> Issue Type: Task
>>> Components: James Core, MailStore & MailRepository
>>> Reporter: Stefano Bagnara
>>> Assigned To: Stefano Bagnara
>>> Fix For: Trunk
>
>
> ---------------------------------------------------------------------
> 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: [jira] Commented: (JAMES-521) Mail/Spool/Message repositories refactoring
Posted by Guillermo Grandes <gu...@gmail.com>.
ohhhh :-)'', very cool, when? when? when? ;-)
you need help with this? I have two hands! and half brain (~):-P
--- Guillermo
> Stefano Bagnara commented on JAMES-521:
> ---------------------------------------
>
> Guillermo, I'd like to add the feature you're proposing to the
> ToMultiRepository mailets I introduced in version 2.3.
> Currently that mailet simply use the localpart of the recipient as
> destination for the message but it would be cool to be able to specify the
> destination using variables. People would need to use full email address
> or simply the domain part as name of the repository, or could use
> "file://var/incoming/${currentyear}${currentmonth}". By default it would
> be ${inboxrepository}/${localpart}.
> Please note that the ${variable} is only an example and we may use any
> other way to dynamically declare the final repository.
> (See comments in JAMES-414 about this)
>
>> Mail/Spool/Message repositories refactoring
>> -------------------------------------------
>>
>> Key: JAMES-521
>> URL: http://issues.apache.org/jira/browse/JAMES-521
>> Project: James
>> Issue Type: Task
>> Components: James Core, MailStore & MailRepository
>> Reporter: Stefano Bagnara
>> Assigned To: Stefano Bagnara
>> Fix For: Trunk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-521) Mail/Spool/Message repositories
refactoring
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ http://issues.apache.org/jira/browse/JAMES-521?page=comments#action_12439011 ]
Stefano Bagnara commented on JAMES-521:
---------------------------------------
Guillermo, I'd like to add the feature you're proposing to the ToMultiRepository mailets I introduced in version 2.3.
Currently that mailet simply use the localpart of the recipient as destination for the message but it would be cool to be able to specify the destination using variables. People would need to use full email address or simply the domain part as name of the repository, or could use "file://var/incoming/${currentyear}${currentmonth}". By default it would be ${inboxrepository}/${localpart}.
Please note that the ${variable} is only an example and we may use any other way to dynamically declare the final repository.
(See comments in JAMES-414 about this)
> Mail/Spool/Message repositories refactoring
> -------------------------------------------
>
> Key: JAMES-521
> URL: http://issues.apache.org/jira/browse/JAMES-521
> Project: James
> Issue Type: Task
> Components: James Core, MailStore & MailRepository
> Reporter: Stefano Bagnara
> Assigned To: Stefano Bagnara
> Fix For: Trunk
>
>
> - Deprecated MailRepository
> - Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
> - Do some experimentation on the spoolrepository interface:
> - MessageKey created while storing, and not userprovided.
> - Split store in insert / update methods.
> - Introduce message moving/cloning between repositories: moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be introduced at repository level when the 2 repositories share the storage medium.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-521) Mail/Spool/Message repositories
refactoring
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ http://issues.apache.org/jira/browse/JAMES-521?page=all ]
Norman Maurer updated JAMES-521:
--------------------------------
Fix Version: 3.0
(was: 2.4.0)
> Mail/Spool/Message repositories refactoring
> -------------------------------------------
>
> Key: JAMES-521
> URL: http://issues.apache.org/jira/browse/JAMES-521
> Project: James
> Type: Task
> Components: MailStore & MailRepository, James Core
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 3.0
>
> - Deprecated MailRepository
> - Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
> - Do some experimentation on the spoolrepository interface:
> - MessageKey created while storing, and not userprovided.
> - Split store in insert / update methods.
> - Introduce message moving/cloning between repositories: moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be introduced at repository level when the 2 repositories share the storage medium.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-521) Mail/Spool/Message repositories
refactoring
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated JAMES-521:
----------------------------------
Assignee: (was: Stefano Bagnara)
Removed myself from assignee: i'm not willing to work on this in the near future.
> Mail/Spool/Message repositories refactoring
> -------------------------------------------
>
> Key: JAMES-521
> URL: https://issues.apache.org/jira/browse/JAMES-521
> Project: James
> Issue Type: Task
> Components: James Core, MailStore & MailRepository
> Reporter: Stefano Bagnara
> Fix For: Trunk
>
>
> - Deprecated MailRepository
> - Introduce a MessageRepository interface for MimeMessages (not Mail objects) to replace the current MailRepository usage: we could even use JavaMail Store/Folders but maybe we should have our own interface and a wrapper.
> - Do some experimentation on the spoolrepository interface:
> - MessageKey created while storing, and not userprovided.
> - Split store in insert / update methods.
> - Introduce message moving/cloning between repositories: moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be introduced at repository level when the 2 repositories share the storage medium.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org