On Jul 31, 2016 6:00 PM, "MyeongGi Jeong" <myeong.jeong at samsung.com> wrote: > > Hi, > > I understand that the agreement for the layered architecture is based on feature set. > > And the feature set is related the interoperability of IoTivity/OCF enabled devices. > > So, discovery, messaging(protocol) and security features currently compose the base layer, am I right ? > > If some other features want to be located in the base layer, > > the relationship with discovery/messaging/security interoperability might be required, I think. >
+1 My 2 cents: the iotivity "kernel" should be absolutely minimal: nothing beyond what is required by the OCF (OIC?) protocol. FWIW I would also prefer that it be 100% C. Most if not all of the "services" look like applications to me. I would break them out into seperate repositories. I would also point out that the "audience" for Iotivity includes not only app devs but also tool vendors. It should be easy for Acme Tool Corp. to build an Iotivity product that uses e.g. their own optimized RD component. Or a Java SDK that provides an API that differs from that official one (e.g.one that does not use the C++ layer.). Etc. gregg > > Thanks. > > Best Regards, > > --- > > MyeongGi Jeong > > Principle Engineer, Software Architect > > Software R&D Center, Samsung Electronics Co., Ltd. > > +82-10-3328-1130 | +82-2-6147-7699 > > > > > > --------- Original Message --------- > > Sender : ??? <uzchoi at samsung.com> S6(??)/??/IoT Lab(S/W??)/???? > > Date : 2016-07-27 15:31 (GMT+9) > > Title : Re: [dev] IoTivity base layer scope and architecture > > > > If something is in the service layer, how should we provide the library set? > > > > In case of windows or android, we can approach as SDK concept. > > Under the SDK concept, should we provide granular library for each service with separating server side and client side? > > In the small embedded device, small set library separation will eventually make user confused. > > > > BR, Uze Choi > > From: Dave Thaler [mailto:dthaler at microsoft.com] > Sent: Tuesday, July 26, 2016 11:56 PM > To: ???(Uze Choi); iotivity-dev at lists.iotivity.org; ts_tg > Subject: RE: [dev] IoTivity base layer scope and architecture > > > > If I understand the architecture correctly, the base layer should be resources that are mandatory to exist in all devices, > > and the service layer should be for resources/services that are optional. If that?s correct, then a COAP/HTTP proxy should be > > in the service layer. > > > > The page you referenced isn?t clear about what the guideline is though, and so I think it should be updated. > > > > Dave > > > > From: iotivity-dev-bounces at lists.iotivity.org [mailto: iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ???(Uze Choi) > Sent: Tuesday, July 26, 2016 4:17 AM > To: iotivity-dev at lists.iotivity.org; ts_tg <ts_tg at openinterconnect.org> > Subject: [dev] IoTivity base layer scope and architecture > > > > Hi IoTivity, > > > > Regarding the IoTivity architecture, let me gather opinions regarding the base layer scope. > > Currently CoAP-HTTP proxy is being argued about layer position. > > RD, collection and cloud related code need discussion whether they are worth of being in base layer. > > Previously group related feature has been argued one year before. > > Anyway, Please give the opinion for base layer scope, which may affect the mandatory API for extended platform and binary packaging unit. > > You can refer to the previously defined architecture posted in the wiki ( https://wiki.iotivity.org/architecture.) > > > > BR, Uze Choi (OSWG Developer Ecosystem Build TG Chair) > > _______________________________________________ > > iotivity-dev mailing list > > iotivity-dev at lists.iotivity.org > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160817/8ccc1e8b/attachment.html>
