On Mon, 2015-02-09 at 13:24 -0800, Thiago Macieira wrote: > On Monday 09 February 2015 13:09:01 Keane, Erich wrote: > > On Mon, 2015-02-09 at 13:04 -0800, Thiago Macieira wrote: > > > 1) is this user-visible API? If not, then choose whatever and it doesn't > > > matter. > > > > We don't intend them to use it, however it IS C, so it is in the global > > namespace. Additionally, a few types from it are exposed (CAToken). > > Everything that is exposed is user-facing API and needs to form a cohesive > unit.
Agreed. > > > > > > 2) if it's visible to the user, can it be used without the rest of > > > IoTivity? > > > I.e., is it a generic abstraction for connectivity that would > > > allow me to send arbitrary unicast and multicast packets of my choosing? > > > > I don't see a reason why they couldn't, but it isn't intended to be used > > separately IIRC. > > Can it be used, today, in its form? If not, is it coming soon (before 1.0)? > If > the answer is "no" to those questions, then it's part of the IoTivity API and > should not be distinct from it. That includes any types exposed to the user. It SHOULD be reasonably usable. The API is set, though not everything functions. I imagine by 1.0 that is the case. > And by "exposed", I don't mean only what's documented. I mean everything that > is present in a public header that users are expected to include, directly or > indirectly. Concur-- We likely need to do a severe cleanup in this regard. Our #include s are quite difficult in this situation. > If only a few types are exposed to the user, we can easily wrap them in > IoTivity-style names and drop the #includes. Otherwise, rename everything. > > > > > For the includes, are we saying the include directory should now be > > > > formed like: > > > > "<iotivityRoot>/resource/csdk/include/iotivity/stack.h"? (note removal > > > > of the oc prefix in that file name)? > > > > > > > > > I'd prefer: > > > <iotivityroot>/include/iotivity/stack.h > > > > The issue with that is we also have the 'service' directory at that > > root, which would be awkward I suspect. > > I don't see how that is an issue. All headers should be in <root>/include, > regardless of whether they come from the C base library, the resources C++ > library or the service C++ libraries. > > But let's instead take a step back and decide what we document that users > need > to #include in their applications. Can you answer for: > > a) the "lite", base C API <root>/resource/csdk/stack/include/ocstack.h > b) the resources (discovery & connectivity) C++ API <root>/resource/include/OCApi.h > c) a specific service Unsure, but It looks like: <root>/service/<program name>/sdk/inc/<program name>.h
