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
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
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 or any other kind of
mail processing engine.
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. RD 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 at tietoenator.com - 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
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 processor 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
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
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
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
--- 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:
processor name=transport
mailet match=RecipientIsLocal
class=AvalonComponentName avalon='true'/
mailet match=RecipientIsLocal
class=LocalDelivery/
mailet match=HostIsLocal class=ToProcessor
processorerror/processor
debugfalse/debug
/mailet
/processor
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
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
Stephen McConnell wrote: Steve Brewin wrote: snipped 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: Stephen McConnell wrote: Steve Brewin wrote: snipped 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
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
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
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] .orgmsgNo=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] .orgmsgId=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] .orgmsgId=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
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. RD 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 at tietoenator.com - 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
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
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
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
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
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
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]
