Re: ConnectionImpl::getWorkSequence()
I doubt there is a good reason, however I suspect the new events API would probably be an easier alternative to getWorkHead() and friends. Unfortunately there aren't docs for the Java version of the API yet, but it shouldn't be difficult to figure out how to use it from the C API docs. --Rafael On Mon, Mar 17, 2014 at 12:44 PM, Clebert Suconic csuco...@redhat.comwrote: Why getWorkSequence is not exposed through Connection? Forcing me to use getWorkHead() would make me re-implement the exact same Iterator that's being implemented at ConnectionImpl(); Why not just expose it properly? Iterators are common practice in Java anyways.
Re: ConnectionImpl::getWorkSequence()
On Mar 18, 2014, at 11:25 AM, Rafael Schloming r...@alum.mit.edu wrote: I doubt there is a good reason, however I suspect the new events API would probably be an easier alternative to getWorkHead() and friends. Unfortunately there aren't docs for the Java version of the API yet, but it shouldn't be difficult to figure out how to use it from the C API docs. I know nothing about the new events API... but I think it would be a mistake to have java being an exact mirror of the C API. Things like Iterators are pretty common in Java. Right now my implementation is forced to cast to ConnectionImpl what breaks the purpose of the interface. Can you guys move it? --Rafael On Mon, Mar 17, 2014 at 12:44 PM, Clebert Suconic csuco...@redhat.comwrote: Why getWorkSequence is not exposed through Connection? Forcing me to use getWorkHead() would make me re-implement the exact same Iterator that's being implemented at ConnectionImpl(); Why not just expose it properly? Iterators are common practice in Java anyways.
Re: ConnectionImpl::getWorkSequence()
Unfortunately there aren't docs for the Java version of the API yet, but it shouldn't be difficult to figure out how to use it from the C API docs. BTW I don't need the javadoc.. just point me what class are you talking about and I will figure out
Re: ConnectionImpl::getWorkSequence()
On Tue, Mar 18, 2014 at 11:43 AM, Clebert Suconic csuco...@redhat.comwrote: On Mar 18, 2014, at 11:25 AM, Rafael Schloming r...@alum.mit.edu wrote: I doubt there is a good reason, however I suspect the new events API would probably be an easier alternative to getWorkHead() and friends. Unfortunately there aren't docs for the Java version of the API yet, but it shouldn't be difficult to figure out how to use it from the C API docs. I know nothing about the new events API... but I think it would be a mistake to have java being an exact mirror of the C API. Things like Iterators are pretty common in Java. I didn't say it was an exact mirror, just that it's close enough that you should be able to figure it out from the C documentation. I would think that would be a good thing in general. As for iterators, in this particular case it's not really C vs Java, it's the fact that the link/delivery data structure is a linked list, and Java's collection API doesn't really do linked lists. (I'm quite familiar with what java does offer in terms of java.util.LinkList, but I don't really count that as it is entirely missing any sort of node abstraction.) Of course that doesn't preclude offering iterators, however iterators will never be able to fully express what the underlying data structure is attempting to represent. That said I've no objection to making the iterator available as a convenience, although I'd probably call it getWorkIterator rather than getWorkSequence. Right now my implementation is forced to cast to ConnectionImpl what breaks the purpose of the interface. Can you guys move it? I'm happy to accept a patch for it, although I'd encourage you to check out the events stuff in any case. --Rafael
Re: ConnectionImpl::getWorkSequence()
On Tue, Mar 18, 2014 at 11:53 AM, Clebert Suconic csuco...@redhat.comwrote: Unfortunately there aren't docs for the Java version of the API yet, but it shouldn't be difficult to figure out how to use it from the C API docs. BTW I don't need the javadoc.. just point me what class are you talking about and I will figure out The relevant classes would be org.apache.qpid.proton.engine.Collector, and org.apache.qpid.proton.engine.Event. You pretty much just create a Collector, register it with a connection by calling Connection.collect(...) and then you can use the Collector API to access any events that have occurred. --Rafael
Re: ConnectionImpl::getWorkSequence()
Right now my implementation is forced to cast to ConnectionImpl what breaks the purpose of the interface. Can you guys move it? I'm happy to accept a patch for it, although I'd encourage you to check out the events stuff in any case. --Rafael I sure will take a look on the events stuff.. I thought you were objecting Iterators just because of the C / Java API compatibility. I would know how to provide a patch if it was git or github. I'm a bit rusty on SVN.. would you be ok if I provided you a git branch with a commit? I'm not a proton committer yet (although I'm planning to get down to it a lot more).
Re: ConnectionImpl::getWorkSequence()
On Tue, Mar 18, 2014 at 2:23 PM, Clebert Suconic csuco...@redhat.comwrote: Right now my implementation is forced to cast to ConnectionImpl what breaks the purpose of the interface. Can you guys move it? I'm happy to accept a patch for it, although I'd encourage you to check out the events stuff in any case. --Rafael I sure will take a look on the events stuff.. I thought you were objecting Iterators just because of the C / Java API compatibility. Ah, no, not as such. If you wanted to limit the Java side to only using iterators that would break the python tests that run against both the C and Java codebase, but providing iterators as a convenience is certainly not an issue. I would know how to provide a patch if it was git or github. I'm a bit rusty on SVN.. would you be ok if I provided you a git branch with a commit? I'm not a proton committer yet (although I'm planning to get down to it a lot more). A pointer to a git commit would be excellent. --Rafael
