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. > > > > 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. 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. 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 b) the resources (discovery & connectivity) C++ API c) a specific service -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
