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 contemporar
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
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.
+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 favo
> 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 s
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
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 sup
> 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 na
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 W
> 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 additio
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 >>>
>>>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 dat
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
req
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 Jam
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
sim
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
effe
> 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
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 ide
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 ide
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
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, lifecyc
> >>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 th
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) G
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 mai
--- 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 a
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
nal 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
>
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, b
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 i
> 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 interface
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 con
> 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
t
> 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 Serv
> > 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
> > 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
> interfac
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 A
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
-
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 o
38 matches
Mail list logo
