This makes good sense on its own, but it doesn't help with our goal of naming and grouping together a "growable library of like things". In other words, if we end up with many reactor implementations, it won't be very approachable to have them littered around as dissimilar peers to reactor.h.
I assume this is why you have handlers.h: so you don't need to define a header file for each handler implementation. Down the line, we could add a reactors.h, but then we have reactor.h and reactors.h--not good. We could address the concern through directory structure or perhaps through a naming convention: reactor.h with reactor_$variant.h. The latter pattern seems to be relatively common. I find types.h strange against all of this. Are the endpoint types collected there in order to solve a dependency problem? It contains some but definitely not all of the non-amqp-datatype types. http://qpid.apache.org/releases/qpid-proton-0.8/protocol-engine/c/api/types_8h.html On Wed, Jan 28, 2015 at 5:25 PM, Rafael Schloming <r...@alum.mit.edu> wrote: > On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross <justin.r...@gmail.com> > 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 >
