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:[email protected]] 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: [email protected] [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) -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160727/36355952/attachment.html>
