Thank you Habib, I listed up the initial sum up as follows.
TARGET_TRANSPORT = ALL, BT, BLE, IP, NFC default=IP/ALL >>
API is not different each other, We cannot make it separate module I think
ROUTING = GW, EP default=EP
>> Can we move the GW Option code, into separate library?
WITH_MQ = SUB, PUB, BROKER, OFF default=OFF >>
Can we make the MQ code into separate library?
SECURED = 0,1 default=0
>> Only Secured will be used sooner, (With Secured build we can
access freely by setting the configuration.)
DTLS_WITH_X509 = 0, 1 default=0
>> Need to be coupled with secured option.
RDMODE = CLIENT, SERVER default=CLIENT >>
Can we move the client code into separate library? Can we move the server
code into the other separate library?
WITH_RA default=False
>> Removing it
WITH_RA_IBB default=False
>> Removing it
WITH_TCP default=False
>> API is not changed. We cannot make it separate module I think
WITH_CLOUD default=False
>> Can we move the Cloud code, into separate library?
BTW WITH_PRESENCE
>> Removing it
>From the list we need to evaluate the feasibility of modularity, this result
>looks key decision point to execute above sun up, I think.
BR, Uze Choi
From: Habib Virji [mailto:[email protected]]
Sent: Thursday, August 25, 2016 7:07 PM
To: '???(Uze Choi)'; iotivity-dev at lists.iotivity.org
Cc: 'ts_tg'
Subject: RE: [dev] [ts_tg] RE: Re: [ts_tg] IoTivity build options query for
cleaning up
Hi Uze,
For option #1 RD will be still behind flag and you will still need a separate
built to check with and without RD functionality. It will perhaps not change
much on Jenkins as we will still need two separate builds.
Option # 2 is a right approach. As in RD case is not an mandatory item and RD
application and cloud application can include RD library for their
application. This will help in reducing the size of ocstack.
Since OCF has some mandatory and some optional items. RD is not a mandatory
item, it should not be part of octypes.h. There will be certain parts which
will require in ocstack specially parsing and sending of the cbor packets but
that can be modularized.
We should introduce a structure where for each optional feature will be part of
src/addon/<feature>. Example src/addon/monitoring,
src/addon/resource-directory, etc.
resource
->csdk
--> stack
--->src
----> addon
-----> resource-directory
Each directory in addon can implement an OCF optional functionality. They will
produce a separate library for each resource.
BTW WITH_PRESENCE is not used in any SConscript as it is defined by default in
octypes.h, it should be perhaps removed from octypes.h and be considered as a
built option or move functionality in addon.
Regards
Habib
From: iotivity-dev-bounces at lists.iotivity.org
[mailto:[email protected]] On Behalf Of ???(Uze Choi)
Sent: 25 August 2016 06:21
To: iotivity-dev at lists.iotivity.org
Cc: 'ts_tg'
Subject: Re: [dev] [ts_tg] RE: Re: [ts_tg] IoTivity build options query for
cleaning up
Let?s get the consensus by defining the criteria.
Pick-up the RD example, Let?s assume RD client component has its own API.
There are two option we can think about.
1. Place APIs in ocstack.h use build option #RD to decide to include or
exclude it ocstack.lib
2. Separate header file as ocrdclient.h do not use the build
option ocstack.lib, ocrdclient.lib
#1 : Increase modularity, decrease the build option maintenance cost, decrease
the Jenkins build job.
#2 : decrease some binary overhead for symbol, user should recognize it.
However, this is valid only in case rd logic can be taken apart from ocstack.
Anyway, I found another build option ?WITH_PRESENCE?, please reply if anyone
find something which you are related with.
BR, Uze Choi
From: ts_tg at openconnectivity.org [mailto:[email protected]] On
Behalf Of MyeongGi Jeong
Sent: Thursday, August 25, 2016 7:12 AM
To: Uze Choi; iotivity-dev at lists.iotivity.org
Cc: 'ts_tg'
Subject: [ts_tg] RE: Re: [dev] [ts_tg] IoTivity build options query for
cleaning up
Hi, Uze.
That's good idea to minize the number of build-options.
But, the example is not agreeable.^^.
What is the module you mean ?, separate file ??
Please explain the reason why you think like that ??
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 : ??? < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>
S6(??)/??/IoT Lab(S/W??)/????
Date : 2016-08-24 18:35 (GMT+9)
Title : Re: [dev] [ts_tg] IoTivity build options query for cleaning up
Scons Build option looks as follows.
TARGET_OS = linux, tizen, android, ios, windows, darwin, arduino, msys_nt,
yocto default=host
TARGET_ARCH = x86, x86_64, arm, arm-v7a, arm64, arm64-v8a, armeabi-v7a,
armeabi-v7a-hard, avr, i386, armv7, armv7s, powerpc, powerpc64, mips, mipsel
default=deault_arch
TARGET_TRANSPORT = ALL, BT, BLE, IP, NFC default=IP/ALL
ROUTING = GW, EP default=EP
WITH_MQ = SUB, PUB, BROKER, OFF default=OFF
SECURED = 0,1 default=0
DTLS_WITH_X509 = 0, 1 default=0
RDMODE = CLIENT, SERVER default=CLIENT
WITH_RA default=False
WITH_RA_IBB default=False
WITH_TCP default=False
WITH_CLOUD default=False
LOGGING default=logging_default
VERBOSE default=False
RELEASE = true/yes/1 default=True
TEST = 0, 1 default=0
SIMUALTOR default=False
BUILD_SAMPLE = ON/,OFF default=ON
WITH_PRESENCE
ANDROID_NDK path
ANDROID_HOME path
ANDROID_GRADLE path
MSVC_VERSION
SHIELD = WIFI, ETHI
DEVICE_NAME ??
I think it will be better to minimize it in case of feature and independent
from others.
For example) If WITH_CLOUD, RDMODE generates the additional API, then make it
as separate module instead of using Build option.
Not used items such as WITH_RA, WITH_RA_IBB need to be removed, I think.
More items make the maintenance hard.
BR, Uze Choi
From: ts_tg at openconnectivity.org [mailto:[email protected]] On
Behalf Of ???(Uze Choi)
Sent: Monday, August 22, 2016 2:47 PM
To: iotivity-dev at lists.iotivity.org
Cc: ts_tg
Subject: [ts_tg] IoTivity build options query for cleaning up
Hi All,
During the last OCF OSWG meeting (even though we are very late), there is a
requirement to list and clean up the build options of IoTivity.
Please share the build option which each developer is interested or associated
with your task.
If no response from this query, let me remove the build option remained for
source code cleaning.
BR, Uze Choi
_______________________________________________
iotivity-dev mailing list
<mailto:iotivity-dev at lists.iotivity.org> iotivity-dev at lists.iotivity.org
<https://lists.iotivity.org/mailman/listinfo/iotivity-dev>
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
<http://v70ext.samsung.net/mail/ext/v1/external/status/update?userid=myeong.jeong&do=bWFpbElEPTIwMTYwODI0MjIxMTMzZXBjbXMxcDIyY2MxZTkzNmM3NTI3OWFhMjcxNzliYzg2NTg2NWYyMCZyZWNpcGllbnRBZGRyZXNzPXRzX3RnQG9wZW5pbnRlcmNvbm5lY3Qub3Jn>
-------------- next part --------------
HTML ?????? ??????????????...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160826/d5d047ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?????? ?? ????????.
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160826/d5d047ac/attachment.gif>
