On Sep 16, 2016 10:54 AM, "Thiago Macieira" <thiago.macieira at intel.com> wrote: > > On sexta-feira, 16 de setembro de 2016 08:36:46 PDT Abhishek Sharma wrote: > > > If I recall correctly, the Scons files always set one or the other. > > > > Yes scripts will always default to ROUTING_EP. > > One problem that Greg faced could still occur when application will have its > > own makefile / sconscript and choose not to define ROUTING_X. Since > > octypes.h will be included in application source, it will result in > > different definition of OCDevAddr in stack and application. I can make a > > static assert in octypes.h to check that either of two should be available. > > Ah, I understand now. Yes, indeed, this is a bug and should be fixed. The code > should have: > > #if !defined(OC_ROUTING_EP) && !defined(OC_ROUTING_GW) > # error One of OC_ROUTING_EP and OC_ROUTING_GW should be defined > #endif > > Alternatively, we should drop the need for the EP #define and just assume > everything is an endpoint, unless OC_ROUTING_GW is set. > > > This will enable any vendor to still try stand alone-mode (No EP and GW) > > for debugging or local setup with a single SConscript change. If we choose > > to modify code everywhere for ex: to check only GW and assume EP is there, > > the flexibility mentioned above will be lost. > > As I argued when the feature came in: either it works for everyone without > changes in their clients, or the feature is misdesigned. There's no such thing > as "stand alone-mode". >
originally, I agreed with this. but now I've spent more time working with the code and reading the specs on the wiki I've changed my mind. most obviously : if I'm only building a local oic network with no bridging then I do not want *any* routing logic. it's all wasted overhead. we need not 2 but 3 build options: ROUTING_MODE :: NONE || EP || GW IMO the default should NONE. More generally: this feature is not OIC. IMO it should not be part of the standard Iotivity build. Iotivity is supposed to be the reference implementation of OIC. Nothing more, nothing less. Stuff like oic-internetworking (including also the cloud stuff) should be treated as a non-standard add-on, and clearly so-marked. in the case of "routing", I think also it should be clearly marked as EXPERIMENTAL (i.e. non-standard), insofar as it is based on a non-standard extension of CoAP. there are more problems I won't go into here other than to note them. mainly underspecification. what *exactly* is "oic/gateway" supposed to mean? what are it's properties? where is the raml spec? What about security? at the very least this kind of add-on should undergo a thorough and explicit security review. one you introduce internetworking you have a lot of issues that are not addressed by the proposal. e.g. you have to decide for each node one your local oic network whether is is allowed to access resources on a remote oic network or nor, including discovery querires. lots of other issues, none of which can simply be taken for granted. > The latest Bridging spec does this by... where can we find this? sincerely, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161010/39cffef6/attachment.html>
