----- Original Message ----- From: "Chris" <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
