RE: James - Gem

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

 >Mailets can provide quite a lot of functionality, but there will 
always come
 >a cut off point, beyond which a complex application will be too 
constrained
 >by the architecture of the server to be able to run as a mailet.

I have a problem with this statement.Most Mailets implement the simple,
generalised, widely useful chunks of logic. Applications implement the
specific, complex, higher level logic. The trouble is that the high level
specific logic needs to call the generalised, widely used logic to get
the job done. The application specific logic needs to make use of
Mailets that send out mails, forward mails, and otherwise deal with
messages, and combine them and package them together for an end result.
What you need is a mechanism for creating primitive components
(you've got that) and a mechanism for packaging those primitive
components to make new components, (I think you're missing that).

 > In this
 >case the mailet would be a gateway, forming a request based on a message,
 >passing the request to the application layer, recieveing the response, and
 >altering the message or creating new messages appropriately.

In which case the application layer needs to be able to call on simple
generalised Mailets to get the job done. Building complex things
from glueing together simple things is what it's all about.

 >My point is that if you accept this scenario, that there is a limit to 
what
 >can be done with mailets, then isn't it better to keep the mailet 
system as
 >simple as possible, and encourage its use for simple mail oriented 
tasks and
 >as a gateway into more complex processing, than fall into the trap of
 >expecting too much from it?

How do you define "keeping it simple"? The core of Gem, excluding specific
Gemlets is about 1000 lines of code. That's simple by any standards. The 
gemlet
API is simpler than the Mailet API. Writing gemlets is simple. A Gemlet
that gets an email, splits off attachments, ftps them to a server in a 
directory
of today's date and then notifies a mailing list with a URL of the new file
takes about 40 lines of code. I could write a Gemlet that
could parse James mail files and execute Mailets, and it would have no
impact on the core of Gem. Or I could plug in an extension language like
Kawa scheme interpreter. You can't write a Mailet to do similar
because that Mailet wouldn't be able to execute the other Mailets.
Simple and powerful don't have to be an either/or decision.

Anyway, not wanting to start a flame war, only calling it like I see it.




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

Re: James - Gem

[Serge Knystautas <se...@lokitech.com>]

----- Original Message -----
From: "Chris" <ch...@bitmead.com>


> I have a problem with this statement.Most Mailets implement the simple,
> generalised, widely useful chunks of logic. Applications implement the
> specific, complex, higher level logic. The trouble is that the high level
> specific logic needs to call the generalised, widely used logic to get
> the job done. The application specific logic needs to make use of
> Mailets that send out mails, forward mails, and otherwise deal with
> messages, and combine them and package them together for an end result.
> What you need is a mechanism for creating primitive components
> (you've got that) and a mechanism for packaging those primitive
> components to make new components, (I think you're missing that).

I'm not missing.  I just disagree.  I think *Java* is a great language for
building applications.  I don't really want to invent another.  (comments
about your example below...)

> How do you define "keeping it simple"? The core of Gem, excluding specific
> Gemlets is about 1000 lines of code. That's simple by any standards. The
> gemlet
> API is simpler than the Mailet API. Writing gemlets is simple. A Gemlet
> that gets an email, splits off attachments, ftps them to a server in a
> directory
> of today's date and then notifies a mailing list with a URL of the new
file
> takes about 40 lines of code. I could write a Gemlet that
> could parse James mail files and execute Mailets, and it would have no
> impact on the core of Gem. Or I could plug in an extension language like
> Kawa scheme interpreter. You can't write a Mailet to do similar
> because that Mailet wouldn't be able to execute the other Mailets.
> Simple and powerful don't have to be an either/or decision.

This is how I would implement your example.  A mailet/gemlets gets the
email.  JavaMail lets you split off attachments.  java.net.URL or some FTP
API let's you FTP them.  JavaMail lets you send a message to a mailing list
with the URL.  I agree it'd take less than 40 lines of code (assuming you're
not doing much error checking), and this would be a single mailet/gemlet.

I don't like the idea of splitting this across multiple gemlets, because
then I'm sticking parameters for my FTP action into a conf object that gets
passed as a dynamic configuration to a Gemlet.  I have to ask myself, why
not just call the FTP API?

> Anyway, not wanting to start a flame war, only calling it like I see it.

Hey, no problem.  I wrote the mailet API because I wanted to do email-based
apps in Java.  Java gives me so many APIs to do lots of complex stuff,
again, I don't see the need to create a new call interface or
Turing-complete language.  Mailets could certainly be easier to write and
debug (JAMES isn't very mailet-developer friendly, mainly from a lack of
docs and server reloading), but that's still my vision for mailets.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/


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

RE: James - Gem

[Oki DZ <ok...@pindad.com>]

Hi,

On Wed, 24 Oct 2001, Chris wrote:
...
> How do you define "keeping it simple"? The core of Gem, excluding
> specific Gemlets is about 1000 lines of code. That's simple by any
> standards. The gemlet API is simpler than the Mailet API.

I've visited your website, and I don't think I read something about
"matchers". If "gemlet" is equivalent to "mailet", what is the like of
"matcher" in Gem?

Oki



---------------------------------------------------------------------
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>]

> Anyway, not wanting to start a flame war, only calling it like I see it.

Hey, there's nothing wrong with a robust exchange of opinions :-)

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