I've been thinking more about this and I think that the issue is probably centered around the idea behind processors.
Processors are dumb, linear, and in actual fact not really entities at all, just a state of a message. If processors were either a) simple external scripts supporting conditional branching or b) objects within which mailets could exist (or both) then in the first case you could set them up as text files, easily altered and capable of being changed without stopping the server, and in the second case they could act as a context for their mailets, and would be potentially capable of managing the session information. or not? I do still think that James is primarily a mail/news server, and the mailet API is there to be a bridge between mail/news protocols and applications. 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. 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. At this point an application which can integrate with James using the Mailet API would be able to integrate with any server supporting the mailet API (there are some 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? Perhaps Chris ought to position GEM as a Mailet application server. (just thinking aloud) d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
