* Alan Bateman:
> It should be feasible but it would likely be a platform/provider
> specific (mapping to the socket domain, translation to/from the socket
> address, etc.). It would be good if someone had the cycles to
> prototype this and come back with a proposal. Is this something you
> might
On 08/27/2008 03:00 PM, Florian Weimer wrote:
* David M. Lloyd:
Doing this: UnixSocketChannel.open(String) or similar seems more
correct to me.
You need to do this twice, for SOCK_STREAM and SOCK_DGRAM.
If you go the route of using SocketChannel.open(SocketAddress), for
example, now you've
* David M. Lloyd:
> Doing this: UnixSocketChannel.open(String) or similar seems more
> correct to me.
You need to do this twice, for SOCK_STREAM and SOCK_DGRAM.
> If you go the route of using SocketChannel.open(SocketAddress), for
> example, now you've got instanceof checks for each socket type.
David M. Lloyd wrote:
:
No, the concern is just that the SocketAddress hierarchy is just kind
of broken (the indicators are the fact that it's an empty abstract
class, and that anywhere it's used, it's immediately casted to a more
specific type). You could change this, but it still seems to m
On 08/26/2008 11:12 AM, Alan Bateman wrote:
David M. Lloyd wrote:
:
I just mean, what would be the benefit of using SocketAddress rather
than using a String or Path directly? You can avoid the difficulties
of extending SocketAddress by simply not using it.
If the protocol or socket address is
David M. Lloyd wrote:
:
I just mean, what would be the benefit of using SocketAddress rather
than using a String or Path directly? You can avoid the difficulties
of extending SocketAddress by simply not using it.
If the protocol or socket address is specified by String then the
implementation
On 08/26/2008 09:20 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
FWIW, a while back I prototyped an "in tree" solution for
SocketChannel. The primary motive was to allow for Sockets Direct
Protoco
Florian Weimer wrote:
[Extensible socket types]
:
Do you think it would be possible to do this out-of-tree? I think I
could port my client code to SocketChannel. (If I require a customized
JDK, it will raise a few eyebrows.)
It should be feasible but it would likely be a platform/provi
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
FWIW, a while back I prototyped an "in tre
* Alan Bateman:
[Extensible socket types]
> This is a good topic. For stream and datagram oriented protocols then
> it would indeed be desirable to allow for communication domains other
> than IP. In theory it should be possible to use a SocketImpl for this
> but there are checks in the Socket AP
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources. Otherwise, you won't get any interoperability
with existing code, you need to deal with the fine points of
* Christopher Hegarty:
> I just sent a mail to the nio-discuss [1] mailing list requesting
> feedback on a proposed Java API for SCTP. If you are interested in
> this topic please read this mail which provides a some details and a
> link to the API. Feedback is really welcome.
I've been wondering
13 matches
Mail list logo
