[Isolate-interest] deafening silence about refactored APIs

[Jesper Zuschlag]

I have been looking into the strawman API for some time now and have be trying to interpret it by comparison to the original public review API and put it into the CLDC perspective. 

here is a quick overview of the notes that I have made until now:

* I like the refactoring of the quite large Message class into separate message classes for each message type

* I sympathize with the use of type-safe enum pattern for ExitReason and Type but in order to fit the API into CLDC/MIDP plain static final int's could be used instead. It is not that big as problem as these constants are not used 

* As messages are pure copy based I assume that some kind of serialization/deserialization mechanism must be available. Consequently, it will not be possible to implement MessageObject in the CLDC/MIDP platform as it lacks Java level serialization/deserialization.

* Are the details of ownership of object that are handed over from one isolate to another intentionally left unspecified. I mean what happens if e.g. a socket is handed over from one isolate to another that subsequently both isolates tries to use this socket. Although, the two socket are distinct on the Java level (as they are living in separate isolates) they could very well map down to the same underlying socket in the host system.

* Why does the method “byte[] getData(byte[] b)” from CompsiteMessage take a byte array as argument? Is it the resulting array which must be provided by the caller?

* The security aspects in the context of CLDC/MIDP must be analyzed and described further

* Most message types are obviously not relevant for CLDC/MIDP (FileMessage,  SocketMessage, ByteBufferMessage, ChannelMessage, ObjectMessage). J2ME include a replacement API in shape of the Generic Connection API although I’m currently uncertain if it would be possible to add some kind of Connector message type because of the extensible nature of the GCF API.

* I have tried categorized the types in accordance to whether they should be included (either mandatory or optional) in a CDLC/MIDP subset or not included in order to get an estimate on the size of such a subset:

Mandatory classes:

javax.isolate.Message
javax.isolate.DataMessage
javax.isolate.Isolate
javax.isolate.IsolateParameters
javax.isolate.Link
javax.isolate.StatusMessage
javax.isolate.StatusMessage.ExitReason <-- Could be replaced by static final int’s
javax.isolate.StatusMessage.Type <-- Could be replaced by static final int’s
javax.isolate.IsolateStartException
javax.isolate.io.IOMessage
javax.isolate.io.IOIsolateParameters
javax.isolate.io.LinkClosedException

Classes that would be “nice to have”

javax.isolate.io.DataMessageInputStream
javax.isolate.io.DataMessageOutputStream
javax.isolate.util.MessageHandler
javax.isolate.util.MessageDispacther
javax.isolate.util.MessageVisitor (must be a subset too)

Classes without relevance for CLDC/MIDP subset

javax.isolate.io.FileMessage
javax.isolate.io.SocketMessage
javax.isolate.nio.ByteBufferMessage
javax.isolate.nio.ChannelMessage
javax.isolate.tbd.IsolatePermission
javax.isolate.tbd.ObjectMessage

* I find it strange that some parties should find the API already to large for CLDC/MIDP. Which J2ME authorities were you talking about?

Just my initial thoughts!

/Jesper