Filip Hanik - Dev Lists wrote:
If you don't care about this stuff, but still read the first line, do
our community a favor and get involved :)
I'm not sure I understand this. It could be interpreted in a derogatory way.
The API's are pretty much identical,
Yes, they are pretty much functionally identical. The problem is that
the interpretation of the same thing you are proposing is
overengineered, convoluted and very GC unfriendly. The sync was a funny
choice which made me start working on a separate branch, since:
- you were ignoring my messages all of a sudden for some reason
- you started adding more and more stuff I disagreed with
It's ok to do that as part of a proposal (like I did), but it's not the
right way if you do it in a regular branch.
callback()
- Remy - one time callback from the container on a Tomcat worker thread
- Filip - same functionality implemented, CometEvent.register(OP_CALLBACK)
I definitely like the register/unregister for events more than I like
the one time functionality of callback()/sleep().
OP_CALLBACK currently is implemented and working in trunk.
Why do I like register more? Cause we can add new operations in the
future without changing the API. This leads to more flexibility.
Currently OP_CALLBACK stays registered until it is "unregister"-ed. If
we wanted to achieve callback() functionality, we can add a
OP_CALLBACK_ONCE operation or simply change the behavior of existing
callback, without changing the API.
it is also possible to retrieve the state of a comet connection by
calling getRegisteredOps, something not available in the sandbox API.
sleep()
- Remy - deregister from the READ events
- Filip - same functionality exists,
CometEvent.unregister(OP_READ,OP_WRITE,OP_CALLBACK) or simply
CometEvent.unregister(OP_READ) if nothing else is registered.
Again, I think the trunk API is more flexible, and cleaner. sleep() is
associated with Thread.sleep() in every programmers head. and doesn't
really apply to an event based API.
This is implemented in trunk and working.
The connector should only care about IO, which only knows read and write
(and error, but obviously this is a special case, and I don't see you
registering for that).
Conclusion, both APIs are almost identical. I believe the trunk API is
more flexible and allows for additions of functionality in the future
without changing the API.
Remy's initial -1 to the trunk was based on the implementation, having
to synchronize etc. All that has been simplified and removed.
I would like to understand what extensions are desirable or envisioned,
since this this sort of extensions will make the connector
implementation to skyrocket in terms of complexity. I think the
connector should only care about IO, so this means: read, write, and a
generic callback. The user will write a piece of code which can listen
to any sort of event, and use the callback method: the callback is the
extension point as far as I understand.
Another flaw IMO is that read and write do not behave the same as far as
their "registration" go.
The trunk API also has the following additional methods and constructs:
- public enum CometConfiguration {COMET_BLOCKING, COMET_NON_BLOCKING};
- public void configure(CometConfiguration... options) throws
IllegalStateException; (note: as I have discussed, it seems possible to
abstract away blocking configuration from the user)
- public enum CometOperation {OP_CALLBACK, OP_READ, OP_WRITE};
- public CometOperation[] getRegisteredOps();
- the need to ask for a write event (it is quite crucial, and I found
out it could easily be hidden away)
So, similarly, the configuration is extensible. I would like to
understand what additional configuration should be exposed to the user
(personally, I solved the configuration problem when I noticed blocking
/ non blocking configuration was pointless).
I also dislike the thread checks you are using.
The last reason I would like to have a really simple (yet fully
functional) API is to avoid having duplicate APIs. The Servlet API may
tackle the Comet topic, and knowing Sun APIs, you may get the API of
your dreams :D
So therefor, the API's are almost identical, I would vote
sandbox API -> -1 -> API is simple but not extensible, names are not
intuitive as they are not event oriented.
trunk API -> +1 -> API is equally simple, more geared towards event
based API, more flexible, as I am sure new needs will need new
operations and events
I think the APIs are quite different in form, yet expose similar
functionality (at the moment, I'm waiting for the OP_JMS ;) ). Since
it's a user visible API, it's an important issue regardless of what you
think. I have my own vote (hehe ;) ):
- sandbox -> +1
- "trunk" -> -1 (overenginneered, more complex, thread checks)
The only thing not working in trunk at this moment is non blocking, but
after doing the research, this is a major surgery to try to do within
the existing buffer/filter API
Actually, this is very simple to implement. Read is obvious. For write,
the algorithm for the flushBuffer method would be very similar to what
it is now, but if a write returns 0, leftover bytes would be put in a
ByteChunk. isWriteable, if called, will return false, and place the
socket in the poller with write notifications.
There are two options at that point:
- the servlet does not use isWriteable (so does not care about possible
congestion when writing): on the next write, the leftover bytes are
flushed (most likely the additional bytes which are sent would be added
to the ByteChunk, to attempt to maximize the amount of bytes written -
in case somehow it works), and if writing still fails an IO exception is
thrown if the write was called asynchronously; if the write was
synchronous (= called from a Tomcat thread), it is possible for ease of
use to make another write, but switch to blocking mode
- the servlet uses isWriteable: no problem, it will get false, stop
writing immediately (unless the guy did not understand the API, lol),
and a write event will be eventually generated by the poller; when this
write occurs, the leftover bytes - if any - will be flushed (if somehow
there are leftovers, then it's "go back to the poller, you lazy stupid
connection !"), isWriteable will start returning true, and a write event
will be sent to the servlet
I'd rather delay such an attempt until we can reach consensus on the API
and the "simple stuff".
I agree a consensus should have been reached *on month ago* :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
