In the IoTivity.git there are lots of modules can be loaded into device. Let?s discuss how to make the binary.
: Whole as single one/all as separate ones?or .what is the minimal? set how to enable some component by build option. discovery-messaging server/client ? discovery/connectivity project (regardless udp, tcp and other transport) security-provisioning manager ? security project security-certificate manager ? security project security-Resource Manager ? security project tls-tcp ? security project or iotivity cloud project pub/sub & message broker ? iotivity cloud project cloud interface-client(device)/server ? iotivity cloud project resource-directory client/server - primitive service project or discovery/connectivity project ?? easy-setup mediator/enrollee - primitive service project notification-service provider/consumer - primitive service project resource-encapsulation client/server - primitive service project resource-container - primitive service project scene-manager local/remote - primitive service project coap-http-proxy server - primitive service project wsi - wsi project (Please add for missing item) Others are in separate repo or out of scope from device loading. BR, UZe Choi From: Gregg Reynolds [mailto:[email protected]] Sent: Thursday, August 18, 2016 4:56 AM To: myeong.jeong at samsung.com Cc: ts_tg; Dave Thaler; Uze Choi; iotivity-dev at lists.iotivity.org Subject: Re: [dev] IoTivity base layer scope and architecture 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 -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160823/4df88444/attachment.html>
