Hi folks,
So the only issue raised for these API changes was the implementation
issue of determining the Decoder type, but I think we solved it.
So I'll incorporate these into the next draft,
Thanks,
- Danny
On 10/24/12 6:15 PM, Danny Coward wrote:
> Hello experts,
>
> Here's a list of API suggestions from the EDR to get things going,
> from larger to smaller. Let me know what you think - I've put my own
> thoughts on each.
>
> A) Consolidate MessageHandlers (Issue
>
> Currently we have MessageHandler.Text, MessageHandler.Binary,
> MessageHandler.AsyncText, MessageHandler.AsyncBinary,
> MessageHandler.BinaryStream, MessageHandler.CharStream,
> MessageHandler.DecodedObject and MessageHandler.Pong.
>
> The same functionality could be consolidated into two handler
> interfaces instead, for example:
>
> MessageHandler<T>
> void onMessage(T message)
>
> with allowable types T of String, ByteBuffer, InputStream, Reader,
> Object, and a new interface PongMessage, and
>
> AsyncMessageHandler<T>
> void onMessage(T partialMessage, boolean isLast)
>
> with allowable types String, ByteBuffer.
>
> IMO: Some type of consolidation seems cleaner to me, and also a little
> simpler to extend to other types in the future.
>
>
> B) Add getURI() to ClientConfiguration
>
> IMO: This I think is an oversight. Implementations need this,
> otherwise they don't know where to connect the client endpoint to.
>
> C) Add checked exceptions to ClientContainer.connectToServer and
> ServerContainer.publishServer methods.
>
> For example, a new ConnectException, thrown in the case when the
> connect or publish fails.
>
> IMO: This makes sense to me.
>
> D) API fixes - as reported by Mark during implementation.
>
> Here's a long list of smaller API nits,
>
> 1. DecodeException / EncodeException
> Parameter ordering is inconsistent
> (ByteBuffer, String) vs. (String, Object)
>
> IMO: Should be consistent - will change ordering on EncodeException to
> match pattern on DecodeException unless I hear otherwise.
>
> 2. DefaultClientConfiguration
> getExtensions() returns null
> setExtensions() has a parameter of preferredExtensions
> (should probably be extensions)
>
> IMO: will fix unless I hear otherwise.
>
> 3. CloseReason
> No accessor for closeCode
> No accessor for reasonPhrase
>
> IMO: An oversight, will add unless I hear otherwise.
>
> 4. Methods in public interfaces do not themselves need to be declared
> public. (style issue / choice)
>
> IMO: Will defer to majority here, but I prefer public declaration.
>
> 5. Endpoint
> Parameter ordering is inconsistent
> onClose(Session, CloseReason) vs. onError(Throwable, Session)
> Parameter naming is inconsistent s vs. session
>
> IMO: Will make consistent, Session as last parameter unless I hear
> otherwise.
>
> 6. Generics
> API uses raw types in a few places.
>
> IMO: Will fix unless I hear otherwise.
>
> 7. Session
> s/getRemoteL/getRemote/
>
> IMO: oops, will fix unless I hear otherwise.
>
> Thanks,
>
> - Danny
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation