James - GEM

[Chris <ch...@bitmead.com>]

Hi!

Well don't you just hate it when you spent some years
developing something then you find out someone else
has done the same thing? :-)

I have also written a freely available java system
for processing emails. I accidently ran across James
today. It's pretty scary how similar they are
actually. I'm trying to figure out now what I should
do:

a) Keep going as I was.
b) Abandon, start using James.
c) ???

I guess I'm trying to figure out which is better
and better designed. I can't seem to find the
source to James on the web site. The Mailet API
is quite similar to my Gemlet API, but I don't
fully understand the algorithm of how they get
called.

Gem is available at http://www.tech.com.au/gem/



---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

RE: James - GEM

[Danny Angus <da...@thought.co.uk>]

> It hasn't clicked with me which Mailets get called
> in James and how control moves to some other Mailet.
> I guess transport/ classes are the interesting ones.
> Is it documented somewhere what the Mail statuses mean?

look at the config.xml file, that sets up the mailet/matcher config, and the processor pipes tehy sit in, mails can be shunted form one processor to another by matchers.


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

Re: James - GEM

[Chris <ch...@bitmead.com>]

Hi!

Ok, found the source and have been poking around.
Amazing some of the similarities, also with Avalon,
very similar to some of the abstractions I'm using.

It still hasn't quite clicked with me how James
processes mails. With Gem, it gets stored in MSG
database table. That has foreign key to QUEUE table.
The queue that the message is stored in is
determined by email addresses attached to that queue.
A queue can be thought of as a mailbox.
The message initially has a status of 'U'nprocessed.
The processing thread picks it up and it goes through
'P'rocessing phase, then to 'S'uccess or otherwise
'F'ailed stage if the Gemlet signals a problem.
There is also a 'R'etry status if the Gemlet would
like to take another shot at it later on.
Messages can be reprocessed by resetting the status.

It hasn't clicked with me which Mailets get called
in James and how control moves to some other Mailet.
I guess transport/ classes are the interesting ones.
Is it documented somewhere what the Mail statuses mean?

I see there is mention of writing an IMAP interface.
This was what I was researching doing when I came
across James. Would it run straight from the database
(if you are using database) in this case? It's not
clear to me how the single table datamodel would support
this.


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

Re: James - GEM

[Peter Donald <do...@apache.org>]

Hi,

On Sun, 21 Oct 2001 13:01, Chris wrote:
> Well don't you just hate it when you spent some years
> developing something then you find out someone else
> has done the same thing? :-)

yup ;)

> I have also written a freely available java system
> for processing emails. I accidently ran across James
> today. It's pretty scary how similar they are
> actually. I'm trying to figure out now what I should
> do:
>
> a) Keep going as I was.
> b) Abandon, start using James.
> c) ???

I would say that working together is always a more desirable alternative. How 
this occurs is really up to you. I would recomend you have a poke around the 
james source and see if you like the look of it. And if you end up liking the 
people here then jump in - the more the merrier ;)

How it could work is up to you. If one of the APIs is clearly better then it 
would be good to merge the good bits of the other into it. Another option 
would be to take the best bits of both APIs and create a new API. There are 
significant differences in the implementation (ie your use of EJBs in parts 
to do the work and you can also kick it from crons) but the ideas are very 
similar.

In the worst case scenario, where you decided that you wanted to continue 
writing your own product - it would still be good to have a common API (much 
like servlet API is common to servlet engines) that would do the processing. 
That way we could at least share that part of the engine. Other options may 
include collaborating on the "processing" engine part while you could keep 
the other parts separate. It is really up to you.

However if you are into working in a meritocracy then this is perfect place 
for you ;)

> I guess I'm trying to figure out which is better
> and better designed. I can't seem to find the
> source to James on the web site. 

>From memory you should be able to download it from

http://jakarta.apache.org/builds/jakarta-james/release/v<some version>/

Anyways I browsed the source of Gem and it definetly looks like there is 
places where James/Gem could share stuff. I will try to look at gem more 
closely when I get the time ;)

-- 
Cheers,

Pete

-----------------------------------------------------------
 "Remember, your body is a temple; however, it's also your 
 dancehall and bowling alley"   -- Dharma Montgomery
-----------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org