Re: [Classpathx-javamail] Event Propagation

[dog]

dixit aselkirk:
> The advantages with a synchronous system include simplified code logic and 
> consistency.  The important issue that needs to be addressed is the use cases 
> of the event propagation system; in particular, is it typical that these 
> notifications from the mail package cascade into further synchronous event 
> systems, the synchronous call ends up blocking on network I/O or latency, or 
> worse, if the standard use case is to make a call back into the API resulting 
> in a possible loop of events.  
> 
> It appears from an initial search of the code that none of the providers or 
> other internal mechanisms rely on the notification of these events, so these 
> events are generated on behalf of the API user for notification and none of 
> our systems are affected by the choice.  So what are the use cases of API 
> users?  I'll give it some thought and see if I can some up with any scenarios.

that would be sincerely appreciated.

> You raise an interesting issue about creating threads; are you aware of any 
> environments that disallow threads?  I haven't come across any in my 
> experience to date.  I have used threads in applets?

certainly, there are plenty - inside application servers, notably servlets
etc, which are likely to be one of the first locations the api is used. on
the javamail-interest mailing list every second message is "i'm developing a
webmail application, how do i...?" - apparently the containers they're using
at the moment allow them to create threads, but serious asp environments
(including, potentially, their deployment environments) may not. as a server
administrator you'd want to have total control over the number of
threads/processes created anyway.
-- 
dog
zx750-p5 sl-mille ukrmma#18
sol lucet omnibus ... praeter anglorum