[Classpathx-javamail] Event Propagation

[Andrew Selkirk]

On November 25, 2001 10:04 am, you wrote:
> in the mail package already committed, there are 4 classes which have
> TODO comments about synchronous/asynchronous event propagation. if you
> could have a look at this whole issue (i know you and joey were working
> on an asynchrous mechanism, presumably much like sun's), and let me know
> what you think about it (what the dependencies and issues surrounding it
> might be), this would be enormously helpful. my main concern is that in
> certain environments (notably applets) you may not have the create thread
> privilege, so synchronous should really be chosen unless there is a
> compelling reason not to - can you think of one?

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.

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?

Andrew...