Re: Proton engine api naming proposal
On Thu, Sep 13, 2012 at 9:36 AM, Justin Ross jr...@redhat.com wrote:
On Thu, 13 Sep 2012, Ted Ross wrote:
I'm not crazy about the work-processing function names as they seem to
disregard the grammar. Should they not all be pn_connection_* functions?
I agree about this. I would definitely prefer to see pn_connection_* for
the connection-scoped work interfaces. I guess I thought I was pressing my
luck, :).
I think there actually already is a consistent rule here, it's just missing
from your grammar. Wherever there is a linked list of things, the API uses
the form:
pn_collection_head(pn_root_t)
pn_collection_next(pn_element_t_t)
I think this is better than trying to stick it all on the root or all on
the element or splitting it up between the two. For example I think
pn_work_head is better than pn_head_delivery as the latter gives you less
information. The fact that it is a delivery is already contained in the
type signature, and there are multiple lists of deliveries maintained by
the engine, so just knowing that it is a list of deliveries isn't
sufficient. Even scoping it to the connection is not terribly useful as
there may well be multiple lists of deliveries on the connection. The
relevant info here is that it is the head of the work queue, a concept that
we actually do (or should) explain at length (somewhere). I would argue
that the work queue is actually the relevant concept/noun here, it just
doesn't have it's own lifecycle since it is a component of the connection.
In Java or some other garbage collected language you might see the noun
expressed directly as an object, e.g.:
WorkIterator work = new WorkIterator(connection);
while (...) {
Delivery d = work.next();
}
This exact pattern of course is extremely cumbersome and inefficient in C
since you'd have to malloc an object just to iterate, so naturally you use
a linked list instead, but I think conceptually the noun still exists and
if we lose the noun from the name we are missing an important key to index
into the documentation.
--Rafael
Re: Proton engine api naming proposal
- Original Message -
On Thu, Sep 13, 2012 at 9:36 AM, Justin Ross jr...@redhat.com
wrote:
On Thu, 13 Sep 2012, Ted Ross wrote:
I'm not crazy about the work-processing function names as they
seem to
disregard the grammar. Should they not all be pn_connection_*
functions?
I agree about this. I would definitely prefer to see
pn_connection_* for
the connection-scoped work interfaces. I guess I thought I was
pressing my
luck, :).
I think there actually already is a consistent rule here, it's just
missing
from your grammar. Wherever there is a linked list of things, the API
uses
the form:
pn_collection_head(pn_root_t)
pn_collection_next(pn_element_t_t)
I think this is better than trying to stick it all on the root or all
on
the element or splitting it up between the two. For example I think
pn_work_head is better than pn_head_delivery as the latter gives you
less
information. The fact that it is a delivery is already contained in
the
type signature, and there are multiple lists of deliveries maintained
by
the engine, so just knowing that it is a list of deliveries isn't
sufficient. Even scoping it to the connection is not terribly useful
as
there may well be multiple lists of deliveries on the connection. The
relevant info here is that it is the head of the work queue, a
concept that
we actually do (or should) explain at length (somewhere). I would
argue
that the work queue is actually the relevant concept/noun here, it
just
doesn't have it's own lifecycle since it is a component of the
connection.
In Java or some other garbage collected language you might see the
noun
expressed directly as an object, e.g.:
WorkIterator work = new WorkIterator(connection);
while (...) {
Delivery d = work.next();
}
This exact pattern of course is extremely cumbersome and inefficient
in C
since you'd have to malloc an object just to iterate, so naturally
you use
a linked list instead, but I think conceptually the noun still exists
and
if we lose the noun from the name we are missing an important key to
index
into the documentation.
--Rafael
All great stuff. I guess I'm surprised there aren't at least 2 standard C
coding styles out there to choose from.
So from now on I'll refer to this style as Rossrafi.
Dude, I can't believe you're coding C like that. Why aren't you using
Rossrafi?
William
Re: idiomatic python API
I would strongly favour shared documentation as much as possible. The concepts , examples etc.. can be handled via a common document and we might have to have some language specific sections. Rajith On Wed, Sep 12, 2012 at 3:42 PM, Rafael Schloming r...@alum.mit.edu wrote: Hey Everyone, I've put together a draft of an idiomatic python API that sits on top of the swig bindings. It's a very thin layer, all it does is translate from a procedural interface to an object oriented one, handling memory management and adding checked exceptions along the way. I've posted it here: https://issues.apache.org/jira/browse/PROTON-23 Notably it does not have any docs yet, this is partly because I'm lazy and partly because it would be nice to figure out a way to share documentation between languages. Please check it out and let me know if you have any comments. --Rafael
Re: Ruby stable API design
On Thu, Sep 13, 2012 at 04:46:00PM -0400, Rajith Attapattu wrote: On Mon, Sep 10, 2012 at 1:36 PM, Rafael Schloming r...@alum.mit.edu wrote: On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce dpie...@redhat.comwrote: methods on Messenger and Message objects and by tying pn_messenger_free and pn_message_free into the respective destructors, we could make things a whole lot safer, e.g. avoid dangling pointers and the like that a user could use to segfault the interpreter. Darryl, you could use %typemap(freearg) to ensure the respective free function is called to cleanup. How it gets called is also automatically handled by swig based on the host language. I'll take a look at that. I did use some simple Ruby to make sure that a destructor method is invoked on garbage collection and also shutdown, but will look at something more automated like this. Thanks. :) -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp89oo4hSgky.pgp Description: PGP signature
[jira] [Created] (PROTON-25) Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed.
Ted Ross created PROTON-25: -- Summary: Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed. Key: PROTON-25 URL: https://issues.apache.org/jira/browse/PROTON-25 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Ted Ross After a connection has been established and opened both remotely and locally, if that connection is closed uncleanly (i.e. the socket is closed without any handshake), the connection object will not transition to PN_REMOTE_CLOSED. The closed connection is awakened and processed by the driver, but its state is not changed. Any state the application has associated with the connection, its sessions, and its links will not be cleaned up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
