Re: My Status, and James RoadMap
Mark Livingstone wrote: Noel J. Bergman wrote: I hope to play with IBM's Cloudscape for another project The idea of Cloudscape is interesting, but it might be best to look at axion Maybe we can now revisit this idea ;-) http://www.eweek.com/article2/0,1759,1630856,00.asp MarkL Yes, this is one of the best things that had happened to open source java projects in a very long times. And I sure hope that James will make use of this excellent database that is able to be completely embedded. An interesting Cloudscape article: http://www-106.ibm.com/developerworks/db2/library/techarticle/dm-0408anderson/ Steen Jansdal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Noel J. Bergman wrote: I hope to play with IBM's Cloudscape for another project The idea of Cloudscape is interesting, but it might be best to look at axion Maybe we can now revisit this idea ;-) http://www.eweek.com/article2/0,1759,1630856,00.asp MarkL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Noel J. Bergman wrote:
> > While I agree that we should be container neutral, it would
> be good to
> > accomodate the extended, but optional, Avalon lifecycles
> into a reworked
> > Mailet API so that it can be leveraged when available.
>
> I would be -1 regarding any contamination of the Mailet API
> with container
> specific interfaces. But I do concur that we want to support dynamic
> reconfiguration. That is something we can all collaborate
> on, that is more
> of an issue for a Mailet Container than the Mailet API. I
> believe that we
> already have enough in the Mailet API to support destroying
> and re-initing
> Mailets. As you already noted to Stephen McConnell, "The
> current Mailet
> lifecycle is init, service, destroy. To reconfigure, the
> container could
> simply send a destroy followed by an init to effect
> reconfiguration."
To be clear, personally I am not proposing "any contamination of the Mailet
API with container specific interfaces". In truth, I am not currently
proposing anything, just exploring possibilities. Adding the reconfigure()
lifecycle state to the Mailet API, a specialization of it or as a discrete
interface, is simply identifying a possible requirement for new Mailet
behaviour, in addition to the current lifecycle states of init(), service()
and destroy(). That Avalon container interfaces include something similar is
by the by. Common concerns often lead to common solutions.
Agreed, the current Mailet API can support reconfiguration. My point was
that it may not always be the optimal way to do so. As examples, I gave
having to destroy and reinitialise expensive resources and losing context
while conversing with an external application. Here we could do more. In a
much earlier thread on this, we identified some James resources we would not
want to recycle during reconfiguration, or would recycle less brutally than
via a destroy/init cycle. The proposed reconfiguration state propogates this
option to Mailets. How it is achieved is another matter.
As other Mailet environments may not support reconfiguration I suggested it
be optional, perhaps achieved by a specialization of the Mailet API such as:
public interface org.apache.mailet.ReconfigurableMailet extends Mailet
{
reconfigure(MailetConfig config) throws javax.mail.MessagingException;
}
This would allow ReconfigurableMailets to play in a vanilla Mailet world
while allowing reconfigurable containers to distinguish between vanilla
Mailets and ReconfigurableMailets.
Alternatively, a family of non-mandatory discrete interfaces could be used.
For instance, for 'reconfigure'
public interface org.apache.mailet.Reconfigurable
{
reconfigure(MailetConfig config) throws javax.mail.MessagingException;
}
...which is logically similair to the 'reconfigure' system event for
Listeners discussed below.
> The Servlet API demonstrates that we don't need more than that in
> the Mailet API
> to support reloading. And if/when we do add things, I would adopt a
> Listener interface approach, just as is done in the Servlet
> and Portlet
> APIs. The events would be in the Mailet domain, not a
> container domain.
As an alternative to incorporating non-mandatory states by specializing the
Mailet interface or adding new interfaces, using Listeners is an interesting
alternative. Still, those Listeners have to listen via an interface, so we
would still be adding something, such as an EventMailet specialization of
Mailet or a new discrete Event interface. I would favour the latter as there
is no true dependency on the Mailet interface.
In order to maintain Mailet portability when using Listeners, we would need
to reserve an event namespace for system events, and declare events such as
'reconfigure' within it. Other private event namespaces could do as they
wished but would lose portability, much as they would if they specialized
the EventMailet or Event interfaces mentioned above.
Which, if any, approach to take? New requirements will come along so some
kind of extension mechanism is attractive, regardless of the driver being
support for a 'reconfigure' event or something else. Listeners and discrete
interfaces are both able to accomodate these requirements, so I'm neutral as
to which.
> A key design area is the Mailet container, which is currently
> a Processor.
> We need to look at that, and decide whether we can merge Processor and
> Mailet; if we need to (and can) have Processor extend Mailet;
> if we can use
> some additional Listeners to allow dynamic reconfiguration of
> a Mailet;
> etc., but I would not tie this into the Avalon lifecycle
> except with an
> adapter. Nor would I require Mailets to register, anymore
> than Servlets or
> Portlets have to register if they have declared listener interfaces.
Merging Processor and Mailet would be nice. Putting my jSeive hat on for a
moment, an important element of any changes is to ensure that the Processor
API is agnositic, enabling the plugin of Mailet, jSieve
RE: My Status, and James RoadMap
> > adding processor to the API would allow different implementations to > > behave differently, so I can live with this the way it is. > What value do you see to adding Processor to the Mailet API? Forget the > question of whether Processor extends Mailet or not. What additional > interface(s) are you trying to provide to matchers and mailets? Leaving aside the thought of using Mailet interface for Processors for a moment I think a Processor interface would have a richer configuration and expose more container lifecycle, see my observation on your point about listeners for example. I we already have two different opinions on the behaviour of our linear processor, this could be easily settled if we had two implementations of Processor. Plus.. theres the notion of allowing sieve processors and other processors as API compliant wrappers for other API's and systems, such as perl anti-spam scripts or whatever, and ... we might arrive at a use for some less simplistic processor architecture, say a boolean processor (having two paths), or a "switch/case" processor. I'm just speculating so don't ask me for use-cases, but I'm keen not to prohibit such flexibility arbitrarily if allowing it doesn't overly complicate the "contract" which, in this case I don't believe it does (if that be gramatical;). > Note that I wouldn't want this (existing) behaviour to be part of the > contract of Processor, just the implemented behaviour of LinearProcessor. > Please define what you feel is missing. RE. v hosting.. Not sure at the moment, all I know is that we didn't have a fully integrated and comprehensive answer to this last time I paid it any close attention. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> > I don't know about processor. I think we ought to go back and look at a > > processor being a mailet. > Doesn't really change things, fwiw I'm agnostic about this now, and Serge > for one has the opposite opinion to you. I think it is worth considering, but I'm not sure on which side it will fall out. We'll have to look closely at the interfaces, particularly configuration, which could be very different it we follow through with what you're saying below. The obvious common method is the basic service(Mail) method. > I'm proposing removing everything from the API which *can* be done by JNDI, > including configuration and most if not all of mailet context. I think that might be overkill for the simple things, but see below. I do believe that we could use JNDI as the sole implementation used to provide the configuration information. > (but in a way that a few find/replace session could upgrade much of > peoples own code) Generic[Mailet|Mailet] could continue to provide the current interface by wrapping the JNDI context. > [dynamic reconfiguration] could be done quite easily if we can settle on > the trigger event or condition Agreed. > > The original code added All and Null to the end. We replaced that > > with explicit classes so that you would know that it had fallen off. > Hmm.. Ok but that doesn't change the fact that I'd like to remove it. :) > adding processor to the API would allow different implementations to > behave differently, so I can live with this the way it is. What value do you see to adding Processor to the Mailet API? Forget the question of whether Processor extends Mailet or not. What additional interface(s) are you trying to provide to matchers and mailets? > Note that I wouldn't want this (existing) behaviour to be part of the > contract of Processor, just the implemented behaviour of LinearProcessor. Agreed. We can add a class attribute to the element (even if a processor is a Mailet, there are still configuration issues that make it a special kind, e.g., it is addressable), and processor implementations can provide different default and/or explicit behavior. > to my mind we do not support virtual hosting in the way that most people > understand it. Please define what you feel is missing. The two things I've heard said are that: (a) people want to be able to use [EMAIL PROTECTED] as a valid POP3 name (b) we don't have a means to partition admin privileges per domain In the case of (a)m I think we need to do a much better job of educating people about virtual user tables, and (b) will be tied to our JNDI work, amongst other things. I'll also agree with respect to (a) that our primitive management tools should be more helpful, rather than requiring the population to be done by hand. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> I would be -1 regarding any contamination of the Mailet API with container > specific interfaces. Me too, what he said. And... I'll fake a new identity and vote twice if I have to ;-) > And if/when we do add things, I would adopt a > Listener interface approach, just as is done in the Servlet and Portlet > APIs. Sounds reasonable to me, in fact I quite like this. Call me old fasioned but I'm fond of the listener pattern. >if we need to (and can) have Processor extend Mailet Oh we can all right they're pretty much identical. The problem is we currently don't have (sorry Serge!) a truly compelling reason not to. However I believe that making processor listen for a set of lifecycle events probably gives us that. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> I don't know about processor. I think we ought to go back and look at a > processor being a mailet. Doesn't really change things, fwiw I'm agnostic about this now, and Serge for one has the opposite opinion to you. >My specific point about order is that there are things that we might add to >the API that might be done, instead, by pluggable services that are accessed >via JNDI. I'm proposing removing everything from the API which *can* be done by JNDI, including configuration and most if not all of mailet context. (but in a way that a few find/replace session could upgrade much of peoples own code) > I would also like to see dynamic reconfiguration. Yeah that could be done quite easily if we can settle on the trigger event or condition > As I've said to you before, that was NOT a change that Peter put in. We > simply changed how it was done. The original code added All and Null to the > end. We replaced that with explicit classes so that you would know that it > had fallen off. Hmm.. Ok but that doesn't change the fact that I'd like to remove it. OTOH adding processor to the API would allow different implementations to behave differently, so I can live with this the way it is. Note that I wouldn't want this (existing) behaviour to be part of the contract of Processor, just the implemented behaviour of LinearProcessor. >I would be happy to see several new attributes added, as we did >on[*]Exception. I had wanted to add a class attribute, but that might not >be necessary (not if we do end up switching back to Mailets as processors), >and could agree with requiring an explicit end clause for processing. >Again, this whole area might change depending on the mailet as processor >approach. Agree. We can thrash this all out in the time honoured fasion! >I am not sure that it has been outstanding. A lot of people who ask for >virtual hosting don't realize that we already have it, or think that they >want something else. We'll have to agree to differ then, because to my mind we do not support virtual hosting in the way that most people understand it. What we do do is more like provide a framework which can be extended and configured by experts to provide vhost behaviour. However I'm not likely to get round to all of this quickly, and if it isn't wanted or needed I'm happy enough to not add it. :-) d *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
On Friday 25 June 2004 03:51, Noel J. Bergman wrote: > > While I agree that we should be container neutral, it would be good to > > accomodate the extended, but optional, Avalon lifecycles into a reworked > > Mailet API so that it can be leveraged when available. > > I would be -1 regarding any contamination of the Mailet API with container > specific interfaces. But I do concur that we want to support dynamic > reconfiguration. That is something we can all collaborate on, that is more > of an issue for a Mailet Container than the Mailet API. I believe that we > already have enough in the Mailet API to support destroying and re-initing > Mailets. As you already noted to Stephen McConnell, "The current Mailet > lifecycle is init, service, destroy. To reconfigure, the container could > simply send a destroy followed by an init to effect reconfiguration." The > Servlet API demonstrates that we don't need more than that in the Mailet > API to support reloading. And if/when we do add things, I would adopt a > Listener interface approach, just as is done in the Servlet and Portlet > APIs. The events would be in the Mailet domain, not a container domain. > > A key design area is the Mailet container, which is currently a Processor. > We need to look at that, and decide whether we can merge Processor and > Mailet; if we need to (and can) have Processor extend Mailet; if we can use > some additional Listeners to allow dynamic reconfiguration of a Mailet; > etc., but I would not tie this into the Avalon lifecycle except with an > adapter. Nor would I require Mailets to register, anymore than Servlets or > Portlets have to register if they have declared listener interfaces. > > On a related note, as I believe I've mentioned I'd like to change the way > that RemoteDelivery works. Rather than have RemoteDelivery handle its own > queuing, I'd like to push that out a level so that any matcher/mailet can > benefit from that capability. For example, if a DNSRBL matcher failed, the > operation could be requeued. I would not mind putting that on my list, well I guess most stuff that concerns RemoteDelivery has my interest ;-) Do you have more detail of how you envision this requeing service? --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> While I agree that we should be container neutral, it would be good to > accomodate the extended, but optional, Avalon lifecycles into a reworked > Mailet API so that it can be leveraged when available. I would be -1 regarding any contamination of the Mailet API with container specific interfaces. But I do concur that we want to support dynamic reconfiguration. That is something we can all collaborate on, that is more of an issue for a Mailet Container than the Mailet API. I believe that we already have enough in the Mailet API to support destroying and re-initing Mailets. As you already noted to Stephen McConnell, "The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration." The Servlet API demonstrates that we don't need more than that in the Mailet API to support reloading. And if/when we do add things, I would adopt a Listener interface approach, just as is done in the Servlet and Portlet APIs. The events would be in the Mailet domain, not a container domain. A key design area is the Mailet container, which is currently a Processor. We need to look at that, and decide whether we can merge Processor and Mailet; if we need to (and can) have Processor extend Mailet; if we can use some additional Listeners to allow dynamic reconfiguration of a Mailet; etc., but I would not tie this into the Avalon lifecycle except with an adapter. Nor would I require Mailets to register, anymore than Servlets or Portlets have to register if they have declared listener interfaces. On a related note, as I believe I've mentioned I'd like to change the way that RemoteDelivery works. Rather than have RemoteDelivery handle its own queuing, I'd like to push that out a level so that any matcher/mailet can benefit from that capability. For example, if a DNSRBL matcher failed, the operation could be requeued. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Adam Fowler wrote: > I've been tinkering with the IMAP2 stuff with a view to implementing the > Maildir (Qmail stylee) method of mail storage. The main issue I had is > (apart from time) splitting off the store type from IMAP2. It's the > heirarchical type of Maildir with folders that will be an issue as far as I > can see. > I'll post the mods I've done onto my website with an explanatory document if > anyone else wants to see it. I'm afraid I'll just be too busy. Time is always an issue for people. :-) Thanks for what help you have, can, and will provide. :-) Jason Webb has a pretty good handle on this area, and I'm sure he'll be appreciative of what you've done. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Danny, > I spent this w/e reviewing the Mailet API Would you please annotate http://wiki.apache.org/james/JamesMailetV3? For that matter, would folks PLEASE update that or http://wiki.apache.org/james/JamesV3/Plans as necessary? I was looking at copying the suggestions from the mailing list, but I would really prefer that everyone took the time to do that themselves. > the processor and repository interfaces and a couple of implementation > methods from James to Mailet. I don't think theres anything contentious > in my ambition, I'm not proposing archtectural changes and have carefully > considered everyone's input into our earlier discussions. I don't know about processor. I think we ought to go back and look at a processor being a mailet. > I don't think there's much reason for doing JNDI or API changes in any > particular order, save that I'd like to have a specification which > specifies the role and beaviour of JNDI first. My specific point about order is that there are things that we might add to the API that might be done, instead, by pluggable services that are accessed via JNDI. > I merely want to make processors the basic element of auto-deployment, as > they seem to strike a nice balance between size and flexibility. I would also like to see dynamic reconfiguration. > The only change I will propose is that LinearProcessor be allowed to not > terminate mail so that unhandled mail can fall back through. As I've said to you before, that was NOT a change that Peter put in. We simply changed how it was done. The original code added All and Null to the end. We replaced that with explicit classes so that you would know that it had fallen off. I would be happy to see several new attributes added, as we did on[*]Exception. I had wanted to add a class attribute, but that might not be necessary (not if we do end up switching back to Mailets as processors), and could agree with requiring an explicit end clause for processing. Again, this whole area might change depending on the mailet as processor approach. > > > $) Add flexible virtual hosting. Offering a choice at config time of > > > either IP based using bound IP's or name based using rich account names. > > I think we already have this, or are very close. > Agreed. I don't think it'd be a big job, but it's been outstanding for > *so**long* I think it has to be on someone's worklist this time round. I am not sure that it has been outstanding. A lot of people who ask for virtual hosting don't realize that we already have it, or think that they want something else. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
I've been tinkering with the IMAP2 stuff with a view to implementing the Maildir (Qmail stylee) method of mail storage. The main issue I had is (apart from time) splitting off the store type from IMAP2. It's the heirarchical type of Maildir with folders that will be an issue as far as I can see. Unless of course I'm missing something. I've managed to move the specification of which store to use into the configuration XML file, and re-jigged the whole thing so its extensible and configurable form there. I've been a bit stretched over the last month, and now I've got my own company this isn't likely to change for the foreseeable future. I'll post the mods I've done onto my website with an explanatory document if anyone else wants to see it. I'm afraid I'll just be too busy. :o( Shame too, I was really beginning to like playing with the code too. Also the emphasis on getting a working IMAP server has now been removed since I battered courier-imap into submission this week, so I no longer have an excuse to work on it. Anyways I'm rambling. I'll go and post the stuff up tonight. Sorry guys, Adam. > -Original Message- > From: Jason Webb [mailto:[EMAIL PROTECTED] > Sent: 23 June 2004 14:19 > To: 'James Developers List' > Subject: RE: My Status, and James RoadMap > > > Mine are simple... > > 0) Debug the mbox random access file class, update the mbox > file handler and > commit them both > 1) Sort out user attributes. This is done for file user > stores, but the db > stuff needs to be re-worked as I'm not happy with it > 2) Get the current mailbox system to support folders > 3) Get the IMAP server to work with the new folder support > 4) Tie in the current IMAP2 proposal into the main source tree > 5) Get my twins to sleep through the night (easy stuff first :)) > > Other things I'd like to look at are (but probably won't): > a) Logging needs to be consistent so I can track mails across > the system > b) JMX support. We still need to be able to authenticate > users in JMX using > the James user dbs. Until this is done JMX is a security hazard > c) A scalable mail queue system. Dumping 150k files into one > flat folder is > a bad idea on any OS. A folder/file system a la Qmail might be fun > > -- Jason > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Here are my objectives: 1) Extend AttachmentFileNameIs to optionally recurse one level in zip attachments. 2) Code an AttachmentFileNameIsRegex matcher (also recursing zips). 3) Polish up and finally commit my Bayesian stuff. 4) Polish up and finally commit my antivirus matcher (perhaps having it become a mailet setting attributes). 5) Polish up and finally commit my AddServerSignature mailet. 6) Start designing and coding a set of functionalities oriented towards server signing and checking, timestamping, logging, whitelisting and more generally "certified electronic mail" (with also the goal of supporting a new legislation just set in my country, that could become of interest for others, but first of all I'm thinking on a set of common stuff that can be customised). The first five points consist mainly in finalising what I already have up and running since several months, the last one is more "ambitious", specially in the design phase, to get something well done and extensible. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
--- Steve Brewin <[EMAIL PROTECTED]> 內容：
> One thing that immediately troubles me is how Mailet
> pipelining would work.
> Currently we have a Linear Processor that is
> responsible for workflow;
> invoking Mailets based on a mail's state.
The avalon powered Mailet behave in exactly the same
way as a normal Mailet. Here's what I did for
JamesSpoolManager initialize():
if (c.getAttributeAsBoolean ("avalon", false))
{
mailet = (Mailet) this.registry.resolve
(mailetClassName);
}
else
{
mailet = mailetLoader.getMailet(mailetClassName,
mailetContext, c);
}
The avalon mailet participates in the pipeline as
usual:
error
false
> I'm
> guessing that you guys would
> advocate a workflow service to provide the
> equivalent function?
In our case, we are not relying on any external
workflow service/solution. The James pipelining is
adequate and very well designed. All We are trying to
do is to have a configurable, serviceable, and log
enabled mailet that can reuse our in house components.
Albert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Hi,
Just a quick note to say thanks for the input. I'm going to have to brush up
on my Avalon knowledge before I can understand the impact of such an
approach - gains, losses, level of effort, etc - and make any meaningful
comments.
One thing that immediately troubles me is how Mailet pipelining would work.
Currently we have a Linear Processor that is responsible for workflow;
invoking Mailets based on a mail's state. I'm guessing that you guys would
advocate a workflow service to provide the equivalent function?
-- Steve
> From: Albert Kwong wrote:
> Sent: 22 June 2004 08:57
> To: Stephen McConnell; James Developers List
> Subject: Re: My Status, and James RoadMap
>
>
> > >>Albert Kwong recently sent to me a patch detailing
> > a
> > >>MailetRegistry that
> > >>handles the registration of merlin based mailet
> > >>implementations (without
> > >>touching the mailet api). This is consistent with
> > the ideas I've
> > >>discussed with Alexis Agahi (Open IM) - basically
> > that the really
> > >>interesting scenario is the ability to move james
> > from
> > >>"application" to
> > >>"service" and once that is achieved - to be able
> > to use james as just
> > >>another service available to any other component.
> > >
> > >
> > > That would be something worth examining. Any links
> > to the conversations?
> >
> > It was off-list so I can't quote anything but I have
> > pinged Albert to
> > let him know that I'm talking about him and this
> > subject. What I can
> > say is that he has come up with a modified james
> > assembly model which
> > ties in a mailet registry - which is kind of cool.
> > It does not impact
> > the mailet api but enables component based mailets.
> > After looking at
> > the code (which is based on Merlin 3.2 I think we
> > can improve/simplify
> > this using the composition spi in Merlin 3.3.
>
> As Steve said, the proposed solution uses a mediator
> with the following interfaces:
>
> public interface RegistryService
> {
> public void register (String name, Object
> plugin);
> public Object resolve (String name);
>
> public void addListener (String name, Listener
> listener);
> }
>
> public interface Listener
> {
> public void registryReady () throws Exception;
> }
>
> A Mailet component will implement the standard Mailet
> interface as well as Avalon lifecycle interfaces. In
> particular, during service(), it looks up the
> RegistryService and then registers itself during
> initialize().
>
> The JamesSpoolManager component will implement the
> Listner interface and adds itself to the registry
> during initialize(). When the RegistryService
> confirms that all components are ready, it calls the
> listener's registryReady() method, where actual
> initialization can take place.
>
> The block.xml will contain the following:
>
> class='RegistryService'>
>
> org.apache.mailet.Mailet
> CustomAvalonMailet
> JamesSpoolManager
>
>
> class='CustomAvalonMailet'>
> ...
>
>
> class='org.apache.james.transport.JamesSpoolManager'>
>
>
>
>
>
>
> When the JamesSpoolManager sees that a mailet is of
> type avalon, it can use the RegistryService to lookup
> the component instead of looking it up from the
> predefined mailet packages.
>
> Benefits: the CustomAvalonMailet can make use of any
> avalon services, such as a datapath we have designed.
> The datapath can be shared between the web tier and
> the SMTP tier (and potentially many other tiers),
> making code highly reusable. In our case, we did not
> call any James Avalon services from our servlets.
>
> Albert
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Mine are simple... 0) Debug the mbox random access file class, update the mbox file handler and commit them both 1) Sort out user attributes. This is done for file user stores, but the db stuff needs to be re-worked as I'm not happy with it 2) Get the current mailbox system to support folders 3) Get the IMAP server to work with the new folder support 4) Tie in the current IMAP2 proposal into the main source tree 5) Get my twins to sleep through the night (easy stuff first :)) Other things I'd like to look at are (but probably won't): a) Logging needs to be consistent so I can track mails across the system b) JMX support. We still need to be able to authenticate users in JMX using the James user dbs. Until this is done JMX is a security hazard c) A scalable mail queue system. Dumping 150k files into one flat folder is a bad idea on any OS. A folder/file system a la Qmail might be fun -- Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
> >>Albert Kwong recently sent to me a patch detailing
> a
> >>MailetRegistry that
> >>handles the registration of merlin based mailet
> >>implementations (without
> >>touching the mailet api). This is consistent with
> the ideas I've
> >>discussed with Alexis Agahi (Open IM) - basically
> that the really
> >>interesting scenario is the ability to move james
> from
> >>"application" to
> >>"service" and once that is achieved - to be able
> to use james as just
> >>another service available to any other component.
> >
> >
> > That would be something worth examining. Any links
> to the conversations?
>
> It was off-list so I can't quote anything but I have
> pinged Albert to
> let him know that I'm talking about him and this
> subject. What I can
> say is that he has come up with a modified james
> assembly model which
> ties in a mailet registry - which is kind of cool.
> It does not impact
> the mailet api but enables component based mailets.
> After looking at
> the code (which is based on Merlin 3.2 I think we
> can improve/simplify
> this using the composition spi in Merlin 3.3.
As Steve said, the proposed solution uses a mediator
with the following interfaces:
public interface RegistryService
{
public void register (String name, Object
plugin);
public Object resolve (String name);
public void addListener (String name, Listener
listener);
}
public interface Listener
{
public void registryReady () throws Exception;
}
A Mailet component will implement the standard Mailet
interface as well as Avalon lifecycle interfaces. In
particular, during service(), it looks up the
RegistryService and then registers itself during
initialize().
The JamesSpoolManager component will implement the
Listner interface and adds itself to the registry
during initialize(). When the RegistryService
confirms that all components are ready, it calls the
listener's registryReady() method, where actual
initialization can take place.
The block.xml will contain the following:
org.apache.mailet.Mailet
CustomAvalonMailet
JamesSpoolManager
...
When the JamesSpoolManager sees that a mailet is of
type avalon, it can use the RegistryService to lookup
the component instead of looking it up from the
predefined mailet packages.
Benefits: the CustomAvalonMailet can make use of any
avalon services, such as a datapath we have designed.
The datapath can be shared between the web tier and
the SMTP tier (and potentially many other tiers),
making code highly reusable. In our case, we did not
call any James Avalon services from our servlets.
Albert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Steve Brewin wrote: Stephen McConnell wrote: Steve Brewin wrote: As I understand it, different containers vary in their depth of support for the Avalon lifecycle. As I remember from way back, we could dynamically modify configurations if the container supported the requisite, but optional, lifecycle methods - suspend, resume, reconfigure, etc. While I agree that we should be container neutral, it would be good to accommodate the extended, but optional, Avalon lifecycles into a reworked Mailet API so that it can be leveraged when available. Just a quick note - you should not need to modify the mailet API because in effect the mailet api is a view on a container - the container is handling the deployment of mailets. The question you are raising concerns the semantics supported by the mailet container implementation as opposed to any computation constraints implied by the api. The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration. Indeed for (1) backwards compatibility with existing Mailets and (2) 'cos the Mailet API is not bound to Avalon so should not be dependent on it, it would have to use this as the lowest common denominator. This depends completely on the mailet container. It the mailet container supports configurable component then you home free (either via a static configuration or dynamically). To-date there has been a lot of attention of API purity, but no real discussion on the subject of a mailet SPI (Service Provider Interface). What would be *really* interesting would be the ability for a client to register a mailet factory class - and have the mailet container use that factory to instantiate mailet instances. This would keep the mailet free from pollution but at the same time enable comprehensive component-based mailet solutions. Exposing more granular lifecycle events which Mailets may optionally support (possibly discovered through introspection) would enable efficiencies during reconfiguration, such as retaining expensive non-reconfigured resources, or resources which must maintain context. Is it worth the effort? Not sure. If there is another clean way of 'parking' resources during destroy and 'unparking' during 'init', then no, otherwise yes. IMO its probably better to load a mailet that understands components and it basically mediates between the pure mailet container and functional component based mailets ... but to be honest - this is not an area I have explored in any detail - I would really need to dig into the container-side of the mailet management model. Albert Kwong recently sent to me a patch detailing a MailetRegistry that handles the registration of merlin based mailet implementations (without touching the mailet api). This is consistent with the ideas I've discussed with Alexis Agahi (Open IM) - basically that the really interesting scenario is the ability to move james from "application" to "service" and once that is achieved - to be able to use james as just another service available to any other component. That would be something worth examining. Any links to the conversations? It was off-list so I can't quote anything but I have pinged Albert to let him know that I'm talking about him and this subject. What I can say is that he has come up with a modified james assembly model which ties in a mailet registry - which is kind of cool. It does not impact the mailet api but enables component based mailets. After looking at the code (which is based on Merlin 3.2 I think we can improve/simplify this using the composition spi in Merlin 3.3. I'll email Albert directly and ask him to provide an overview of what he's been up to. Cheers, Steve. Cheers, -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Stephen McConnell wrote: > > > Steve Brewin wrote: > > > As I understand it, different containers vary in their > depth of support for > > the Avalon lifecycle. As I remember from way back, we could > dynamically > > modify configurations if the container supported the requisite, but > > optional, lifecycle methods - suspend, resume, reconfigure, etc. > > > > While I agree that we should be container neutral, it would > be good to > > accommodate the extended, but optional, Avalon lifecycles > into a reworked > > Mailet API so that it can be leveraged when available. > > Just a quick note - you should not need to modify the mailet > API because > in effect the mailet api is a view on a container - the container is > handling the deployment of mailets. The question you are raising > concerns the semantics supported by the mailet container > implementation > as opposed to any computation constraints implied by the api. The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration. Indeed for (1) backwards compatibility with existing Mailets and (2) 'cos the Mailet API is not bound to Avalon so should not be dependent on it, it would have to use this as the lowest common denominator. Exposing more granular lifecycle events which Mailets may optionally support (possibly discovered through introspection) would enable efficiencies during reconfiguration, such as retaining expensive non-reconfigured resources, or resources which must maintain context. Is it worth the effort? Not sure. If there is another clean way of 'parking' resources during destroy and 'unparking' during 'init', then no, otherwise yes. > Albert Kwong recently sent to me a patch detailing a > MailetRegistry that > handles the registration of merlin based mailet > implementations (without > touching the mailet api). This is consistent with the ideas I've > discussed with Alexis Agahi (Open IM) - basically that the really > interesting scenario is the ability to move james from > "application" to > "service" and once that is achieved - to be able to use james as just > another service available to any other component. That would be something worth examining. Any links to the conversations? Cheers, -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Steve Brewin wrote: Danny Angus wrote: My take on the container is that we it to just be there, support our code, be free of memory leaks and crashes, and otherwise stay out of our way. Agreed. And i don't normally pay it much attention, but with people talking about Merlin I wondered what your idea was. As I understand it, different containers vary in thier depth of support for the Avalon lifecycle. As I remember from way back, we could dynamically modify configurations if the container supported the requisite, but optional, lifecycle methods - suspend, resume, reconfigure, etc. While I agree that we should be container neutral, it would be good to accomodate the extended, but optional, Avalon lifecycles into a reworked Mailet API so that it can be leveraged when available. Just a quick note - you should not need to modify the mailet API because in effect the mailet api is a view on a container - the container is handling the deployment of mailets. The question you are raising concerns the semantics supported by the mailet container implementation as opposed to any computation constraints implied by the api. Albert Kwong recently sent to me a patch detailing a MailetRegistry that handles the registration of merlin based mailet implementations (without touching the mailet api). This is consistent with the ideas I've discussed with Alexis Agahi (Open IM) - basically that the really interesting scenario is the ability to move james from "application" to "service" and once that is achieved - to be able to use james as just another service available to any other component. Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Danny Angus wrote: > > My take on the container is that we it to just be there, support our > code, > > be free of memory leaks and crashes, and otherwise stay out > of our way. > > Agreed. And i don't normally pay it much attention, but with > people talking > about Merlin I wondered what your idea was. As I understand it, different containers vary in thier depth of support for the Avalon lifecycle. As I remember from way back, we could dynamically modify configurations if the container supported the requisite, but optional, lifecycle methods - suspend, resume, reconfigure, etc. While I agree that we should be container neutral, it would be good to accomodate the extended, but optional, Avalon lifecycles into a reworked Mailet API so that it can be leveraged when available. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> My take on the container is that we it to just be there, support our code, > be free of memory leaks and crashes, and otherwise stay out of our way. Agreed. And i don't normally pay it much attention, but with people talking about Merlin I wondered what your idea was. > I agree, but would reverse the order. Having JNDI in the Mailet environment > will impact what we can expose, and how, which will impact discussion and > consideration of what should be added to the Mailet API, itself. Actually I spent this w/e reviewing the Mailet API, and apart from moving the processor and repository interfaces and a couple of implementation methods from James to Mailet. I don't think theres anything contentious in my ambition, I'm not proposing archtectural changes and have carefully considered everyone's input into our earlier discussions. I want to start, though, by preparing a draft spec based on the current API and changed to fix the glaring holes. I don't think there's much reason for doing JNDI or API changes in any particular order, save that I'd like to have a specification which specifies the role and beaviour of JNDI first. There's no reason why we can't cycle through two or three alpha versions of the spec and implementation. But I'll post my early work here for review before I commit anything. > > Add support for archived application auto deployment, probably on the > > basis of deploying "Processors" . Tighten classloader separation and > > add JNDI local contexts for secure separation of processors. >I think we should revisit processors and mailets again, as we started to >discuss earlier in the year. Yeah, OK, but.. first of all I think we got some clear opinion, and secondly I'm not proposing any change of behaviour there, particularly not anything which would obstruct changes we might consider on the lines of our last discussion. I merely want to make processors the basic element of auto-deployment, as they seem to strike a nice balance between size and flexibility. The only change I will propose is that LinearProcessor be allowed to not terminate mail so that unhandled mail can fall back through. Of course in line with my belief in the philosophy of least suprise I'd make this a config option turned off by default. The significant bit is that Peter Goldstein considered that: "It is an essential part of the contract of the LinearProcessor that a particular matcher/mailet combination be used to terminate the processor chain" I disagree, and believe that it is not part of the contract at all, certainly it is not expressed anywhere except for the code. Rather we need to specify exactly what the behaviour is here, and we can specify anything, so why not specify the flexible option. It could simply (and consistently with current practices) be implemented by a option in ToRepository or a passThrough attribute in config. > > $) Add flexible virtual hosting. Offering a choice at config time of > > either IP based using bound IP's or name based using rich account names. > I think we already have this, or are very close. Agreed. I don't think it'd be a big job, but it's been outstanding for *so**long* I think it has to be on someone's worklist this time round. > We might want to record our collective ideas on the wiki, where we already > have others: http://wiki.apache.org/james/JamesV3. Looks like we've already > done some, and have new ideas on others. Serge would probably suggest, and > he's right, that we start to use JIRA to layout our roadmap concretely. Perhaps we should use a status file, which only the commiters can alter, rather than the wiki which can be hacked around by strangers? d. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this
RE: My Status, and James RoadMap
Nevermind. It bugged me all morning trying to remember why someone had raised a licensing issue, and I finally recalled the actual issue, which has nothing to do with James. The Thomas Mueller advertising clause prevents HSQLDB from being proposed for Incubation as an ASF project. It has no effect on our being able to bundle hsqldb, since that is addressable in the NOTICE file, and it would not be a hard dependency. The irony of this whole discussion is that I brought up the idea of incorporating HypersonicSQL/hsqldb two years ago, so that we could depend upon the presence of a SQL database: > Honestly, I'd love to can file system user repositories in favor of > at least using HyperSonicSQL bundled with James, but there does not > appear to be any consensus to do that. ref: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .org&msgNo=4123 > I'm hoping that in James v3 we will include hsqldb, so that we can > always assume the presence of a database ref: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .org&msgId=647741 > > Having a JDBC database as a known part of the environment is > > getting better and better. > Heh, sure. Ok maybe we do this at least for configuration stuff. I know > embeding hypersonic (?) is something you'd like to see. ref: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .org&msgId=591339 We already have HypersonicSQL support in sqlResources.xml. The current version of the HypersonicSQL block for Phoenix appears to be http://cvs.sourceforge.net/viewcvs.py/hsqldb/hsql-component/. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
I am somewhat unlearned in the licensing end, and need to be otherwise. I have read the HSQLDB license and it seems to be unexceptional to me. I have a law degree, and this seems to be a clear open source agreement to me. Can you guys educate me on the issues here? The licenses are very simple, so the issues cannot be that deep. Michael At 11:31 PM 6/18/2004, Serge Knystautas wrote: Noel J. Bergman wrote: Well, as I said, people can try whatever databases they want. But I don't see the point of using it if you can't distribute it. Seems to me that the primary reason for it is convenience/turnkey distribution. The ASF may not feel it is open source enough, but that's our requirement, not someone else's. The licensing point just sounds like FUD. Anyway, the license itself from my reading is BSD-style. http://hsqldb.sourceforge.net/web/hsqlLicense.html -- Serge Knystautas Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Thanks, Noel. Could you give a short statement of why that is? If so, thanks in advance. Michael At 10:20 PM 6/18/2004, Noel J. Bergman wrote: > Would you not recommend HSQLDB? People can try whatever databases they want. But IIRC, the HSQLDB license is not compatible with distribution by James. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Noel J. Bergman wrote: Well, as I said, people can try whatever databases they want. But I don't see the point of using it if you can't distribute it. Seems to me that the primary reason for it is convenience/turnkey distribution. The ASF may not feel it is open source enough, but that's our requirement, not someone else's. The licensing point just sounds like FUD. Anyway, the license itself from my reading is BSD-style. http://hsqldb.sourceforge.net/web/hsqlLicense.html -- Serge Knystautas Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
>>>Would you not recommend HSQLDB? >> People can try whatever databases they want. But IIRC, the HSQLDB license >> is not compatible with distribution by James. > Does this really matter to anyone but the ASF (or anyone who would > redistribute James)? Well, as I said, people can try whatever databases they want. But I don't see the point of using it if you can't distribute it. Seems to me that the primary reason for it is convenience/turnkey distribution. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Noel J. Bergman wrote: Would you not recommend HSQLDB? People can try whatever databases they want. But IIRC, the HSQLDB license is not compatible with distribution by James. Does this really matter to anyone but the ASF (or anyone who would redistribute James)? -- Serge Knystautas Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> Would you not recommend HSQLDB? People can try whatever databases they want. But IIRC, the HSQLDB license is not compatible with distribution by James. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
Would you not recommend HSQLDB? At 09:19 PM 6/18/2004, Noel J. Bergman wrote: > Where do plans for IMAP getting a permanent store fit in the scheme of > plans? IMAP needs some champions to work on it. Many have offered, few if any have actually contributed. In terms of a persistent store, Jason Webb and I had worked out a scheme using the current store technology and a naming convention. I think that would be your best place to start. See the mailing list archives. > I hope to play with IBM's Cloudscape for another project The idea of Cloudscape is interesting, but it might be best to look at axion (http://axion.tigris.org/), due to licensing. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> Where do plans for IMAP getting a permanent store fit in the scheme of > plans? IMAP needs some champions to work on it. Many have offered, few if any have actually contributed. In terms of a persistent store, Jason Webb and I had worked out a scheme using the current store technology and a naming convention. I think that would be your best place to start. See the mailing list archives. > I hope to play with IBM's Cloudscape for another project The idea of Cloudscape is interesting, but it might be best to look at axion (http://axion.tigris.org/), due to licensing. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Hi Noel, Where do plans for IMAP getting a permanent store fit in the scheme of plans? I went to the mentioned WIKI site but no real mention. After Maths exam on Tuesday, I will have a month or so to start testing ;-D Also, I hope to play with IBM's Cloudscape for another project, does James support it? TIA MarkL Noel J. Bergman wrote: Start to add features. I have two immediate feature changes I want to make, post-merger. One is a "hack" related to JavaMail that should dramatically improve footprint and performance in two key locations in the code. Basically, I want to convince JavaMail that the message content should be shared and streamed. The second is in-process processor support for the SMTP handler. Comments/criticisms/concerns? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Noel J. Bergman wrote: We might want to record our collective ideas on the wiki, where we already have others: http://wiki.apache.org/james/JamesV3. Looks like we've already done some, and have new ideas on others. Serge would probably suggest, and he's right, that we start to use JIRA to layout our roadmap concretely. I may/may not suggest this, and am not sure whether I'm right. ;) What's in the wiki is a list of goals, while JIRA is nice for discrete tasks. I would prefer to use JIRA to track each developer/code change, e.g., "JNDI support" may be 1 issue, it might be 6, so having the wiki set the goal of JNDI is fine. I'm also just looking for JIRA to helping with changelogs and track bugs. I don't know any tool that really helps with release or product planning. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: My Status, and James RoadMap
> Are we to consider releasing James with Merlin instead > of Phoenix for instance..? I'm considering what we've been considering for over a year: migrating from the old version of Phoenix to the "current" version of Phoenix in our CVS, and the current Avalon components. Phoenix is a proven and stable platform for us, but if someone wants to give Merlin a try, that's fine. My take on the container is that we it to just be there, support our code, be free of memory leaks and crashes, and otherwise stay out of our way. > My own plan.. and in this order.. > a) Revisit the Mailet API experimental changes, particularly those >which haven't found favour. > 2) Add JNDI support for service and parameter lookups to the Mailet >API wordy spec (and draft it as it doesn't exist!) and implement >same in James I agree, but would reverse the order. Having JNDI in the Mailet environment will impact what we can expose, and how, which will impact discussion and consideration of what should be added to the Mailet API, itself. > Add support for archived application auto deployment, probably on the > basis of deploying "Processors" . Tighten classloader separation and > add JNDI local contexts for secure separation of processors. I think we should revisit processors and mailets again, as we started to discuss earlier in the year. > $) Add flexible virtual hosting. Offering a choice at config time of > either IP based using bound IP's or name based using rich account names. I think we already have this, or are very close. We might want to record our collective ideas on the wiki, where we already have others: http://wiki.apache.org/james/JamesV3. Looks like we've already done some, and have new ideas on others. Serge would probably suggest, and he's right, that we start to use JIRA to layout our roadmap concretely. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
+1 to everyone else's plans. But.. Noel, what do you have in mind vis-a-vis Avalon? Are we to consider releasing James with Merlin instead of Phoenix for instance..? My own plan.. and in this order.. a) Revisit the Mailet API experimental changes, particularly those which haven't found favour. 2) Add JNDI support for service and parameter lookups to the Mailet API wordy spec (and draft it as it doesn't exist!) and implement same in James (Hopefully using naming from http://incubator.apache.org/directory/) -- the above two items aiming at finally providing full portability to mailets in a way acceptable in the light of (constructive) criticism raised earlier., Test cases are the James Transport mailets some of which still depend upon access to vendor specific service lookups. Or in other words Avalon. iii) Add support for archived application auto deployment, probably on the basis of deploying "Processors" . Tighten classloader separation and add JNDI local contexts for secure separation of processors. $) Add flexible virtual hosting. Offering a choice at config time of either IP based using bound IP's or name based using rich account names. Of course I'll have to get off my a**e and sort out my net acess at home 1st! :-) Then if I do all that, and my wife hasn't left me, I'd like to write a mailet container which can be embedded in other apps, for instance in a MessageDrivenBean or a test harness. Comments and help would be welcomed for any of the above. d.. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
On Friday 18 June 2004 03:47, Noel J. Bergman wrote: > OK guys, James 2.2.0 is released. That's it from me for probably the next > week or so. I have something next week that I really must focus on. After > that, I'll get onto the branch merger. > > Conjectured Roadmap: > > Release James X (2.3, 3.0, don't care) based upon > the merged code with contemporary Avalon code. > > Start to add features. > > I have two immediate feature changes I want to make, post-merger. One is a > "hack" related to JavaMail that should dramatically improve footprint and > performance in two key locations in the code. Basically, I want to > convince JavaMail that the message content should be shared and streamed. > The second is in-process processor support for the SMTP handler. > > Comments/criticisms/concerns? Sounds great! My work list is as follows: - allowing RemoteDelivery to use SMTP-SSL (port 465) - support for STARTTLS in SMTPHandler - handling source routes by stripping them - RemoteDelivery uses HELO not EHLO, due to a bug in JavaMail back in 2001, so I believe it is time to revisit that. --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
Noel J. Bergman wrote: OK guys, James 2.2.0 is released. That's it from me for probably the next week or so. I have something next week that I really must focus on. After that, I'll get onto the branch merger. Conjectured Roadmap: Release James X (2.3, 3.0, don't care) based upon the merged code with contemporary Avalon code. Can you explain what you intent to mean by your usage of the term "contemporary"? Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
