On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross <[email protected]> wrote:

> https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
>
> Please take a look.  The intention:
>
>  - Organize the API consistently across languages, allowing for deliberate
> exceptions
>
>  - Put more frequently used items closer to hand, and less frequently used
> ones out of the way
>
>  - Put like things together in a named group
>
> This scheme is now in use to some extent by the C and Python variants, but
> there are some possibly non-semantic variations that I think are worth
> ironing out:
>
>  - Python is using utils, not util.  I don't care whether we go util or
> utils, but I'd very much like to avoid it being half one way and half the
> other.  If we decide utils, I'll update the wiki page.
>
>  - C is using reactor, not reactors.  Is the idea that it will have only
> one reactor implementation?
>

No that's not the intention, although what is in reactor.h should probably
be the basis for any other reactors.

The header files in C actually have a much stronger correspondence to
classes in python rather than than to packages. The C API uses header files
to identify objects, e.g. foo.h generally has a typedef pn_foo_t and a
bunch of "methods" named pn_foo_* for operating on pn_foo_t's. Sometimes
there are two related types grouped together, e.g. proton/event.h contains
pn_event_t and pn_collector_t since pn_event_t objects can't actually exist
on their own without a collector.

So some of the resemblance between C header files and python packages is
actually less strong than you suggest. C is just flatter because it doesn't
actually have packages.

Hopefully this is clear by now, but the reason it's reactor.h and not
reactors.h is because that is where pn_reactor_t and all it's related
pn_reactor_* operations are defined. If we were to add another reactor,
e.g. something based on libuv for example, I would expect that to go into
"proton/uv.h" and probably inherit/reference/reuse a lot of what is in
"proton/reactor.h".

--Rafael

Reply via email to