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 Sid Stuart <si...@weaselworks.com> on 2003/04/30 16:46:41 UTC
Re: Repositories (Design suggestion)
Hi,
I spent some time looking through the archives last night, reading
through the Repository and "JavaMail as the message store" threads. I
see three issues regarding the repository in those and other recent
discussions,
There is a desire by some developers to provide alternate persistence
implementations for the mailet.Mail class (Harmeet Bedi - JNDI,
Vincent de Lau - RDBMS? ) that are constrained by the current repository
definitions in the apache.mailet package. They will also be
constrained by the
selection of the JavaMail Store abstract class as an interface to
persistence.
There is no persistence support for the NNTP server defined in
apache.mailet. The support provided by JavaMail Store may not be
a good fit for that server.
There is general interest in using JNDI/LDAP to store User data. What
steps should be taken for James to support this though?
I would like to suggest a design approach to resolve these issues:
The low-level definition of repositories should be be abstracted out of
apache.mailet completely (no MailRepository, no SpoolRepository, no
UserRepository). Instead, a new Interface called Persistent should be
provided. This interface would be implemented by objects whose
properties need persistence (Mail, User, NTTPArticle...). A suggested
definition of the Persistent Interface is provided as an attachment to
this document in source and JavaDoc formats. A helper Interface,
Identifier, is also attached.
This approach defines a consistent persistence interface that can be
easily shared across all servers. It provides the class implementer with
substantial freedom in choosing a persistence mechanism. It also allows
the class implementor to easily add properties to a persisted class as
no repository definition need be considered.
Sid
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> I don't know about siege scripts, but often a lot of this is stored in
> "special" IMAP folders. Calendar objects, blah blah blah... I know
> CommuniGate has an Outlook MAPI plugin to let you use any IMAP server as
> an exchange server, and that's how they do it.
Exchange\Outlook stores a lot of extra information in the message stores:
- folder view settings
- server-side Inbox agents (similar to SIEVE scripts)
- custom forms
- free-busy information (Public folder, so you don't have to have access to
a users mailbox to see if he/she is available.)
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Noel J. Bergman wrote:
>AIUI, JavaMail doesn't provide support for metadata unless we hack it by
>storing "invisible" messages containing the metadata. I agree that we
>should provide similar functionality, but it is unclear that we should store
>our metadata in JavaMail just because Exchange stores metadata in their
>message stores.
>
>Thoughts?
>
>
>
JavaMail does provide limited support for metadata using the Flags
class: /The Flags class represents the set of flags on a Message. Flags
are composed of predefined system flags, and user defined flags. /
http://java.sun.com/products/javamail/1.3/docs/javadocs/index.html
Unfortunately, it is defined as a class and not an interface....
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: MS Exchange SDK links
Posted by "Noel J. Bergman" <no...@devtech.com>.
Thanks.
I did find what I was looking for at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/exchserv/ht
ml/schmahlp_927n.asp.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: MS Exchange SDK links
Posted by Vincent de Lau <vi...@delau.nl>.
> I added this material to
> http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/ExchangeServerNotes.
> Please feel free to elaborate by editing that page.
I will add this comment to the wiki as well:
> Looking at the documentation for the directory schema, which
> fills the same
> role that JNDI would fill for James, I must be missing it. I see a
> statement of what the schema provides, but not the actual schema
> definition.
The tree can't sync when using the schema link. You can navigate to the
schema definition as follows:
Enterprise Development
Development
Windows Server System
Microsoft Exchange Server
Microsoft Exchange Server 5.5
SDK Documentation
Microsoft Exchange Server
Microsoft Exchange Server Programmer's Reference
Reference
Directory Schema
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: MS Exchange SDK links
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincent,
I added this material to
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/ExchangeServerNotes.
Please feel free to elaborate by editing that page.
Looking at the documentation for the directory schema, which fills the same
role that JNDI would fill for James, I must be missing it. I see a
statement of what the schema provides, but not the actual schema definition.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
MS Exchange SDK links
Posted by Vincent de Lau <vi...@delau.nl>.
Below I've posted some links to MSDN regarding Exchange. Large parts are
very well documented. Others are not...
MS Exchange 5.5 SDK
http://msdn.microsoft.com/library/en-us/exchanchor/htms/msexchsvr_e55.asp
Exchange 5.5 directory schema
http://msdn.microsoft.com/library/en-us/exchserv/html/schema_4mg1.asp
MS Exchange 2000 SDK
http://msdn.microsoft.com/library/en-us/exchanchor/htms/msexchsvr_e2k.asp
Please keep in mind that Exchange 2000 uses a lot of functionality from the
Windows 2000 Active Directory. Exchange 5.5 uses it's own directory.
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>> I don't know about siege scripts, but often a lot of this is stored in
>> "special" IMAP folders. Calendar objects, blah blah blah... I know
>> CommuniGate has an Outlook MAPI plugin to let you use any IMAP server as
>> an exchange server, and that's how they do it.
I'll stand corrected, and will have a look at RFCs 2426, 2445 and 2446.
Mind you, a Folder is a view, so it had occured to me that a special Folder
could derive its content on demand. I just thought that if a service wanted
to act on groupware data, it might be more optimally stored elsewhere rather
than just storing the data as messages in a folder.
> Exchange\Outlook stores a lot of extra information in the message stores:
> - folder view settings
> - server-side Inbox agents (similar to SIEVE scripts)
> - custom forms
> - free-busy information (Public folder, so you don't have to have
> access to a users mailbox to see if he/she is available.)
AIUI, JavaMail doesn't provide support for metadata unless we hack it by
storing "invisible" messages containing the metadata. I agree that we
should provide similar functionality, but it is unclear that we should store
our metadata in JavaMail just because Exchange stores metadata in their
message stores.
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> IMO, non-message items would be stored via JNDI (or JDBC), rather than
> JavaMail, by those mailets or other services that managed them.
I don't know about siege scripts, but often a lot of this is stored in
"special" IMAP folders. Calendar objects, blah blah blah... I know
CommuniGate has an Outlook MAPI plugin to let you use any IMAP server as
an exchange server, and that's how they do it.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
I was really pleased to hear your ideas and agreement. When I earlier tried
to promote recasting org.apache.mailet as a generic package, and subpackages
for various messaging schemes, the idea didn't go over well. Admittedly, I
didn't have a good use case to exemplify why, but perhaps we do now.
Vincent's example is good, but perhaps a bit misleading. AIUI, the type of
content he was using would generally be embedded in a message, as opposed to
being the message, and then pulled from the message for processing.
I believe that a messaging model can be generalized to consist of content
representation (Message), address representation (Address), and transport
protocol (possibly opaque). The base mailet package would provide abstract
notions of the model. Then we would have subpackages that provided
specialized notions of those model elements, similar to how this is managed
in other Java packages.
> corresponding abstraction of repositories to store items not Mail.
IMO, non-message items would be stored via JNDI (or JDBC), rather than
JavaMail, by those mailets or other services that managed them.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Noel,
> > I've tried to canvass support for extending it to cover NNTP
>
> What changes do you believe are necessary? I don't disagree at
> all with the
> premise.
More or less only greater abstraction than the Mail class as the basic unit of messages, as postulated here tonight by Serge (or Vincent?)with "item", and corresponding abstraction of repositories to store items not Mail.
> The primary changes that I'd like to see to the Mailet API are (a) generic
> package and specific package(s) as necessary (ala javax.servlet and
> javax.servlet.http), and (b) pulling out areas that are not core to the
> message processing API. My view is that the Mailet Specification is a
> superset of the Mailet API. For example, specifying how JNDI can
> be used to
> locate users, mailboxes, etc., and how to use JavaMail to store/retrieve
> messages could be part of the Specification without having to be
> part of the
> API. Lightweight Mailet containers that just process messages within a
> pipeline, without needing either user repositories or message
> stores, would
> not need to offer those features.
I pretty much agree with all that.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I've tried to canvass support for extending it to cover NNTP
What changes do you believe are necessary? I don't disagree at all with the
premise.
> I'm trying to extend it now to become less dependant on James
> and easier for 3rd party implementors.
+1
> What I am saying is that I disagree with your principle of
> accessing storage through the message class.
Mixing the domains of message content and message storage in a single class
seems fundamentally flawed. The Message.saveChanges method is simply an
opaque hint that changes made to a message should be committed.
> The Mailet API is a message processing API.
+1
The primary changes that I'd like to see to the Mailet API are (a) generic
package and specific package(s) as necessary (ala javax.servlet and
javax.servlet.http), and (b) pulling out areas that are not core to the
message processing API. My view is that the Mailet Specification is a
superset of the Mailet API. For example, specifying how JNDI can be used to
locate users, mailboxes, etc., and how to use JavaMail to store/retrieve
messages could be part of the Specification without having to be part of the
API. Lightweight Mailet containers that just process messages within a
pipeline, without needing either user repositories or message stores, would
not need to offer those features.
I appreciate a desire to see a demonstrable use case before repackaging the
org.apache.mailet. It seems to me that NNTP provides a use case because a
newsgroup address doesn't match an e-mail address, even though both can use
MimeMessage as the data representation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Sid,
> What I (and I think Vincent) want, is to have the definition of that
> custom operation definition facility extended to support operations on
> all the data stored in James. What you see in my postings is not a lack
> of understanding of the difference between the Mailet definition and the
> SpoolManager implementation. It is a lack of acceptance of the
> limitations of the Mailet definition.
No, I don't believe that I lack acceptance of the limitations of the Mailet API, I've tried to canvass support for extending it to cover NNTP before now, I'm trying to extend it now to become less dependant on James and easier for 3rd party implementors.
What I am saying is that I disagree with your principle of accessing storage through the message class.
Heres why:
The Mailet API is a message processing API.
Like every similar API I have worked with it can be described thus:
Messages are discrete packets of data.
Messages can enter the system through sources and depart through sinks. During their progress through the system they can be acted upon by processors. The flow of messages through the system can be controlled by filters and valves.
In order to build a system which performs useful work one associates sources, processors, filters and sinks.
In James this pattern is realised in the following way:
Messages are realised by the Mail class.
Sources include SMTP daemon, FetchPOP, and internal Mailets.
Messages are injected into the spoolmanager by the sources.
The spoolmanager controls the flow of these messages, processors are realised by Mailet and filters by Matcher.
Messages eventually end up at a sink, and leave the system. sinks are represented by Mailets which either kill the message or move it to another sub-system, these subsystems can generally be categorised as transport protocols or repositories.
I don't believe that a system which is so intuitively simple to understand would benefit from being re-designed to remove the sinks.
And if we were to follow your design imperative would we also have to have messages provide their own transport?
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > mail message processing, and James an MTA implementing the Mailet API.
> I have read this statement in mail from two of the James developers.
> *James is not an MTA*.
Please see the charter for the James project: "James is a 100% Java mail and
news server, evolving into a complete electronic messaging solution that
integrates the range of IETF protocols, such as SMTP, POP3, IMAP, NNTP, and
XXMP with unified user account management and open storage mechanisms."
(http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-james/proposals/TLP/pr
oposal-letter.txt?rev=1.11)
> In addition to [MTA feaures], it provides a faciity
> to define custom operations on Mail messages.
In other words: the Mailet specification.
> What I (and I think Vincent) want, is to have the definition of that
> [Mailets] extended to support operations on all the data stored in
> James.
In your review of the archives, I don't suppose that you noticed that I had
proposed that the Mailet API be modified to follow the javax.servlet,
javax.servlet.http pattern? So far there hasn't been a proven need, but I
do expect that it will eventually happen.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Vincent de Lau wrote:
> May I propose to rephrase messages to items? An item would be an arbitrary
> piece of data with MIME headers to specify how to interpret the item. An
> Item might be a text/rfc822 message or anything else. I'm thinking towards
> iCalendar/iCAP, vCards etc, or even SIEVE scripts. Allowing a store to store
> arbitrary items would give service implementers a better way to reuse the
> store components for their needs.
Makes sense. So does javax.mail.MimeMessage fully implement/define your
'items'? If so, we're almost done. :)
> A spool would only handle text/rfc822 messages, not items.
I understand from usage that this is true. However, to me spool is
additive (not restrictive) to 'items'. spool would need the SMTP meta
information, namely:
- recipient(s)
- sender
- remote host
- other protocol details we might want to know
- generic message "attributes"
The last 2 points... protocol details might include whether this message
was sent by someone who used SMTP AUTH, or who knows what else you might
gather. Generic message attributes was to have a String->Object
(Serializable) Map on each Mail object. This would allow inter-mailet
communication, similar to the servlet API's Session object has attributes.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm thinking towards iCalendar/iCAP, vCards etc, or even SIEVE scripts.
The kind of thing that you're talking about would probably be stored in
JNDI, not in JavaMail. A user's groupware data would be associated with his
JNDI user entry. Likewise, there is a bullet item in the Wiki regarding
"User-specific Pipeline". One simple thing could be a Sieve package that
ran SIEVE scripts associated from a user's record.
> Allowing a store to store arbitrary items would give service
> implementers a better way to reuse the store components for
> their needs.
Why do you think I am pushing JNDI? JNDI provides federated, hierarchical,
named, searchable storage of named entities and their named attributes.
Where JNDI is not the optimal access mechanism, the most likely solution
will be a JDBC connection, which could be acquired via JNDI.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
>
> > - I'm not sure if it would be usefull to place the spool folders in this
> > namespace. I suppose it doesn't hurt to do so, but I think that a spool
> > folder and a store folder have different needs. A spool folder
> would also
> > have to store MTA data (sender, recipient etc.) and should be
> fast. Single
> > instance storage on spools would help.
>
> How spool interacts with this store has been a big stumbling block...
> and actually your point is so simple, I guess we've been missing it.
>
> If I can restate, we use a single message stores for just that..
> messages. That would support POP3/IMAP4 mailboxes, NNTP, and whatever
> else someone wanted (archives of mailing lists, whatever).
May I propose to rephrase messages to items? An item would be an arbitrary
piece of data with MIME headers to specify how to interpret the item. An
Item might be a text/rfc822 message or anything else. I'm thinking towards
iCalendar/iCAP, vCards etc, or even SIEVE scripts. Allowing a store to store
arbitrary items would give service implementers a better way to reuse the
store components for their needs.
> Separate from this, we have spool stores. Spools do not need to be
> hierarchical, they need that extra data. We have in the past used the
> same implementations for both spool and message (by having spool extend
> message), but this is a bit overkill for message, and in practice I
> don't know how often we reinject messages from a mailbox into
> processing, and if that even makes sense.
A spool would only handle text/rfc822 messages, not items.
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I proposed that we expand upon a proposal you had made in our talks with
> Bill Shannon, and create a ServerMimeMessage class that marshalls those
> attributes as X- headers.
Can you explain how Mail, ServerMimeMessage (and MimeMessage) relate?
You seemed to answer that ServerMimeMessage was what you would use in
place of a Mail <-> MimeMessage converter.
Sorry Noel, this delegating factory objects and all this just seem very
complicated, or maybe just jumping into the nitty gritty of the
implementation before explaining how these are used.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I proposed that we expand upon a proposal you had made in our talks with
> > Bill Shannon, and create a ServerMimeMessage class that marshalls those
> > attributes as X- headers.
> As I think you pointed out to someone else, the individual stores will
> implement the MimeMessage directly, so we can't enforce that a given
> JavaMail store we want to plug into James could support this.
The ServerMimeMessage would be created outside of a Store (e.g., in
SMTPHandler), and could add the additional attributes as X- headers. After
that, code could rely upon the presence of the X- headers on MimeMessage
instances, or we could provide a Factory that wraps a MimeMessage in a
ServerMimeMessage subclass, if and as necessary, that does the work. But I
would like to avoid some of the issues we have with MimeMessageWrapper.
>>>you could (and to some extent should) store this data in
>>>the message headers (Recieved:, Delivered-To: and maybe
>>>some x- header).
>> That is my proposed solution to preserve full fidelity.
>Yeah, X-headers maybe. Instead of ServerMimeMessage (since we can't
>really do that with the API as is and the way Java simplifies OO), what
>about a utility class? Convert Mail to MimeMessage, and vice versa.
Why can't we? ServerMimeMessage extends MimeMessage. Our own store
implementations can create ServerMimeMessage instances directly; for others
we could use a DelegatingServerMimeMessage as described above. That utility
class you mention could be a Factory that takes a MimeMessage, sees if it
needs to be wrapped or not, and returns a ServerMimeMessage (either the
original or a wrapper), ensuring consistency for the client code.
FWIW, I believe that we'll still want Store service providers that are
better optimized that I have seen in the code for those I've read.
Once we start using JavaMail, I reiterate my suggestion that we setup a
subproject for JavaMail service providers, and invite the authors to
contribute. We've already had some positive feedback on the idea. You've
noted a number of times that JavaMail is still more client than server
oriented. I think that having a subproject here for service providers would
help the process of getting more server oriented service providers.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I proposed that we expand upon a proposal you had made in our talks with
> Bill Shannon, and create a ServerMimeMessage class that marshalls those
> attributes as X- headers.
As I think you pointed out to someone else, the individual stores will
implement the MimeMessage directly, so we can't enforce that a given
JavaMail store we want to plug into James could support this.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> If we want to support most established mailbox formats, we're going to
> lose the data. For example, mbox cannot store (all) the extra junk of
> the Mail object beyond the MimeMessage
I proposed that we expand upon a proposal you had made in our talks with
Bill Shannon, and create a ServerMimeMessage class that marshalls those
attributes as X- headers.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I would tread carefully before commiting us to a data transformation that loses information in the way this proposed spool->mail repository trnasformation would.
I would agree, but...
If we want to support most established mailbox formats, we're going to
lose the data. For example, mbox cannot store (all) the extra junk of
the Mail object beyond the MimeMessage... it stores recipient, sender,
time, but not remote host (well, buried in received headers), mail
attributes, other stuff we might want).
Workarounds might be:
1. Inform/guide admins, so they create numerous "holding" spools that
don't do anything (messages sit unprocessed), so an admin can collect
them and then reinsert it later on.
2. Maybe make a mailet that persists useful "extra junk" to certain
Headers, and then another that takes those headers and puts the "extra
junk" back in place.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>I don't think that you would need this information after you deliver a
>>message to a store
>
> It is a frequent request to be able to re-queue messages accidentally
> trapped in spam or error.
Yes, think of these as alternate spools... ones that just weren't
getting processed.
>>you could (and to some extent should) store this data in
>>the message headers (Recieved:, Delivered-To: and maybe
>>some x- header).
>
> That is my proposed solution to preserve full fidelity.
Yeah, X-headers maybe. Instead of ServerMimeMessage (since we can't
really do that with the API as is and the way Java simplifies OO), what
about a utility class? Convert Mail to MimeMessage, and vice versa.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't think that you would need this information after you deliver a
> message to a store
It is a frequent request to be able to re-queue messages accidentally
trapped in spam or error.
> you could (and to some extent should) store this data in
> the message headers (Recieved:, Delivered-To: and maybe
> some x- header).
That is my proposed solution to preserve full fidelity.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
>
> > Separate from this, we have spool stores. Spools do not need to be
> > hierarchical, they need that extra data. We have in the past used the
> > same implementations for both spool and message (by having spool extend
> > message), but this is a bit overkill for message, and in practice I
> > don't know how often we reinject messages from a mailbox into
> > processing, and if that even makes sense.
>
> I would tread carefully before commiting us to a data
> transformation that loses information in the way this proposed
> spool->mail repository trnasformation would.
I don't think that you would need this information after you deliver a
message to a store, but you could (and to some extent should) store this
data in the message headers (Recieved:, Delivered-To: and maybe some x-
header).
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
> Separate from this, we have spool stores. Spools do not need to be
> hierarchical, they need that extra data. We have in the past used the
> same implementations for both spool and message (by having spool extend
> message), but this is a bit overkill for message, and in practice I
> don't know how often we reinject messages from a mailbox into
> processing, and if that even makes sense.
I would tread carefully before commiting us to a data transformation that loses information in the way this proposed spool->mail repository trnasformation would.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
> someone will want to dump messages into a folder to webify
> mailing list archives using eyebrowse.
+1, thats me big perceived need here :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Vincent de Lau wrote:
> This is where I'm getting at. There are two concerns however:
> - Using seperate store implementations would make it harder or impossible to
> do single instance storage. However I think that consensus is reached in the
> James community that you want to be able to support several storage methods.
Yes, because of (mostly) integration and migration. Someone will want
to keep their existing mailbox folders from their previous server (maybe
qmail), and someone will want to dump messages into a folder to webify
mailing list archives using eyebrowse.
> - I'm not sure if it would be usefull to place the spool folders in this
> namespace. I suppose it doesn't hurt to do so, but I think that a spool
> folder and a store folder have different needs. A spool folder would also
> have to store MTA data (sender, recipient etc.) and should be fast. Single
> instance storage on spools would help.
How spool interacts with this store has been a big stumbling block...
and actually your point is so simple, I guess we've been missing it.
If I can restate, we use a single message stores for just that..
messages. That would support POP3/IMAP4 mailboxes, NNTP, and whatever
else someone wanted (archives of mailing lists, whatever).
Separate from this, we have spool stores. Spools do not need to be
hierarchical, they need that extra data. We have in the past used the
same implementations for both spool and message (by having spool extend
message), but this is a bit overkill for message, and in practice I
don't know how often we reinject messages from a mailbox into
processing, and if that even makes sense.
> There is another major issue involved with the virtual naming system: access
> control!
> How do you store this? Is that up to the store implementation or does the
> namespace manager provide that?
Good question. At first glance I would say each protocol implementation
would handle that on its own. That may be inadequate though. I don't
remember if JavaMail stores handle access control (either reading or
managing).
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> There is another major issue involved with the virtual naming system:
>>> access control!
>> Can you elaborate on your concern? What specific areas of access control
>> are you considering?
> When sharing folders, you should be able to specify who you want to give
> access to certain folders.
I wasn't sure if you were refering to application domain access control, or
talking about keeping authentication information for a database server, for
example, associated with someone's mailbox. Both can be done, but I wanted
a better idea of what issues you were considering.
> Just got a bright moment: should we be able to use JNDI to store ACL's?
My view is that there are only two types of stores that James v3 would use:
JNDI and JavaMail. JNDI for everything that isn't a message store, JavaMail
for the message stores. That being said, I would expect that there will be
a variety of resources stored in JNDI that are associated with some form of
authentication and authorization, e.g., user mailboxes, mailing list
moderator controls, etc.
>>>> I would expect two user APIs:
>>>> Authentication would be for SMTP auth, NNTP login, POP3/IMAP4 login
>>>> Mailbox/account info would be for POP3/IMAP4 accounts, maybe also
>>>> mailing lists
>>> I agree. Lets call one a 'user' and the other a 'recipient'.
>> Someone should produce the start of a data model, and then we can shuffle
>> things around.
> What kind of data model? A directory data model or Java
classes/interfaces?
An abstract data model, not interfaces.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> However, JNDI is a basic mechanism for named, searchable storage. We can
> put what we want into it as necessary.
>
> > There is another major issue involved with the virtual naming system:
> > access control!
>
> Can you elaborate on your concern? What specific areas of access control
> are you considering?
When sharing folders, you should be able to specify who you want to give
access to certain folders. I don't think you would like it if your co-worker
could access /user/me/private. Or a desk clerk to read /user/MrCEO/INBOX
Just got a bright moment: should we be able to use JNDI to store ACL's?
> > > I would expect two user APIs:
> > > Authentication would be for SMTP auth, NNTP login, POP3/IMAP4 login
> > > Mailbox/account info would be for POP3/IMAP4 accounts, maybe also
> > > mailing lists
> > I agree. Lets call one a 'user' and the other a 'recipient'.
>
> Someone should produce the start of a data model, and then we can shuffle
> things around.
What kind of data model? A directory data model or Java classes/interfaces?
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> There are two concerns however:
> - Using seperate store implementations would make it harder or impossible
to
> do single instance storage.
However, within a single store, you could have single instance storage.
That just requires the store to be smart about it. I outlined that for a
JavaMail store just the other day in an note on this list. So I think we'd
be in good shape.
For example, an administrator could use a JDBC-backed store for most user
mailboxes, but could use mbox for mailing list archives. There would be two
copies of a message. One in the JDBC store, and one in the mbox. When all
users in the JDBC store have deleted the message, it goes away, leaving just
the single copy in the mbox.
> I'm not sure if it would be usefull to place the spool folders in this
> namespace.
TBD. The idea is that a spooler is not a store, but rather may USE a store.
For example, if we used T-spaces, that provides its own persistence, and so
you don't need to replicate it.
However, JNDI is a basic mechanism for named, searchable storage. We can
put what we want into it as necessary.
> There is another major issue involved with the virtual naming system:
> access control!
Can you elaborate on your concern? What specific areas of access control
are you considering?
> > I would expect two user APIs:
> > Authentication would be for SMTP auth, NNTP login, POP3/IMAP4 login
> > Mailbox/account info would be for POP3/IMAP4 accounts, maybe also
> > mailing lists
> I agree. Lets call one a 'user' and the other a 'recipient'.
Someone should produce the start of a data model, and then we can shuffle
things around.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> I've proposed a single "virtual" message repository that I think is the
> same as what you're talking about. You would have:
If seen something along this line on the wiki.
> All mailets and any application/protocols would use this single
> "virtual" naming system. Per your email, '/news' might be another
> expected path.
>
> James would then "mount" implementations to these various directories,
> so you could have your mbox implementation stored in /var/mail handling
> '/mailbox', and maybe a local file implementation for /spool, and maybe
> a DB implementation for /spool/spam.
This is where I'm getting at. There are two concerns however:
- Using seperate store implementations would make it harder or impossible to
do single instance storage. However I think that consensus is reached in the
James community that you want to be able to support several storage methods.
- I'm not sure if it would be usefull to place the spool folders in this
namespace. I suppose it doesn't hurt to do so, but I think that a spool
folder and a store folder have different needs. A spool folder would also
have to store MTA data (sender, recipient etc.) and should be fast. Single
instance storage on spools would help.
> All this is just to address message repositories, and doesn't get to
> users. Ideally we could use JavaMail Store for the core message
> repository, but then would have to layer SMTP/spooling logic on top of
> this somehow.
There is another major issue involved with the virtual naming system: access
control!
How do you store this? Is that up to the store implementation or does the
namespace manager provide that?
> I would expect two user APIs:
> - authentication
> - mailbox/account info
>
> Authentication would be for SMTP auth, NNTP login, POP3/IMAP4 login, or
> whatever else. Mailbox/account info would be for POP3/IMAP4 accounts,
> maybe also mailing lists... this gets a bit murkier. But I think there
> are two distinct definitions of users that we need to make.
I agree. Lets call one a 'user' and the other a 'recipient'.
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Vincent de Lau wrote:
> You are partly right about my vision. In my opinion James should provide one
> interface to access all the stores, but James should also have complete
> control of what should be stored where. The current storeMessage() operation
> is pretty good, but might be renamed deliverLocaly(). James should make the
> decission where and how to store it. A message to a newsgroup might be
> posted in the '#news/' namespace of the store while a user message might be
> stored at '#user/username/INBOX'. I don't think a Mailet should be aware
> where the message is stored in the end. In a mailet perspective, a message
> is delivered to the store or passed on to the next hop in the transport
> chain.
Vincent,
I've proposed a single "virtual" message repository that I think is the
same as what you're talking about. You would have:
/spool
/spool/queue1
/spool/queue2
/spool/spam
...
/mailbox/foo/bar
/mailbox/fuu/ber
All mailets and any application/protocols would use this single
"virtual" naming system. Per your email, '/news' might be another
expected path.
James would then "mount" implementations to these various directories,
so you could have your mbox implementation stored in /var/mail handling
'/mailbox', and maybe a local file implementation for /spool, and maybe
a DB implementation for /spool/spam.
In addition to what you describe of not requiring mailets or protocols
to worry about where they are storing it, it also:
- makes admin tools simpler to write, since they just move/copy messages
between the virtual paths.
- allows an admin to temporarily mount a remote IMAP/news folder and
then transfer messages between servers that way.
- allow easy migration between different message store implementations.
All this is just to address message repositories, and doesn't get to
users. Ideally we could use JavaMail Store for the core message
repository, but then would have to layer SMTP/spooling logic on top of
this somehow.
I would expect two user APIs:
- authentication
- mailbox/account info
Authentication would be for SMTP auth, NNTP login, POP3/IMAP4 login, or
whatever else. Mailbox/account info would be for POP3/IMAP4 accounts,
maybe also mailing lists... this gets a bit murkier. But I think there
are two distinct definitions of users that we need to make.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Wednesday, April 30, 2003 9:19 PM
> To: James Developers List
> Subject: RE: Repositories (Design suggestion)
>
>
> Vincent
>
> > decission where and how to store it. A message to a newsgroup might be
> > posted in the '#news/' namespace of the store while a user
> > message might be
> > stored at '#user/username/INBOX'. I don't think a Mailet should be aware
> > where the message is stored in the end. In a mailet
> perspective, a message
> > is delivered to the store or passed on to the next hop in the transport
> > chain.
>
> Thanks, I like that, it helps crystalise something I've been
> trying to work towards.
>
> Theres a disjunct in James where the User repository
> specifications are refered to by name, but the Mail repositories
> are refered to by URI.
>
> This suggests to me that all repositories should be mapped to
> namespaces, and the namespaces alone made available to Mailets.
> Is that what you are getting at?
Yes. And even further: servers shouldn't have to be aware where and how
messages are stored. For instance a IMAP4 implementation should only have to
know where in the namespace a user mailbox starts.
In the specs I outlined earlier, recipient-namespace mappings are stored in
a directory. This also helps to seperate users from recipients. A recipient
in my opinion is broader then a user because it could also be a NNTP group,
public folder or a mailinglist.
Side note: I'm using the term 'mailbox' to refer to a set of folders that
belong to a user (eg #user/username) and 'inbox' to refer to the location
where new messages are injected into the users mailbox (eg
#user/username/INBOX).
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Danny Angus wrote:
> > Fine Noel, I guess I'm getting to the same page as everyone else now!
> > It would save you constantly having to explain these things to me if
> > you just cut to the > chase and did them! ;-)
> +1 :)
LOL You and Danny are going to be a PIMA. :-)
Actually, I'm really happy to see ldapd, and that could really help push
James forward. I knew how to store these things in JNDI, but until I would
have time to author a JNDI<->JDBC bridge, so that we had a place to store
the data, we had a problem. JNDI without a writeable service provider is
like having a storage interface without an engine.
ldapd, being embeddable in James, looks like it should provide all of that
for us. I'll start to run that by them. And I think that we should
absolutely encourage their addition to Incubator, and ask them to work with
us as a demonstration application.
And Aaron was going to work on putting org.apache.naming into James, but
appears to have gone walkabout.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> Fine Noel, I guess I'm getting to the same page as everyone else now!
> It would save you constantly having to explain these things to me if you just cut to the chase and did them! ;-)
+1 :)
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
>
> Fine Noel, I guess I'm getting to the same page as everyone else now!
> It would save you constantly having to explain these things to me
> if you just cut to the chase and did them! ;-)
http://java.sun.com/products/jndi/tutorial/
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Fine Noel, I guess I'm getting to the same page as everyone else now!
It would save you constantly having to explain these things to me if you just cut to the chase and did them! ;-)
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 30 April 2003 21:21
> To: James Developers List
> Subject: RE: Repositories (Design suggestion)
>
>
> > Theres a disjunct in James where the User repository specifications
> > are refered to by name, but the Mail repositories are refered to by
> > URI.
>
> > This suggests to me that all repositories should be mapped to
> > namespaces, and the namespaces alone made available to Mailets.
>
> Hence JNDI. JNDI == Java *Naming* and *Directory* interface. I am really
> suggesting that JNDI provide that functionality to James. We can look
> things up by name, path, search by attribute, etc.
>
> Users, groups, etc., can all be stored, named, located, and bound through
> JNDI.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Theres a disjunct in James where the User repository specifications
> are refered to by name, but the Mail repositories are refered to by
> URI.
> This suggests to me that all repositories should be mapped to
> namespaces, and the namespaces alone made available to Mailets.
Hence JNDI. JNDI == Java *Naming* and *Directory* interface. I am really
suggesting that JNDI provide that functionality to James. We can look
things up by name, path, search by attribute, etc.
Users, groups, etc., can all be stored, named, located, and bound through
JNDI.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Vincent
> decission where and how to store it. A message to a newsgroup might be
> posted in the '#news/' namespace of the store while a user
> message might be
> stored at '#user/username/INBOX'. I don't think a Mailet should be aware
> where the message is stored in the end. In a mailet perspective, a message
> is delivered to the store or passed on to the next hop in the transport
> chain.
Thanks, I like that, it helps crystalise something I've been trying to work towards.
Theres a disjunct in James where the User repository specifications are refered to by name, but the Mail repositories are refered to by URI.
This suggests to me that all repositories should be mapped to namespaces, and the namespaces alone made available to Mailets.
Is that what you are getting at?
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Vincent de Lau <vi...@delau.nl>.
> -----Original Message-----
> From: Sid Stuart [mailto:sid@weaselworks.com]
>
> What I (and I think Vincent) want, is to have the definition of that
> custom operation definition facility extended to support operations on
> all the data stored in James. What you see in my postings is not a lack
> of understanding of the difference between the Mailet definition and the
> SpoolManager implementation. It is a lack of acceptance of the
> limitations of the Mailet definition.
You are partly right about my vision. In my opinion James should provide one
interface to access all the stores, but James should also have complete
control of what should be stored where. The current storeMessage() operation
is pretty good, but might be renamed deliverLocaly(). James should make the
decission where and how to store it. A message to a newsgroup might be
posted in the '#news/' namespace of the store while a user message might be
stored at '#user/username/INBOX'. I don't think a Mailet should be aware
where the message is stored in the end. In a mailet perspective, a message
is delivered to the store or passed on to the next hop in the transport
chain.
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Danny Angus wrote:
>...mail message processing, and James an MTA implementing the Mailet API.
>
>
This is the crux of our communications problem. I have read this
statement in mail from two of the James developers. *James is not an MTA*.
I don't think there is an acronym for James, but I think of it as an
Internet Message Facility (IMF). It provides the functionality of a Mail
Transfer Agent, but it also provides the functionality of a news server
and a mail storage facility. In addition to this, it provides a faciity
to define custom operations on Mail messages.
What I (and I think Vincent) want, is to have the definition of that
custom operation definition facility extended to support operations on
all the data stored in James. What you see in my postings is not a lack
of understanding of the difference between the Mailet definition and the
SpoolManager implementation. It is a lack of acceptance of the
limitations of the Mailet definition.
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion) tedious counter arguments
Posted by Serge Knystautas <se...@lokitech.com>.
Sid Stuart wrote:
> As for the mailet developer, it makes their life simpler. Let's use the
> Mail class as an example. The class itself (MailImpl) would pick up the
> default delegation from the configuration file. The only time the
> developer would need to set the persistence mechanism is if they want to
> change it for some reason. So to create an instance of Mail,
>
>
> theConfigData.getMailServer().sendMail(mail);
This does suck. We have to rename it or do something.
> Mail mail = new Mail (...); // How hard is this?
>
> <this> is a lot simpler than the current mechanism used to select the
> persistence in SMTPhandler,
How is anything supposed to know you want this Mail object in SMTP's
root message queue? There are probably a dozen different places someone
would want to stick a new Mail object. Nevermind that from a design
perspective, how is this constructor supposed to know where the SMTP's
root message queue? You basically have to make something static to
accomplish this.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion) tedious counter arguments
Posted by Danny Angus <da...@apache.org>.
Sid,
> javax.mail.internet.MimeMessage.saveChanges. My pattern is consistent
> with that method.
In my opinion I don't think your example stands up to scrutiny, your notion that the message should be the "Information Expert" is supported by this, in that this method is used to commit changes to the internal representation, it doesn't, however, persist the message This is taken care of by implementations of the "Store" interface.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion) tedious counter arguments
Posted by Sid Stuart <si...@weaselworks.com>.
Danny Angus wrote:
>What we actually want is to provide the sysadmin and the Mailet developer with this freedom, not the Mail implementor. What you propose here means that to use alternative repository types for, lets say spool (file) and archive (mbox) we would have to convert the Mail from one class to another, or use delegation.
>
How would this expose additional complexity to the sysadmin? While they
will see additional complexity due to the availability of multiple
persistent implementations, this is a design decision of the James
development team. My abstraction simply hides this complexity from from
the developer.
As for the mailet developer, it makes their life simpler. Let's use the
Mail class as an example. The class itself (MailImpl) would pick up the
default delegation from the configuration file. The only time the
developer would need to set the persistence mechanism is if they want to
change it for some reason. So to create an instance of Mail,
Mail mail = new Mail (...); // How hard is this?
The above is a lot simpler than the current mechanism used to select the
persistence in SMTPhandler,
theConfigData.getMailServer().sendMail(mail);
>The idea that a repository would be managed by an instance of the message class, rather than an explicit repository class is, in my opinion, a bad idea.
>
Yes, but other people agree with my approach, see
javax.mail.internet.MimeMessage.saveChanges. My pattern is consistent
with that method.
>James is a server, one of the key parts of that is it's management of storage, messages are the data. In all the time I've been here you are the first person to suggest....
>
Thanks, the Catholic church used a similar argument against Galileo.
It's nice to be associated with such a distinguished philosopher. :)
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I'm sorry but I simply do not agree that making persistence a method of the Mail object achieves any real benefit.
>
> What does eveyrone else think?
I agree.
Danny speaks to the implicit roles and responsibility in this design,
but beyond that, there is very little that is specific to James... these
are general Java language issues that I don't think are worth
reinventing for this project, and don't get to the heart of the matter
as to what are the requirements and how to solve them.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Sid,
> There is no persistence support for the NNTP server defined in
> apache.mailet. The support provided by JavaMail Store may not be
> a good fit for that server.
The Mailet API is implemented by the mail spoolmanager not NNTP, this is a weakness of the API, wich doesn't support NNTP messages, not an omission of the NNTP service.
I suggest you take a few moments to familiarise yourself with the subtle but very important distinction between the Mailet API, an API for portable mail message processing, and James an MTA implementing the Mailet API.
>
> There is general interest in using JNDI/LDAP to store User data. What
> steps should be taken for James to support this though?
>
> I would like to suggest a design approach to resolve these issues:
>
> The low-level definition of repositories should be be abstracted out of
> apache.mailet completely
Not sure I agree with you, first there is a high level definition, second without that it is much harder for mailet writers to write mailets which access repositories without knowing about the repositories, it moves the responsibility from the mailet developer to the container implementor.
> This approach defines a consistent persistence interface that can be
> easily shared across all servers. It provides the class implementer with
> substantial freedom in choosing a persistence mechanism.
What we actually want is to provide the sysadmin and the Mailet developer with this freedom, not the Mail implementor. What you propose here means that to use alternative repository types for, lets say spool (file) and archive (mbox) we would have to convert the Mail from one class to another, or use delegation.
A mailet developer is not interested in repository internals, it's not her concern, she wants to access a repository and store or retrieve messages, making her deal with delegation is an unnecessary extra step.
> It also allows
> the class implementor to easily add properties to a persisted class as
> no repository definition need be considered.
I see that as being something which would break the effectiveness of the API, what is the point in having a standard processing API when each Mail implementation is incompatible with every other.
Further to your comments about patterns and OOD I agree that Mail is the "Information Expert" for mail messages, but not at all that that inevitably extends to persistence. I would respectfully suggest that a repository is the "Information Expert" for persistent storage.
Using your pattern we end up with either many subclasses of Mail, one for each type of persistence where the correct type has to be chosen at instantiation, or we delegate this functionality and have to pass delegates to the Mail object each time we want to persist it.
The idea that a repository would be managed by an instance of the message class, rather than an explicit repository class is, in my opinion, a bad idea. James is a server, one of the key parts of that is it's management of storage, messages are the data. In all the time I've been here you are the first person to suggest that we should reverse the architecture and remove the concept of repositories from the design of James.
I would have thought that reversing the pattern to pass the Mail to the storage method would be simpler to understand, easier to code, and a better match with our aspirations to *not* pre-judge the requirements of any installation, rather to provide freedom to administrators to choose repository types according to their requirements.
I'm sorry but I simply do not agree that making persistence a method of the Mail object achieves any real benefit.
What does eveyrone else think?
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > No, do you have a pointer to any documentation? I don't see anything
> > mentioned about NNTP in the JavaMail 1.3 docs.
> There are couple listed here
> http://java.sun.com/products/javamail/Third_Party.html
> There is another one under classspathx project at
> http://savannah.gnu.org/projects/classpathx
Purely FYI, Harmeet, the classpathx code service providers are from Chris
Burdess' knife project.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Sid Stuart" <si...@weaselworks.com>
> Noel J. Bergman wrote:
>
> >Are you aware that there is an NNTP JavaMail service provider?
> >
> >
> >
> >
> No, do you have a pointer to any documentation? I don't see anything
> mentioned about NNTP in the JavaMail 1.3 docs.
There are couple listed here
http://java.sun.com/products/javamail/Third_Party.html
There is another one under classspathx project at
http://savannah.gnu.org/projects/classpathx
Harmeet
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>Are you aware that there is an NNTP JavaMail service provider?
> No, do you have a pointer to any documentation? I don't see anything
> mentioned about NNTP in the JavaMail 1.3 docs.
There are at least two. Please see:
http://java.sun.com/products/javamail/Third_Party.html.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Noel J. Bergman wrote:
>Are you aware that there is an NNTP JavaMail service provider?
>
>
>
>
No, do you have a pointer to any documentation? I don't see anything
mentioned about NNTP in the JavaMail 1.3 docs.
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Would you store the messages in a folder named spooler?
The persistence implementation of the spooler would be opaque. Spoolers,
themselves, should be first class resources available from the JNDI lookup
(or a MailetContext method).
> How will SpoolRepository's "accept (long delay)" method be implemented?
That is just a "pull" operation with a timeout.
> Would you use the listener capability to signal the arrival
> of new messages to the SpoolManager?
Possibly. I'm leaning towards converting existing C++ code I've written
that implements the OMG Common Object Services Event Service to Java. The
COS Event Service is one of the only packages that fully supports decoupling
push and pull consumers and suppliers, and can be layered over varied
implementations. The event service can leverage the Java notification model
within its implementation space.
> My interest is also perked by comments like this from Noel in the
> message labeled Re:Repositories (Design suggestion) labeled dated
> 4/30/2003 4:34
> > The idea is that a spooler is not a store, but rather may USE a store.
Correct. I don't believe that Spool extending Repository is good; the Spool
/ Repository relationship is better expressed as HAS-A than IS-A. And it is
an important change, IMO, because there are technologies that could be used
to implement a spooler, and they provide their own persistence notions. We
gain implementation flexibility by keeping the design clean.
> I've googled the phrase T-space and came up with this link
> http://www.almaden.ibm.com/cs/TSpaces/intro.html
> While this looks like a powerful platform, I don't understand how the
> licensing will be compatible with the Apache licensing.
Google for tuplespace. A tuplespace is a generic concept. Linda, IBM
T-spaces, Sun JavaSpaces, jxtaSpaces, LighTS, etc., are all tuplespace
implementations.
My comment about T-spaces was just an example. However, if we have a
clustering spool solution that *allows* IBM T-spaces to be used to implement
clustering, that is fine. That is no different from someone who wants to
use Oracle as the database backend.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Sid Stuart wrote:
> Thanks for the pointer Serge. Fortunately, I can read a Javadoc and
> figure out how I would implement something. Past evidence suggests a
> void between my approach and the approaches of the James team though.
> Thus my request for how it would be done. My questions are,
>
> Would you store the messages in a folder named spooler?
Maybe. Originally it seemed that was a good idea, but there isn't as
much of a need to have spools integrate with other implementations, so
perhaps we just keep these proprietary and make this very performance
tailored.
> How will SpoolRepository's "accept (long delay)" method be implemented?
Not even sure if that's the right design approach, leading to your next
question.
> Would you use the listener capability to signal the arrival
> of new messages to the SpoolManager?
Perhaps. Right now there's a notifyAll() issue with the file
implementation for the spooler that Noel believes is causing problems.
Basically I think we need to step back and redesign spools, so we'll
have to see.
> My interest is also perked by comments like this from Noel in the
> message labeled Re:Repositories (Design suggestion) labeled dated
> 4/30/2003 4:34
>
> I'm not sure if it would be usefull to place the spool folders
> in this namespace.
> TBD. The idea is that a spooler is not a store, but
> rather may USE a store.
> For example, if we used T-spaces, that provides its own
> persistence, and so
> you don't need to replicate it.
Yes, not sure how much we decouple it or not. We originally thought
that, but to the first comment, what does this really get you? We have
extra data we need to store, we don't need to integrate, it has a
different API. Really spoolers might do better to just be 100%
separately written implementations.
> I've googled the phrase T-space and came up with this link
> http://www.almaden.ibm.com/cs/TSpaces/intro.html
> While this looks like a powerful platform, I don't understand how the
> licensing will be compatible with the Apache licensing.
I don't know if Noel meant literally that product. I don't expect to
contribute to that design effort directly, beyond these high level
requirements discussion.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Serge Knystautas wrote:
>
> - How to make this distributed? Alternatively, I'd say if we used a
> centralized database server and relied on the db transactions to flag
> that you were handling a spooled message, you could let multiple James
> instances use a centralized spool.
>
One benefit of this approach is that additional mail transfer protocols,
such as LMTP, could be supported.
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Serge,
re events and spooling you wrote:
> There are two issues to resolve with that approach:
> - How do you handle "wake" events. For example, after 2 hours I need to
> retry that message again. What is checking this?
I would re-examine the model and suggest that having hidden messages in the spool is in fact counter intuitve to the principle of a spool.
IMHO a spool is really little more than a buffer, it exists to absorb peaks and provide a single simple access point. It is particularly applicable if the output is to a slow or hungry process, or if the inputs cannot be regulated.
I would suggest that mail which may not be de-spooled is not permitted to exist in a spool, and instead we have a "sin-bin" a repository whose primary purpose is to retain messages in an inactive state for a pre-determined time. After which they are inserted into the spool and events are raised.
> - How to make this distributed?
Not sure how the current system is "distributed", unless we're talking about the ability for external processes to insert messages into our spool.
To this I'd say first of all should this be a design objective?
And if the answer is yes, then we should create an explicit entry point for these messages, a directory, recognised file format file, or documented db table. This would be periodically "swept" into the central spool by a James ervice existing for this explcit purpose.
After all an event driven system with one or more dispatchers sending mail to one or more "spoolmanager" threads is to my mind a nice, elegant, scaleable architectural solution.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Serge,
> So then, how would you design this sin-bin?
As a mail repository, with a Mail attribute for time-to-live in the sin-bin.
Ideally a process would be triggered for each message when it was due to be re-inserted, with the list being maintained by events.
> So after discussing this, I think it would be more useful to keep
> individual spools, but then have a way for James servers to know of each
> other, to know when it can stop accepting requests, and to know where
> each other's spools are so it can grab from those if a server goes down.
Yeah... but it's quite likely that the spool will be unavailable too.
> Do other people see what a "distributed" spool could give you that this
> loose "aware" clustering approach doesn't? For anyone interested in
> this, I think this aware cluster would be much more scalable and
> possibly easier to implement.
Thinking aloud only...
I think a james<->james protocol which could perform the following would be much better:
provide load and availability data perhaps like: I am working, I am stopped but alive, my spool is growing/shrinking
provide efficient spool<->spool xfer "send me n Mails", "take this Mail ..."
provide cluster controller actions.. "send n Mails to server x", "send all new Mails to x", "balance Mail to x,y,z"
So that any James instance could handle connections in any mail protocol, and request or sned mail to and from other Jameses.
You could end up with some configured as connection handlers and some as processors/repositories, with the ability to scale by adding more of the required type.
In the end I think we need shared access to mailboxes and user-repositories to make this really work, and that implies a lot of work on locking and preventing bottlenecks to be robust.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I would suggest that mail which may not be de-spooled is not permitted to exist in a spool, and instead we have a "sin-bin" a repository whose primary purpose is to retain messages in an inactive state for a pre-determined time. After which they are inserted into the spool and events are raised.
Ok, sounds reasonable. The only push-back I would give though is that
this means we're creating yet another "mail" store (spool is one,
JavaMail store is another, and then a sin-bin repository).
So then, how would you design this sin-bin?
> Not sure how the current system is "distributed", unless we're talking about the ability for external processes to insert messages into our spool.
The current (2.1) system is not distributed, but I think there have been
requests to make it such. This may not be scalable, and this may be
defeating much of the value of SMTP.
Talking it through outloud, clustering James servers and having them
work off of a single "distributed" spool would make it...
- faster? hardly. keeping individual spools on each server would be
much more effective. A better approach would be for the servers to
"know" there are others locally available, and then just not accept
those connections until it was happy again.
- non-stop service? SMTP already does this. if a server is down, you
bump over to the next.
- increased uptime? This is the only real benefit I see... if a server
goes down, then you can get to messages that are stuck in process in
that server.
So after discussing this, I think it would be more useful to keep
individual spools, but then have a way for James servers to know of each
other, to know when it can stop accepting requests, and to know where
each other's spools are so it can grab from those if a server goes down.
Do other people see what a "distributed" spool could give you that this
loose "aware" clustering approach doesn't? For anyone interested in
this, I think this aware cluster would be much more scalable and
possibly easier to implement.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Serge,
re events and spooling you wrote:
> There are two issues to resolve with that approach:
> - How do you handle "wake" events. For example, after 2 hours I need to
> retry that message again. What is checking this?
I would re-examine the model and suggest that having hidden messages in the spool is in fact counter intuitve to the principle of a spool.
IMHO a spool is really little more than a buffer, it exists to absorb peaks and provide a single simple access point. It is particularly applicable if the output is to a slow or hungry process, or if the inputs cannot be regulated.
I would suggest that mail which may not be de-spooled is not permitted to exist in a spool, and instead we have a "sin-bin" a repository whose primary purpose is to retain messages in an inactive state for a pre-determined time. After which they are inserted into the spool and events are raised.
> - How to make this distributed?
Not sure how the current system is "distributed", unless we're talking about the ability for external processes to insert messages into our spool.
To this I'd say first of all should this be a design objective?
And if the answer is yes, then we should create an explicit entry point for these messages, a directory, recognised file format file, or documented db table. This would be periodically "swept" into the central spool by a James ervice existing for this explcit purpose.
After all an event driven system with one or more dispatchers sending mail to one or more "spoolmanager" threads is to my mind a nice, elegant, scaleable architectural solution.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>> Would you use the listener capability to signal the arrival
>> of new messages to the SpoolManager?
>
> I for one would be greatly in favour of promoting an event driven internal architecture.
> An events raised spooling and de-spooling messages would be a much neater method of maintaining lists in spool manager threads than the current what-do-you-call-it method of listing the contents of the spool.
There are two issues to resolve with that approach:
- How do you handle "wake" events. For example, after 2 hours I need to
retry that message again. What is checking this?
- How to make this distributed? Alternatively, I'd say if we used a
centralized database server and relied on the db transactions to flag
that you were handling a spooled message, you could let multiple James
instances use a centralized spool.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by Danny Angus <da...@apache.org>.
Sid,
> Would you use the listener capability to signal the arrival
> of new messages to the SpoolManager?
I for one would be greatly in favour of promoting an event driven internal architecture.
An events raised spooling and de-spooling messages would be a much neater method of maintaining lists in spool manager threads than the current what-do-you-call-it method of listing the contents of the spool.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Serge Knystautas wrote:
> Sid Stuart wrote:
>
>> I am still trying to understand how this would actually work. I've
>> read through the javadoc's for Folder and Store and cannot understand
>> how they would be used to persist data in the server. Would you
>> please provide a short code segment that would show how the
>> STMPHandler would save an incoming mail message using these definitions?
>
>
> There are several examples that come with the JavaMail download. A
> couple of them show how you add/save a MimeMessage to a Store/Folder.
>
Thanks for the pointer Serge. Fortunately, I can read a Javadoc and
figure out how I would implement something. Past evidence suggests a
void between my approach and the approaches of the James team though.
Thus my request for how it would be done. My questions are,
Would you store the messages in a folder named spooler?
How will SpoolRepository's "accept (long delay)" method be implemented?
Would you use the listener capability to signal the arrival
of new messages to the SpoolManager?
My interest is also perked by comments like this from Noel in the
message labeled Re:Repositories (Design suggestion) labeled dated
4/30/2003 4:34
I'm not sure if it would be usefull to place the
spool folders in this namespace.
TBD. The idea is that a spooler is not
a store, but rather may USE a store.
For example, if we used T-spaces, that
provides its own persistence, and so
you don't need to replicate it.
I've googled the phrase T-space and came up with this link
http://www.almaden.ibm.com/cs/TSpaces/intro.html
While this looks like a powerful platform, I don't understand how the licensing will be compatible with the Apache licensing.
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Serge Knystautas <se...@lokitech.com>.
Sid Stuart wrote:
> I am still trying to understand how this would actually work. I've read
> through the javadoc's for Folder and Store and cannot understand how
> they would be used to persist data in the server. Would you please
> provide a short code segment that would show how the STMPHandler would
> save an incoming mail message using these definitions?
There are several examples that come with the JavaMail download. A
couple of them show how you add/save a MimeMessage to a Store/Folder.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>> The repository interface provided by the Mailet API is
>> inadequate for IMAP, and has some other issues. Rather than reinvent the
>>wheel, it makes sense to adopt JavaMail.
> I am still trying to understand how this would actually work. I've read
> through the javadoc's for Folder and Store and cannot understand how
> they would be used to persist data in the server.
What part don't you understand? If you have read
http://java.sun.com/products/javamail/1.3/docs/javadocs/javax/mail/Folder.ht
ml, you must have seen the appendMessages method.
> Would you please provide a short code segment that would show how
> the STMPHandler would save an incoming mail message using these
> definitions?
Actually, it wouldn't. The SMTPHandler talks to the spooler. And that
would be a separate interfaace. I thought that you had read the message
archives and the Wiki.
ref: http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Repositories (Design suggestion)
Posted by Sid Stuart <si...@weaselworks.com>.
Noel J. Bergman wrote:
>>There is a desire by some developers to provide alternate persistence
>>implementations for the mailet.Mail class that are constrained by the
>>current repository definitions in the apache.mailet package.
>>
>>
>
>Somewhat correct. The repository interface provided by the Mailet API is
>inadequate for IMAP, and has some other issues. Rather than reinvent the
>wheel, it makes sense to adopt JavaMail.
>
>
I am still trying to understand how this would actually work. I've read
through the javadoc's for Folder and Store and cannot understand how
they would be used to persist data in the server. Would you please
provide a short code segment that would show how the STMPHandler would
save an incoming mail message using these definitions?
Sid
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Repositories (Design suggestion)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> There is a desire by some developers to provide alternate persistence
> implementations for the mailet.Mail class that are constrained by the
> current repository definitions in the apache.mailet package.
Somewhat correct. The repository interface provided by the Mailet API is
inadequate for IMAP, and has some other issues. Rather than reinvent the
wheel, it makes sense to adopt JavaMail.
> They will also be constrained by the selection of the JavaMail Store
> abstract class as an interface to persistence.
Please be specific in your analysis. Blanket statements like this are
really just FUD.
> There is no persistence support for the NNTP server defined in
> apache.mailet. The support provided by JavaMail Store may not
> be a good fit for that server.
Are you aware that there is an NNTP JavaMail service provider?
> There is general interest in using JNDI/LDAP to store User data. What
> steps should be taken for James to support this though?
This is orthogonal to the JavaMail issue. Right now we are starting to talk
with the ldapd project about using that service, and I do believe that we
should encourage them to bring it into Apache Incubator.
> The low-level definition of repositories should be be abstracted out of
> apache.mailet completely
You should have stopped here. If we adopt JavaMail for the message stores,
then the Mailet API does not provide storage as part of its definition,
anymore than the Servlet API does. Both of them deal with container <->
component interactions.
Adopting JavaMail also addresses Danny's concern about enabling "mailet
writers to write mailets which access repositories without knowing about the
repositories."
> Instead, a new Interface called Persistent should be provided.
I disagree, for reasons that include the following:
- JavaMail would provide the notion of persistence for messages.
- Serializable and Externalizable are the stanard mechanism for
converting to/from a stream format.
- JNDI uses a completely different model for persistence that
would be interfered with by your proposal.
> This approach defines a consistent persistence interface that can
> be easily shared across all servers.
Perhaps. But it is one that is completely naive regarding messaging
systems, and provides no necessary functionality beyond basic CRUD
operations.
> It provides the class implementer with substantial freedom
> in choosing a persistence mechanism.
So does JavaMail, as can be demonstrated by the range of persistent storage
formats currently available. JavaMail, however, is a standard that can be
leveraged, and provides a lot more reusable functionality.
> It also allows the class implementor to easily add properties to
> a persisted class as no repository definition need be considered.
Are you familar at all with X.500, LDAP, JNDI? The entire data model is a
hierarchical store of nodes with named attributes. Personally, I had even
looked at using JNDI as the model for message stores. If we did not use the
JavaMail interface, I would revisit that approach.
One proposal for James v3 is that in each user's JNDI entry, there is an
attribute that represents their mailbox (e.g., a serialzed proxy or just a
suitable URI). To store a message for a user, I look them up, get their
mailbox, and store the message. Serge has a different idea that uses a
hierarchical URL. Considering that Serge's URI can be viewed as a JNDI URI,
these are not incompatible ideas.
Yes, we will likely provide convenience methods, but that doesn't hide the
basic approach using standard interfaces.
> So to create an instance of Mail
> Mail mail = new Mail (...);
Actually, I am hoping that as we evolve Mailet API v3 in conjunction with
the other changes, the Mail class *may* go away. Serge has proposed a
ServerMimeMessage class that subclasses MimeMessage.
> Yes, but other people agree with my approach, see
> javax.mail.internet.MimeMessage.saveChanges. My
> pattern is consistent with that method.
The saveChanges method has no effect if the message is not associated with a
message store. Calling saveChanges on a new message has no effect. Also,
please note that you use Folder to place messages into storage.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org