ConnectionImpl::getWorkSequence()

[Clebert Suconic <cs...@redhat.com>]

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()

[Rafael Schloming <rh...@alum.mit.edu>]

On Tue, Mar 18, 2014 at 2:23 PM, Clebert Suconic <cs...@redhat.com>wrote:

> >
> >>
> >> 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

Re: ConnectionImpl::getWorkSequence()

[Clebert Suconic <cs...@redhat.com>]

> 
>> 
>> 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()

[Rafael Schloming <rh...@alum.mit.edu>]

On Tue, Mar 18, 2014 at 11:43 AM, Clebert Suconic <cs...@redhat.com>wrote:

> On Mar 18, 2014, at 11:25 AM, Rafael Schloming <rh...@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()

[Rafael Schloming <rh...@alum.mit.edu>]

On Tue, Mar 18, 2014 at 11:53 AM, Clebert Suconic <cs...@redhat.com>wrote:

> >>
> >>
> >> 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()

[Clebert Suconic <cs...@redhat.com>]

>> 
>> 
>> 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()

[Clebert Suconic <cs...@redhat.com>]

On Mar 18, 2014, at 11:25 AM, Rafael Schloming <rh...@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 <cs...@redhat.com>wrote:
> 
>> 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()

[Rafael Schloming <rh...@alum.mit.edu>]

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 <cs...@redhat.com>wrote:

> 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.