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
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)
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
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
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
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
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
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,
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)
--- 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
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
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,
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,
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
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
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
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,
+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
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
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
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
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
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
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
24 matches
Mail list logo
