[dev] IoTivity Engineering Snapshot for PF13

[최우제 (Uze Choi)]

Dear IoTivity developer,



We made a tag for Plugfest 13 preparation.

-   Tag name : PF13_PRE

Please use this version as baseline for Plugfest preparation and
participation.



Initially this engineering snapshot was intended to resolve CTT gap by
today.

However there are still some issues to be resolved yet. Most items are
security issues.

Please update the status for PF participant aware on
https://wiki.iotivity.org/pf13_engineering_version_tag .



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] New project for approval

[최우제 (Uze Choi)]

I think Betty intended to propose the new iotivity project (not OCF
project), as like IoTivity alljoyn-bridge and upnp-bridge project.
However, the attachment includes the associated OCF project information
which is not required in IoTivity.
Just filtering out the OCF specific context will resolve the Mat and Thiago
concerns, I think.
If this is new IoTivity project proposal, ISG should decide to approve.

BR, UZe Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Friday, July 07, 2017 10:24 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] New project for approval

On quinta-feira, 6 de julho de 2017 12:34:08 PDT Mats Wichmann wrote:
> 2. in terms of starting a "new project", you should read these two 
> pages and prepare internally to follow these procedures and respond to 
> any questions that can arise:
> 
> https://www.iotivity.org/get-involved/feature-development
> https://www.iotivity.org/get-involved/contribution-guidelines
> 
> 
> "Starting a new project" in effect means the interested parties making 
> the proposal are prepared to contribute the code, work on the 
> integration, maintain the code (and hopefully actually provide a 
> maintainer to the project), and to convince the project infrastructure 
> that when it comes time to allocate QA resources that there is value 
> in including this new feature in the test plan - of course being a 
> feature in an approved OCF specification feature clearly helps with this
argument.

Thank you Mats ,I meant to send something along those lines.

Betty, thank you for the interest. Since this follows the vision of the
IoTivity project, the ISG does not need to approve this; only the
maintainers do. So this needs to be a technical discussion: what the
features you want to implement are and how you and your engineers would
like to do so.

Please look at the feature development page (link above) and decide how to
proceed. You may skip some phases or overlap them depending on how small
the feature is (e.g., if it's just a plugin to the bridge host).

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] Noti-: IoTivity Branch strategy after 1.3.0 release.

[최우제 (Uze Choi)]

Please merge each commit on 1.3-rel branch by maintainer decision of each
project. (D, security, service, ?.)



Originally, any commit on 1.3-rel should be reviewed by release function
lead.

However, we have a lots of time for next patch release (1.3.1), and this is
not release cycle either.

Let?s apply release function lead review rule on release time (with QA
cycle) only.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Friday, June 02, 2017 12:30 PM
To: iotivity-dev at lists.iotivity.org
Subject: IoTivity Branch strategy after 1.3.0 release.



Hi All,



There are several commits after 1.3.0 release.

Because we still have to go further for IoTivity to be OCF1.0 CTT
conformable, it will be better to continue to keep the 1.3-rel branch.

Please, commit to 1.3-rel branch for OCF1.0 CTT conformance, then merge
into master will be done regularly.

IoTivity next version with 1.3.X tag will be created on the 1.3-rel branch.



Phil, Could you make a script to execute it and enabling it into server?



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Several Architectural Questions on Iotivity

[최우제 (Uze Choi)]

RD works similar as DNS server.

Each power constraint Server register its own discovery address into server.

Then, any client can browse these address by look up RD.

RD just provide the resource address information related with discovery only.

If you think about the data hosting or data relay beyond discovery information, 
these are not served by RD.



Heterogeneous routing functionality has been tested thru BLE and WiFI on 
Android device and Ubuntu As far as I know.



BR, Uze Choi

From: khaled at ieee.org [mailto:kha...@ieee.org] On Behalf Of Khaled Elsayed
Sent: Wednesday, June 07, 2017 10:52 PM
To: ??? (Uze Choi)
Cc: iotivity-dev
Subject: Re: [dev] Several Architectural Questions on Iotivity



Hi Uze,



Thanks very much for the clarifications. I will have a look at the mini plugin 
bridge module, Glad to know the resource container is deprecated, seems overly 
complex and a simpler approach was needed. 



So, just to make sure I get the correct understanding, it is possible for the 
RD to cache values of the resources of other nodes and serve requests for these 
resources locally. Pls confirm. 



Yes, I had a look at the routing through heterogeneous networks, has anyone 
really tested that it works?



Best regards,



Khaled







On Wed, Jun 7, 2017 at 10:49 AM, ??? (Uze Choi)  wrote:

Hi Khaled,



Let me update some iotivity implementation status from your initial questions.

(RD)

https://wiki.iotivity.org/resource_directory_-_programming_guide focus on the 
generic use case and inclined to local network scenario. 

 https://wiki.iotivity.org/resource-directory_rd looks have more focus on the 
cloud use case. But, they are same concept.

If you say resource value cache mechanism such as temperature and power status 
value, we call it resource hosting but for the discovery information we call it 
resource directory. Resource hosting is separate terminology beyond resource 
directory. Initially resource hosting module was implemented but now deprecated.



(BLE routing)

If you enable the routing feature, you can find the other network device thru 
BLE and WIFI.

Please see https://wiki.iotivity.org/routing_through_heterogeneous_transports.

However, BLE transport using GATT is not accepted as OCF transport. You can 
only connect thru gateway device implementation using mini plugin manager 
module and so on.



(Resource Container)

Use case of Resource container is exactly what you expected. However, This 
module was deprecated from this release 1.3.0.

Instead, mini plugin bridge module was newly introduced in this IoTivity 1.3.0 
release.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of VanCutsem, 
Geoffroy
Sent: Wednesday, June 07, 2017 7:05 AM
To: khaledieee at gmail.com
Cc: iotivity-dev


Subject: Re: [dev] Several Architectural Questions on Iotivity



Hi Khaled,



I?d need to dive deeper into the 6LowPAN (Arduino 101 + Zephyr + 
iotivity-constrained) stack to understand how it works but I don?t believe that 
that one does any resource hosting so any OIC/OCF client will really talk to 
the device. The Gateway in our case is simply the ?BLE endpoint? (not sure that 
terminology is appropriate) that the OCF server connects to using Bluetooth. It 
happens to be our home gateway in our set-up but it likely does not have to be. 
I?m also assuming that you could have many of these endpoints throughout your 
network as long as they?re all part of the same subnet. These ?BLE endpoint? 
would be connected over a network (e.g. Ethernet, WiFi, ?) to your Gateway. I 
say ?likely? and ?assuming? because I have not tested this and I really don?t 
know enough yet about IPv6 to understand how this all plays out.



For our sensors using BLE GATT, it?s a little different and yes, it?s really 
the small app running on the BLE endpoint that turns it into an OIC/OCF device. 
But similar to what I describe above, you could most likely have many of these 
around. In your diagram below, the BLE connections (GATT) would be established 
between your sensor and what I call here a BLE endpoint and all you?d need to 
have is a network connection (same subnet) between that endpoint and your 
gateway. That connection could be Ethernet or WiFi for example.



My understanding is also that things will be slightly different (for the 
better) when Bluetooth 5.0 (that introduces mesh) gets into the picture. But I 
think that?s still a few months away at least.



To all networking experts out there, please chime him if I?m talking rubbish at 
any point ;)



Geoffroy



From: khaled at ieee.org [mailto:kha...@ieee.org] On Behalf Of Khaled Elsayed
Sent: Tuesday, June 6, 2017 5:11 PM
To: VanCutsem, Geoffroy 
Cc: iotivity-dev 
Subject: Re: [dev] Several Architectural Questions on Iotivity



Thanks Geoffroy for the info. 



So, as far as I could understand from your replies and the initial reading of 
the readme file is that your BLE 

[dev] Several Architectural Questions on Iotivity

[최우제 (Uze Choi)]

Hi Khaled,



Let me update some iotivity implementation status from your initial questions.

(RD)

https://wiki.iotivity.org/resource_directory_-_programming_guide focus on the 
generic use case and inclined to local network scenario. 

 https://wiki.iotivity.org/resource-directory_rd looks have more focus on the 
cloud use case. But, they are same concept.

If you say resource value cache mechanism such as temperature and power status 
value, we call it resource hosting but for the discovery information we call it 
resource directory. Resource hosting is separate terminology beyond resource 
directory. Initially resource hosting module was implemented but now deprecated.



(BLE routing)

If you enable the routing feature, you can find the other network device thru 
BLE and WIFI.

Please see https://wiki.iotivity.org/routing_through_heterogeneous_transports.

However, BLE transport using GATT is not accepted as OCF transport. You can 
only connect thru gateway device implementation using mini plugin manager 
module and so on.



(Resource Container)

Use case of Resource container is exactly what you expected. However, This 
module was deprecated from this release 1.3.0.

Instead, mini plugin bridge module was newly introduced in this IoTivity 1.3.0 
release.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of VanCutsem, 
Geoffroy
Sent: Wednesday, June 07, 2017 7:05 AM
To: khaledieee at gmail.com
Cc: iotivity-dev
Subject: Re: [dev] Several Architectural Questions on Iotivity



Hi Khaled,



I?d need to dive deeper into the 6LowPAN (Arduino 101 + Zephyr + 
iotivity-constrained) stack to understand how it works but I don?t believe that 
that one does any resource hosting so any OIC/OCF client will really talk to 
the device. The Gateway in our case is simply the ?BLE endpoint? (not sure that 
terminology is appropriate) that the OCF server connects to using Bluetooth. It 
happens to be our home gateway in our set-up but it likely does not have to be. 
I?m also assuming that you could have many of these endpoints throughout your 
network as long as they?re all part of the same subnet. These ?BLE endpoint? 
would be connected over a network (e.g. Ethernet, WiFi, ?) to your Gateway. I 
say ?likely? and ?assuming? because I have not tested this and I really don?t 
know enough yet about IPv6 to understand how this all plays out.



For our sensors using BLE GATT, it?s a little different and yes, it?s really 
the small app running on the BLE endpoint that turns it into an OIC/OCF device. 
But similar to what I describe above, you could most likely have many of these 
around. In your diagram below, the BLE connections (GATT) would be established 
between your sensor and what I call here a BLE endpoint and all you?d need to 
have is a network connection (same subnet) between that endpoint and your 
gateway. That connection could be Ethernet or WiFi for example.



My understanding is also that things will be slightly different (for the 
better) when Bluetooth 5.0 (that introduces mesh) gets into the picture. But I 
think that?s still a few months away at least.



To all networking experts out there, please chime him if I?m talking rubbish at 
any point ;)



Geoffroy



From: khaled at ieee.org [mailto:kha...@ieee.org] On Behalf Of Khaled Elsayed
Sent: Tuesday, June 6, 2017 5:11 PM
To: VanCutsem, Geoffroy 
Cc: iotivity-dev 
Subject: Re: [dev] Several Architectural Questions on Iotivity



Thanks Geoffroy for the info. 



So, as far as I could understand from your replies and the initial reading of 
the readme file is that your BLE devices whether OCF/OIC (e.g. the sensor 
running zephyr with iotivity constrained) or GATT-based non-OIC, they are 
handled by the gateway device. The gateway will provide some "resource hosting" 
for the BLE devices to connect them with the rest of the system. All entities 
will talk with the gateway not to the BLE node itself even if BLE node is 
OCF/OIC. Is this correct?



I think this will make things a bit easier though not as flexible as in the 
case the gateway will route between the different transports. 



Also, the usage of simple node.js scripts instead of full-fledged resource 
container/bundle simplifies the handling of non-OIC devices. I will have a look 
at these. 



Best regards,



Khaled





On Tue, Jun 6, 2017 at 3:41 PM, VanCutsem, Geoffroy  wrote:

Hi Khaled,



You will find some input to some of your questions embedded below.



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Khaled Elsayed
Sent: Tuesday, June 6, 2017 9:59 AM
To: iotivity-dev 
Subject: [dev] Several Architectural Questions on Iotivity



??

Dear all, 



We are working on a research project called campie http://campie.cu.edu.eg/ and 
have chosen iotivity/OIC as our base connectivity and service discovery layer. 
I have several questions on iotivity 

[dev] note on sconscript cleanups

[최우제 (Uze Choi)]

Hi Phils,

>From the release view, I think current build script has some issues to
secure the overall quality.
Frequently we faced the error in the build script and it caused the build
failure from specific preprocessor options.
To lessen the release burden from the next time in case of patch release
such as 1.3.1 or 1.3.2, it needs to be applied into 1.3-rel I expect.

BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Philippe Coval
Sent: Saturday, June 03, 2017 10:17 AM
To: IoTivity Developer List
Subject: Re: [dev] note on sconscript cleanups

Thank Mats for your help on that, this is appreciated, I think master is
the good place to prepare next release, 1.4-rel or 2.0-rel ?

But I am a bit reluctant to change all in 1.3-rel, unless there is valid
reason to do that (regressions etc).
and it needs to be tracked off course.

Last advice, all build related changes are welcome to be committed
progressively (per module), then we can find out regression more easily
than we did on recent patches for windows (we had to revert big patches)

Regards

On 03/06/17 09:00, Mats Wichmann wrote:
> There's a bunch of stuff that could clean up the build scripts to be 
> more readable, more maintainable, and in some cases more correct (e.g 
> the situation where some of the extlibs scripts are called many times, 
> which is just plain not the way scons is supposed to work).
>
> Step one of that is converting them into a consistent style. I didn't 
> want to push any of this to master until 1.3 was released, since 
> changes often seem to touch the scons scripts as well, and that could 
> cause some headaches in keeping master and 1.3-rel synced - mergebacks 
> would not necessarily be trivial.
> s MAts
> So 1.3 is out and I've done some of these against master (using a 
> tool, but with manual inspection for sanity checking)... and now it 
> turns out
> 1.3 is going to stay open for quite a while yet. So not sure where 
> these will be able to go.
>
> So far, I've sent up seven patchsets for seven subdirectories of 
> iotivity, covering 54 of the build scripts. Pending are the resource 
> subdirectory (82 scripts) and the service subdirectory (61 scripts). 
> At this point I'm unsure who wants/needs to review them, or if doing 
> this at this time turns out to be a bad idea since 1.3 work remains
pending.
> I only assigned reviewers on one of them so far, and two have 
> inexplicably failed builds - jenkins apparently is still fragile since 
> there were no functional changes from any of the patchsets, so it 
> should be impossible to fail.
>
> If people want to review these, let me know and I'll add you.
> Repeating, this particular set of patches only reformats things, it 
> does not change anything except in a few cases the content of text 
> messages printed out if there's an issue.
> ___
> 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

[dev] IoTivity Branch strategy after 1.3.0 release.

[최우제 (Uze Choi)]

Hi All,



There are several commits after 1.3.0 release.

Because we still have to go further for IoTivity to be OCF1.0 CTT
conformable, it will be better to continue to keep the 1.3-rel branch.

Please, commit to 1.3-rel branch for OCF1.0 CTT conformance, then merge
into master will be done regularly.

IoTivity next version with 1.3.X tag will be created on the 1.3-rel branch.



Phil, Could you make a script to execute it and enabling it into server?



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [Status update 2 for RC2 tagging] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi All,



Still Security blocks are blocking issue for RC2 Tagging and QA start.

Please resolve them ASAP.



Existing Security issue. [Dongik.Lee/Sergiy]

https://jira.iotivity.org/browse/IOT-2194 [Sergiy] (SSL handshake)  Still issue.

   https://jira.iotivity.org/browse/IOT-2107 [Sergiy] 
https://jira.iotivity.org/browse/IOT-1876 [Sergiy] 

OCF1.0 Security [Nathan]

https://jira.iotivity.org/browse/IOT-2179 (IOT-2121 dependent)
https://jira.iotivity.org/browse/IOT-2023 reviewing?

 https://jira.iotivity.org/browse/IOT-1958 reviewing?
https://jira.iotivity.org/browse/IOT-1895 reviewing?
https://jira.iotivity.org/browse/IOT-1795 reviewing?
https://jira.iotivity.org/browse/IOT-1763 reviewing?



One more, Sri, new patches for introspection as below. should they merged for 
RC2 tag? If yes, please resolve them soon.

Introspection : newly made ones, should they be merged?

https://gerrit.iotivity.org/gerrit/#/c/19541/

https://gerrit.iotivity.org/gerrit/#/c/19647/ 



BR, Uze Choi

From: Malsbary, Todd [mailto:todd.malsb...@intel.com] 
Sent: Saturday, May 06, 2017 2:18 AM
To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Status update for RC2 tagging] RE: [session2-Meeting 
minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update 
request for some missing blocks



Hi Uze,



The fix for IOT-1941 has been merged,



-Todd 



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, May 2, 2017 12:52 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [Status update for RC2 tagging] RE: [session2-Meeting minute]: 
[Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



Hi There are pending issue for RC2 tag as of now.



Without resolving them, we cannot make the RC2 tag and QA start again.

If any issue resolved please notify to me.



Existing Security issue. 

https://jira.iotivity.org/browse/IOT-2121 (SSL handshake)  [Sergiy]   under the 
review from Dan patch

   https://jira.iotivity.org/browse/IOT-2107 [Chul Lee] pending
https://jira.iotivity.org/browse/IOT-1876 [surabh sharma] pending



OCF1.0 Security [Nathan]

https://jira.iotivity.org/browse/IOT-2179 (IOT-2121 dependent)
https://jira.iotivity.org/browse/IOT-2023 reviewing?

 https://jira.iotivity.org/browse/IOT-1958 reviewing?
https://jira.iotivity.org/browse/IOT-1895 reviewing?
https://jira.iotivity.org/browse/IOT-1795 reviewing?
https://jira.iotivity.org/browse/IOT-1763 reviewing?



Versioning

https://jira.iotivity.org/browse/IOT-2120 [Ziran] under the review by Ashok.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, April 28, 2017 3:41 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [Status for RC2 tagging] RE: [session2-Meeting minute]: [Triage 
CC schedule] [For 1.3 release RC2 ] list sharing and update request for some 
missing blocks



Hi All.



Let me share the status as follows which are currently pending issues for RC2 
tagging.

I wish to make a tag early next week with these resolved.



Security Onboarding issue. (SSL handshake)

  
https://jira.iotivity.org/browse/IOT-2121   [Sergiy & Randeep]

Versioning

  https://jira.iotivity.org/browse/IOT-2120 [Ziran]

OCF1.0 Security [Nathan]

   https://jira.iotivity.org/browse/IOT-2107 
https://jira.iotivity.org/browse/IOT-2023 

 https://jira.iotivity.org/browse/IOT-1958
https://jira.iotivity.org/browse/IOT-1957

https://jira.iotivity.org/browse/IOT-1895
https://jira.iotivity.org/browse/IOT-1795
https://jira.iotivity.org/browse/IOT-1763

MPM

  https://jira.iotivity.org/browse/IOT-1941 [Todd]



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, April 27, 2017 10:04 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Session2 Participants: Dave, Nathan, Mitch, Todd, Rick Uze.Choi, anyone else?



Agenda: IoTivity 1.3 Feature progress for security/MPM, AJbridge, UPnP

security onboarding issue(blocking)



Existing feature Security provisioning break

Even https://gerrit.iotivity.org/gerrit/#/c/19237/ is merged, still issue on 
linux machine (Windows env, it looks work)

When This patch is Tested with CTT, still we have issue. So CTT will be fixed 
to change a property related with Read-only.

1.3.0 Security features

   Once provisioning is fixed in time, all features could be merged by 
this week. [Nathan]

MPM, AJ bridge

   All pending patch to be merged.

   Open issues need to be evaluated whether they affect CTT pass or 
not. (e,g: optional features)

 

[dev] [Status update for RC2 tagging] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi There are pending issue for RC2 tag as of now.



Without resolving them, we cannot make the RC2 tag and QA start again.

If any issue resolved please notify to me.



Existing Security issue. 

https://jira.iotivity.org/browse/IOT-2121 (SSL handshake)  [Sergiy]   under the 
review from Dan patch

   https://jira.iotivity.org/browse/IOT-2107 [Chul Lee] pending
https://jira.iotivity.org/browse/IOT-1876 [surabh sharma] pending



OCF1.0 Security [Nathan]

https://jira.iotivity.org/browse/IOT-2179 (IOT-2121 dependent)
https://jira.iotivity.org/browse/IOT-2023 reviewing?

 https://jira.iotivity.org/browse/IOT-1958 reviewing?
https://jira.iotivity.org/browse/IOT-1895 reviewing?
https://jira.iotivity.org/browse/IOT-1795 reviewing?
https://jira.iotivity.org/browse/IOT-1763 reviewing?



Versioning

https://jira.iotivity.org/browse/IOT-2120 [Ziran] under the review by Ashok.

Discovery EP

https://jira.iotivity.org/browse/IOT-2155 [Koushik]   fixing

MPM

  https://jira.iotivity.org/browse/IOT-1941 [Todd] fixing



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, April 28, 2017 3:41 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [Status for RC2 tagging] RE: [session2-Meeting minute]: [Triage 
CC schedule] [For 1.3 release RC2 ] list sharing and update request for some 
missing blocks



Hi All.



Let me share the status as follows which are currently pending issues for RC2 
tagging.

I wish to make a tag early next week with these resolved.



Security Onboarding issue. (SSL handshake)

  
https://jira.iotivity.org/browse/IOT-2121   [Sergiy & Randeep]

Versioning

  https://jira.iotivity.org/browse/IOT-2120 [Ziran]

OCF1.0 Security [Nathan]

   https://jira.iotivity.org/browse/IOT-2107 
https://jira.iotivity.org/browse/IOT-2023 

 https://jira.iotivity.org/browse/IOT-1958
https://jira.iotivity.org/browse/IOT-1957

https://jira.iotivity.org/browse/IOT-1895
https://jira.iotivity.org/browse/IOT-1795
https://jira.iotivity.org/browse/IOT-1763

MPM

  https://jira.iotivity.org/browse/IOT-1941 [Todd]



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, April 27, 2017 10:04 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Session2 Participants: Dave, Nathan, Mitch, Todd, Rick Uze.Choi, anyone else?



Agenda: IoTivity 1.3 Feature progress for security/MPM, AJbridge, UPnP

security onboarding issue(blocking)



Existing feature Security provisioning break

Even https://gerrit.iotivity.org/gerrit/#/c/19237/ is merged, still issue on 
linux machine (Windows env, it looks work)

When This patch is Tested with CTT, still we have issue. So CTT will be fixed 
to change a property related with Read-only.

1.3.0 Security features

   Once provisioning is fixed in time, all features could be merged by 
this week. [Nathan]

MPM, AJ bridge

   All pending patch to be merged.

   Open issues need to be evaluated whether they affect CTT pass or 
not. (e,g: optional features)

 : We can triage out what to be fixed next.

?  Todd reply which open jira ticket should be done for 1.3.0 release

UPnP bridge

   Sound like pending issue. ? Rick, please share the context.

General

1.3.0 release Target is pass the CTT (even though this is intermediate 
version), Lets focus on it.

Let?s mark P1 in Jira with 1.3.0 fix version, for CTT fail issue or blocking 
issues. (As Nathan did it on 7 Jira tickets)

   Todd, Nathan, Rick to notify RC2 which contain all code patch for 
1.3.0 feature.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 7:54 PM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [session1-Meeting minute]: [Triage CC schedule] [dev] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Hi All, Let me share the meeting minute for session1



Session1 Participants: Ziran.Sun, Sergiy, Antu, Phil, Christian, Dongik, and 
Uze.Choi, Randeep



Agenda: IoTivity 1.3 Feature progress & CTT/Test Blocking issue

   The remaining jira issues could not discussed how to resolve so many 
items.



[Discovery Endpoint]

There are two issue in Discovery Endpoint. But these two issues are under the 
certain environment, no blocking issue for whole testing.

In case of multiple interfaces  [Jira will be there soon from Antu]

In case of TCP connection. Missing tcp port info..  [Jira will be there soon 
from Antu]



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 

Accept version API from 

[dev] IoTivity reviewer setting guide

[최우제 (Uze Choi)]

Hi All,



Whenever we commit the code please include the maintainer at least.

Some security code just put the reviewer as sub-maintainer as final
approver but, commit should include the maintainer I think.

This rule belongs to platform extension and discovery-connectivity also.



BR, Uze Choi



-- next part --
HTML ?? ??...
URL: 

[dev] [Status for RC2 tagging] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi All.



Let me share the status as follows which are currently pending issues for RC2 
tagging.

I wish to make a tag early next week with these resolved.



Security Onboarding issue. (SSL handshake)

  
https://jira.iotivity.org/browse/IOT-2121   [Sergiy & Randeep]

Versioning

  https://jira.iotivity.org/browse/IOT-2120 [Ziran]

OCF1.0 Security [Nathan]

   https://jira.iotivity.org/browse/IOT-2107 
https://jira.iotivity.org/browse/IOT-2023 

 https://jira.iotivity.org/browse/IOT-1958
https://jira.iotivity.org/browse/IOT-1957

https://jira.iotivity.org/browse/IOT-1895
https://jira.iotivity.org/browse/IOT-1795
https://jira.iotivity.org/browse/IOT-1763

MPM

  https://jira.iotivity.org/browse/IOT-1941 [Todd]



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, April 27, 2017 10:04 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Session2 Participants: Dave, Nathan, Mitch, Todd, Rick Uze.Choi, anyone else?



Agenda: IoTivity 1.3 Feature progress for security/MPM, AJbridge, UPnP

security onboarding issue(blocking)



Existing feature Security provisioning break

Even https://gerrit.iotivity.org/gerrit/#/c/19237/ is merged, still issue on 
linux machine (Windows env, it looks work)

When This patch is Tested with CTT, still we have issue. So CTT will be fixed 
to change a property related with Read-only.

1.3.0 Security features

   Once provisioning is fixed in time, all features could be merged by 
this week. [Nathan]

MPM, AJ bridge

   All pending patch to be merged.

   Open issues need to be evaluated whether they affect CTT pass or 
not. (e,g: optional features)

 : We can triage out what to be fixed next.

?  Todd reply which open jira ticket should be done for 1.3.0 release

UPnP bridge

   Sound like pending issue. ? Rick, please share the context.

General

1.3.0 release Target is pass the CTT (even though this is intermediate 
version), Lets focus on it.

Let?s mark P1 in Jira with 1.3.0 fix version, for CTT fail issue or blocking 
issues. (As Nathan did it on 7 Jira tickets)

   Todd, Nathan, Rick to notify RC2 which contain all code patch for 
1.3.0 feature.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 7:54 PM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [session1-Meeting minute]: [Triage CC schedule] [dev] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Hi All, Let me share the meeting minute for session1



Session1 Participants: Ziran.Sun, Sergiy, Antu, Phil, Christian, Dongik, and 
Uze.Choi, Randeep



Agenda: IoTivity 1.3 Feature progress & CTT/Test Blocking issue

   The remaining jira issues could not discussed how to resolve so many 
items.



[Discovery Endpoint]

There are two issue in Discovery Endpoint. But these two issues are under the 
certain environment, no blocking issue for whole testing.

In case of multiple interfaces  [Jira will be there soon from Antu]

In case of TCP connection. Missing tcp port info..  [Jira will be there soon 
from Antu]



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 

Accept version API from E.H for application developer ? [Fundamental issue 
still there Ziran will report back]



[Security - onboarding Break]

Randeep, Antu and Sergiy together resolved by today. [Randeep organize]





BR, Uze Choi



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 11:04 AM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [WebEx Info]: [Triage CC schedule] [dev] [For 1.3 release RC2 ] list 
sharing and update request for some missing blocks



Web Ex detail is addressed for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 ? CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



IoTivity Release Triage ? 1 session

-   For (Asia, Europe)

-   Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian, 
bg.chun, Dongik, and maintainers

-   WebEx info

Wednesday, April 26, 2017 | 2:00 am Pacific Daylight Time (GMT-07:00) 

Host: OCF Staff Edit   | Cancel meeting 
  | Add to my calendar   

Meeting number: 926 165 930 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mf6059dd35477f29e25a21f9eb0f7f7d7
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 

[dev] [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Session2 Participants: Dave, Nathan, Mitch, Todd, Rick Uze.Choi, anyone else?



Agenda: IoTivity 1.3 Feature progress for security/MPM, AJbridge, UPnP

security onboarding issue(blocking)



Existing feature Security provisioning break

Even https://gerrit.iotivity.org/gerrit/#/c/19237/ is merged, still issue on 
linux machine (Windows env, it looks work)

When This patch is Tested with CTT, still we have issue. So CTT will be fixed 
to change a property related with Read-only.

1.3.0 Security features

   Once provisioning is fixed in time, all features could be merged by 
this week. [Nathan]

MPM, AJ bridge

   All pending patch to be merged.

   Open issues need to be evaluated whether they affect CTT pass or 
not. (e,g: optional features)

 : We can triage out what to be fixed next.

?  Todd reply which open jira ticket should be done for 1.3.0 release

UPnP bridge

   Sound like pending issue. ? Rick, please share the context.

General

1.3.0 release Target is pass the CTT (even though this is intermediate 
version), Lets focus on it.

Let?s mark P1 in Jira with 1.3.0 fix version, for CTT fail issue or blocking 
issues. (As Nathan did it on 7 Jira tickets)

   Todd, Nathan, Rick to notify RC2 which contain all code patch for 
1.3.0 feature.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 7:54 PM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [session1-Meeting minute]: [Triage CC schedule] [dev] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Hi All, Let me share the meeting minute for session1



Session1 Participants: Ziran.Sun, Sergiy, Antu, Phil, Christian, Dongik, and 
Uze.Choi, Randeep



Agenda: IoTivity 1.3 Feature progress & CTT/Test Blocking issue

   The remaining jira issues could not discussed how to resolve so many 
items.



[Discovery Endpoint]

There are two issue in Discovery Endpoint. But these two issues are under the 
certain environment, no blocking issue for whole testing.

In case of multiple interfaces  [Jira will be there soon from Antu]

In case of TCP connection. Missing tcp port info..  [Jira will be there soon 
from Antu]



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 

Accept version API from E.H for application developer ? [Fundamental issue 
still there Ziran will report back]



[Security - onboarding Break]

Randeep, Antu and Sergiy together resolved by today. [Randeep organize]





BR, Uze Choi



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 11:04 AM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [WebEx Info]: [Triage CC schedule] [dev] [For 1.3 release RC2 ] list 
sharing and update request for some missing blocks



Web Ex detail is addressed for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 ? CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



IoTivity Release Triage ? 1 session

-   For (Asia, Europe)

-   Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian, 
bg.chun, Dongik, and maintainers

-   WebEx info

Wednesday, April 26, 2017 | 2:00 am Pacific Daylight Time (GMT-07:00) 

Host: OCF Staff Edit   | Cancel meeting 
  | Add to my calendar   

Meeting number: 926 165 930 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mf6059dd35477f29e25a21f9eb0f7f7d7
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 926 165 930 



IoTivity Release Triage ? 2 session 

-   For (US)

-   Very required: Todd, Nathan, Rick and maintainers

-   WebEx info

Meeting number: 921 574 122 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mefcf78b31dccb6d7b3592b833c9ebce5
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 921 574 122



BR, Uze Choi

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Tuesday, April 25, 2017 12:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



Hi Uze,



How about having 2 calls (1 for Pacific time zone & 1 for European time zone) 
in this week may be Thursday and Friday to finalize the status of this release 
as of now? Emails may not get rapid response sometime.



Regards

Dwarka

[dev] [session1-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Ziran will describe it detail by registering jira.



From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Wednesday, April 26, 2017 8:58 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [session1-Meeting minute]: [Triage CC schedule] [For 1.3 
release RC2 ] list sharing and update request for some missing blocks



Thanks for sharing minutes Uze.



I am looking forward to know more specific details regarding below issue ?



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 



Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF)



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Wednesday, April 26, 2017 7:54 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [session1-Meeting minute]: [Triage CC schedule] [For 1.3 release 
RC2 ] list sharing and update request for some missing blocks



Hi All, Let me share the meeting minute for session1



Session1 Participants: Ziran.Sun, Sergiy, Antu, Phil, Christian, Dongik, and 
Uze.Choi, Randeep



Agenda: IoTivity 1.3 Feature progress & CTT/Test Blocking issue

   The remaining jira issues could not discussed how to resolve so many 
items.



[Discovery Endpoint]

There are two issue in Discovery Endpoint. But these two issues are under the 
certain environment, no blocking issue for whole testing.

In case of multiple interfaces  [Jira will be there soon from Antu]

In case of TCP connection. Missing tcp port info..  [Jira will be there soon 
from Antu]



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 

Accept version API from E.H for application developer ? [Fundamental issue 
still there Ziran will report back]



[Security - onboarding Break]

Randeep, Antu and Sergiy together resolved by today. [Randeep organize]





BR, Uze Choi



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 11:04 AM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [WebEx Info]: [Triage CC schedule] [dev] [For 1.3 release RC2 ] list 
sharing and update request for some missing blocks



Web Ex detail is addressed for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 ? CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



IoTivity Release Triage ? 1 session

-   For (Asia, Europe)

-   Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian, 
bg.chun, Dongik, and maintainers

-   WebEx info

Wednesday, April 26, 2017 | 2:00 am Pacific Daylight Time (GMT-07:00) 

Host: OCF Staff Edit   | Cancel meeting 
  | Add to my calendar   

Meeting number: 926 165 930 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mf6059dd35477f29e25a21f9eb0f7f7d7
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 926 165 930 



IoTivity Release Triage ? 2 session 

-   For (US)

-   Very required: Todd, Nathan, Rick and maintainers

-   WebEx info

Meeting number: 921 574 122 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mefcf78b31dccb6d7b3592b833c9ebce5
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 921 574 122



BR, Uze Choi

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Tuesday, April 25, 2017 12:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



Hi Uze,



How about having 2 calls (1 for Pacific time zone & 1 for European time zone) 
in this week may be Thursday and Friday to finalize the status of this release 
as of now? Emails may not get rapid response sometime.



Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF)



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, April 25, 2017 11:49 AM
To: iotivity-dev 

[dev] [session1-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi All, Let me share the meeting minute for session1



Session1 Participants: Ziran.Sun, Sergiy, Antu, Phil, Christian, Dongik, and 
Uze.Choi, Randeep



Agenda: IoTivity 1.3 Feature progress & CTT/Test Blocking issue

   The remaining jira issues could not discussed how to resolve so many 
items.

[Discovery Endpoint]

There are two issue in Discovery Endpoint. But these two issues are under the 
certain environment, no blocking issue for whole testing.

In case of multiple interfaces  [Jira will be there soon from Antu]

In case of TCP connection. Missing tcp port info..  [Jira will be there soon 
from Antu]



[Versioning]

Scenario with old client to new server: looks like spec issue. [Jira will be 
there soon from Antu, Dwarka should help it from spec view] ? 

Accept version API from E.H for application developer ? [Fundamental issue 
still there Ziran will report back]



[Security - onboarding Break]

Randeep, Antu and Sergiy together resolved by today. [Randeep organize]





BR, Uze Choi



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, April 26, 2017 11:04 AM
To: 'iotivity-dev at lists.iotivity.org'
Subject: [WebEx Info]: [Triage CC schedule] [dev] [For 1.3 release RC2 ] list 
sharing and update request for some missing blocks



Web Ex detail is addressed for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 ? CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



IoTivity Release Triage ? 1 session

-   For (Asia, Europe)

-   Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian, 
bg.chun, Dongik, and maintainers

-   WebEx info

Wednesday, April 26, 2017 | 2:00 am Pacific Daylight Time (GMT-07:00) 

Host: OCF Staff Edit   | Cancel meeting 
  | Add to my calendar   

Meeting number: 926 165 930 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mf6059dd35477f29e25a21f9eb0f7f7d7
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 926 165 930 



IoTivity Release Triage ? 2 session 

-   For (US)

-   Very required: Todd, Nathan, Rick and maintainers

-   WebEx info

Meeting number: 921 574 122 

Meeting password: 1234 

Meeting link: 
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mefcf78b31dccb6d7b3592b833c9ebce5
 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions 
 

Access code: 921 574 122



BR, Uze Choi

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Tuesday, April 25, 2017 12:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



Hi Uze,



How about having 2 calls (1 for Pacific time zone & 1 for European time zone) 
in this week may be Thursday and Friday to finalize the status of this release 
as of now? Emails may not get rapid response sometime.



Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF)



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, April 25, 2017 11:49 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



Hi Todd,



Please update the MPM and AllSeen bridge status.

Everything is merged? Otherwise, what are left and when do you expect to be 
done.

I need the timeline for prepare the testing, without it, we cannot make the 
plan to move forward.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Tuesday, April 25, 2017 1:37 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks



My change to address feedback on Introspection turned out to be complicated.  I 
expect to submit another patch in a couple of days.



Thanks,

Sri



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, April 24, 2017 2:35 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [For 1.3 release RC2 ] list sharing and update request for some 
missing blocks



Hi Sri, Ziran, Todd, Nathan, and All,



Please update the progress for your feature merging? Still some pending issue 
to bug fix.

[dev] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Please work on the 1.3-rel branch rather than master. Merging to mater will be 
done regularly.

Final perfect code could be in the master, but testable code should be merged 
in 1.3-rel branch I think.
After this week passed, no more time to test the iotivity code for release I 
think, even though we have another time to test but this will not be for newly 
introduced code but regression test.
In shortly, I wish you finalize your module in 1.3-rel even with some 
limitation/incompleteness. Of course, This will not be acceptable to master.

BR, Uze Choi
-Original Message-
From: Malsbary, Todd [mailto:todd.malsb...@intel.com] 
Sent: Wednesday, April 26, 2017 1:08 AM
To: iotivity-dev at lists.iotivity.org; uzchoi at samsung.com
Subject: Re: [dev] [For 1.3 release RC2 ] list sharing and update request for 
some missing blocks

Hi Uze,

Sorry for the delay.  Here's the current status:

MPM
Would like to cherry pick these to 1.3-rel.  A couple have build issues so not 
ready yet.
- https://gerrit.iotivity.org/gerrit/#/c/19165/
- https://gerrit.iotivity.org/gerrit/#/c/19167/
- https://gerrit.iotivity.org/gerrit/#/c/19169/

Pending, but needs fixes before getting merged
- https://gerrit.iotivity.org/gerrit/#/c/17621/

Open issues
- https://jira.iotivity.org/browse/IOT-2087
- https://jira.iotivity.org/browse/IOT-2094
- https://jira.iotivity.org/browse/IOT-2095

iotivity-alljoyn-bridge
- 1.3-rel branch exists, need to verify with iotivity.git + patches suggested 
by Antu
- Open tasks
  - Review introspection implementation and track upcoming changes
  - Implement oic.r.alljoynobject collection resource
  - Integrate with MPM

Dependent open issues in iotivity.git
- https://jira.iotivity.org/browse/IOT-1935
- https://jira.iotivity.org/browse/IOT-1940
- https://jira.iotivity.org/browse/IOT-1941

General spec alignment issues
- https://jira.iotivity.org/browse/IOT-204
8
- https://jira.iotivity.org/browse/IOT-2056

-Todd

On Tue, 2017-04-25 at 11:48 +0900, ??? (Uze Choi) wrote:
> Hi Todd,
>  
> Please update the MPM and AllSeen bridge status.
> Everything is merged? Otherwise, what are left and when do you expect 
> to be done.
> I need the timeline for prepare the testing, without it, we cannot 
> make the plan to move forward.
>  
> BR, Uze Choi
> From: Srikrishna Gurugubelli [mailto:srikguru at microsoft.com]
> Sent: Tuesday, April 25, 2017 1:37 AM
> To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
> Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update 
> request for some missing blocks
>  
> My change to address feedback on Introspection turned out to be 
> complicated.  I expect to submit another patch in a couple of days.
>  
> Thanks,
> Sri
>  
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo 
> unces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
> Sent: Monday, April 24, 2017 2:35 AM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] [For 1.3 release RC2 ] list sharing and update request 
> for some missing blocks
>  
> Hi Sri, Ziran, Todd, Nathan, and All,
>  
> Please update the progress for your feature merging? Still some 
> pending issue to bug fix.
> Originally, this is the planned time to make the RC2 for QA 2 cycle 
> start, but we are not ready to do this.
> At least all feature should be merged in this stage, I believe. We are 
> behind the schedule.
> If the issue are not cleared by this week, Let me cut out the feature 
> from 1.3.0 release scope.
>  
> BR, Uze Choi
> From: ??? (Uze Choi) [mailto:uzchoi at samsung.com]
> Sent: Monday, April 17, 2017 8:33 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: [for 1.3 release] list sharing and update request for some 
> missing blocks
>  
> Hi All, this is update which I know
>  
> Introspection, Versioning, Endpoint are having pending patches and 
> open issues as of now. (Sri., Ziran, bg.chun please update them) 
> Security patches are expected to be merged by this week (Nathan
> commented)
> MPM and AllJoyn Bridge still do not know the status. (Todd, please 
> update it) CoAP Native Cloud project. (JK, please share the progress) 
> From the CTT testing, discovery logic looks broken, this is test 
> blocker and should be cleared ASAP . (Ziran/Habib, please check it) 
> Provisioning manager is also broken due to unidentified patch.
> (Sergiy is fixing it now)
> From Testing case, Antu, If you have any update please update table 
> context.
> Please care programming document on wiki also.
>  
> Feature   Overall Initial codeUpdate fix  T
> C ready   Test Executor   Contributor Documentation
> Introspection 90% merged  IOT-1965 in
> reviewJson2cbor updateDoneIoTivity QA Srikrish
> naNo API
> Versioning80% merged  Endpoint PM
> issue.payload separation  In progress IoTivity QA 
> Ziran No API
> Endpoint  100%merged  Routing issue   
> Done  IoTivity QA bg.chun No API
> Security update  

[dev] [WebEx Info]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Web Ex detail is addressed for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 - CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



IoTivity Release Triage - 1 session

-   For (Asia, Europe)

-   Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian,
bg.chun, Dongik, and maintainers

-   WebEx info

Wednesday, April 26, 2017 | 2:00 am Pacific Daylight Time (GMT-07:00) 

Host: OCF Staff Edit   | Cancel meeting
  | Add to my calendar   

Meeting number: 926 165 930 

Meeting password: 1234 

Meeting link:
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mf6059dd35477
f29e25a21f9eb0f7f7d7 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions
 

Access code: 926 165 930 



IoTivity Release Triage - 2 session 

-   For (US)

-   Very required: Todd, Nathan, Rick and maintainers

-   WebEx info

Meeting number: 921 574 122 

Meeting password: 1234 

Meeting link:
https://openconnectivity.webex.com/openconnectivity/j.php?MTID=mefcf78b31dcc
b6d7b3592b833c9ebce5 

Audio connection: 

+1-415-655-0002 US Toll

+1-855-797-9485 US Toll free

Global call-in numbers  

Show toll-free dialing restrictions
 

Access code: 921 574 122



BR, Uze Choi

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Tuesday, April 25, 2017 12:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



Hi Uze,



How about having 2 calls (1 for Pacific time zone & 1 for European time
zone) in this week may be Thursday and Friday to finalize the status of
this release as of now? Emails may not get rapid response sometime.



Regards

Dwarka


--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF)



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, April 25, 2017 11:49 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



Hi Todd,



Please update the MPM and AllSeen bridge status.

Everything is merged? Otherwise, what are left and when do you expect to be
done.

I need the timeline for prepare the testing, without it, we cannot make the
plan to move forward.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Tuesday, April 25, 2017 1:37 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



My change to address feedback on Introspection turned out to be
complicated.  I expect to submit another patch in a couple of days.



Thanks,

Sri



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, April 24, 2017 2:35 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [For 1.3 release RC2 ] list sharing and update request for
some missing blocks



Hi Sri, Ziran, Todd, Nathan, and All,



Please update the progress for your feature merging? Still some pending
issue to bug fix.

Originally, this is the planned time to make the RC2 for QA 2 cycle start,
but we are not ready to do this.

At least all feature should be merged in this stage, I believe. We are
behind the schedule.

If the issue are not cleared by this week, Let me cut out the feature from
1.3.0 release scope.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 17, 2017 8:33 PM
To: iotivity-dev at lists.iotivity.org
Subject: [for 1.3 release] list sharing and update request for some missing
blocks



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

[dev] [isg] commenst on reorg proposals

[최우제 (Uze Choi)]

Thank you Christian for your comments.

Some questions is for Thiago and others for me. Regardless of who should 
answer, let me talk my opinion.



We currently may have about a total of 15 active developers/maintainers in 
IoTivity (at least seen on this list).

Spreading these out on all the roles as defined in the proposal on project 
leaders, maintainers and 

technical leaders and so on seems to introduce quite an overhead.

?  There could be Overhead but currently there is no connection or 
communication channel or decision or management path.

This hierarchy may encourage the responsibility for each position, I expect.



subcommittees will have a 

?committee leader?/chair - so the project governance is done by 13 people (as 
seen on slide 4)?

?  Just categorization as like project, I imagined, But further detail is 
required I admit.



Also - the first three subcommittee blocks make immediate sense, as these 
define building blocks/tasks for any software development,

but what is meant by ?Smart Home? and ?Industrial?. These two do not seem to 
really fit here? 

?  I think this people can advocate or defense some architectural change or API 
from its biz perspective.

A kind of requirement review channel I can see. Furthermore, they can bring the 
biz requirement from stack to sdk views.



BR, Uze Choi

From: isg-bounces at lists.iotivity.org [mailto:isg-boun...@lists.iotivity.org] 
On Behalf Of Christian Gran
Sent: Tuesday, April 25, 2017 6:07 PM
To: iotivity-dev at lists.iotivity.org; isg at lists.iotivity.org
Subject: [isg] commenst on reorg proposals



Hi, 



in my opinion Uze/Samsung captured the current problem very well as

*   current IoTivity development is not well aligned with OCF 

*   OCF requires an easy to use solution with documentation
*   OCF requires product quality code for released versions and proof of 
concept code for draft specifications

*   not enough developers participating in IoTivity (we even have not one 
maintainer per component in  Jira!!!)



Thiago - could you please explain, why you think that moving to a more detailed 
structure as seen in your proposal would help with any of these points?

We currently may have about a total of 15 active developers/maintainers in 
IoTivity (at least seen on this list).

Spreading these out on all the roles as defined in the proposal on project 
leaders, maintainers and 

technical leaders and so on seems to introduce quite an overhead.



This said, I lean much more to the proposal from Samsung. The four blocks 
mentioned as subcommittees look good,

and these should be represented in OCF as well. We need the tight OCF relation 
with IoTivity, 

because OCF is mainly funding the project and OCF is the reason why IoTivity 
code is/will be used in products.

However I do not understand the differentiation between projects and 
subcommittees on slide 4.

Will the projects each have a project leader/maintainer (as of today) - and 
each of the subcommittees will have a 

?committee leader?/chair - so the project governance is done by 13 people (as 
seen on slide 4)?



Also - the first three subcommittee blocks make immediate sense, as these 
define building blocks/tasks for any software development,

but what is meant by ?Smart Home? and ?Industrial?. These two do not seem to 
really fit here? 



thanks

  Christian







-- next part --
HTML ?? ??...
URL: 

[dev] [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

I see. Good proposal, 



Let me create the two calls for ?Release Triage? for feature acceptance.

Taget date : 1 - 4/26 morning, 11:00 - CET (Central European Time Zone)

2 - 4/26 afternoon, 17:00 - PST



1 session (Asia, Europe)

Very required: Ziran.Sun, Sergiy, Antu, Jeeheok, Phil, Christian, bg.chun,
Dongik, and maintainers



2 session (US)

Very required: Todd, Nathan, Rick and maintainers



Let me send the webex connection info tomorrow.



BR, Uze Choi

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Tuesday, April 25, 2017 12:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



Hi Uze,



How about having 2 calls (1 for Pacific time zone & 1 for European time
zone) in this week may be Thursday and Friday to finalize the status of
this release as of now? Emails may not get rapid response sometime.



Regards

Dwarka


--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF)



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, April 25, 2017 11:49 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



Hi Todd,



Please update the MPM and AllSeen bridge status.

Everything is merged? Otherwise, what are left and when do you expect to be
done.

I need the timeline for prepare the testing, without it, we cannot make the
plan to move forward.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Tuesday, April 25, 2017 1:37 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



My change to address feedback on Introspection turned out to be
complicated.  I expect to submit another patch in a couple of days.



Thanks,

Sri



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, April 24, 2017 2:35 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [For 1.3 release RC2 ] list sharing and update request for
some missing blocks



Hi Sri, Ziran, Todd, Nathan, and All,



Please update the progress for your feature merging? Still some pending
issue to bug fix.

Originally, this is the planned time to make the RC2 for QA 2 cycle start,
but we are not ready to do this.

At least all feature should be merged in this stage, I believe. We are
behind the schedule.

If the issue are not cleared by this week, Let me cut out the feature from
1.3.0 release scope.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 17, 2017 8:33 PM
To: iotivity-dev at lists.iotivity.org
Subject: [for 1.3 release] list sharing and update request for some missing
blocks



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

100%

merged

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi Todd,



Please update the MPM and AllSeen bridge status.

Everything is merged? Otherwise, what are left and when do you expect to be
done.

I need the timeline for prepare the testing, without it, we cannot make the
plan to move forward.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Tuesday, April 25, 2017 1:37 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [For 1.3 release RC2 ] list sharing and update request
for some missing blocks



My change to address feedback on Introspection turned out to be
complicated.  I expect to submit another patch in a couple of days.



Thanks,

Sri



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, April 24, 2017 2:35 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [For 1.3 release RC2 ] list sharing and update request for
some missing blocks



Hi Sri, Ziran, Todd, Nathan, and All,



Please update the progress for your feature merging? Still some pending
issue to bug fix.

Originally, this is the planned time to make the RC2 for QA 2 cycle start,
but we are not ready to do this.

At least all feature should be merged in this stage, I believe. We are
behind the schedule.

If the issue are not cleared by this week, Let me cut out the feature from
1.3.0 release scope.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 17, 2017 8:33 PM
To: iotivity-dev at lists.iotivity.org
Subject: [for 1.3 release] list sharing and update request for some missing
blocks



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

100%

merged

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [For 1.3 release RC2 ] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi Sri, Ziran, Todd, Nathan, and All,



Please update the progress for your feature merging? Still some pending
issue to bug fix.

Originally, this is the planned time to make the RC2 for QA 2 cycle start,
but we are not ready to do this.

At least all feature should be merged in this stage, I believe. We are
behind the schedule.

If the issue are not cleared by this week, Let me cut out the feature from
1.3.0 release scope.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 17, 2017 8:33 PM
To: iotivity-dev at lists.iotivity.org
Subject: [for 1.3 release] list sharing and update request for some missing
blocks



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

100%

merged

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Fwd: [isg] Notes from ISG call 2017-04-10/11

[최우제 (Uze Choi)]

I expect Dwarka to answer regarding topic for kernel and so on.
For the Event and Community, we can get the budget directly from OCF I think.
Whether this is under the TSC or others looks trivial issue, let's discuss 
further later. 
BR, Uze Choi
-Original Message-
From: Thiago Macieira [mailto:thiago.macie...@intel.com] 
Sent: Friday, April 21, 2017 7:20 AM
To: iotivity-dev at lists.iotivity.org
Cc: ??? (Uze Choi)
Subject: Re: [dev] Fwd: [isg] Notes from ISG call 2017-04-10/11

On Monday, 17 April 2017 23:45:48 PDT ??? (Uze Choi) wrote:
> I believe, IoTivity should be extended with cloud further and the 
> other vertical such as industrial domain.

As replied to Dwarka, agreed and I think we actually need more. We need Fog, we 
need more verticals and we need the opposite of Cloud: the edge devices too.

> For the better complete solution provider, Lightweight kernel is also 
> required.

Sorry, what do you mean by lightweight kernel? Do you mean the IoTivity 
Constrained implementation? Or do you mean IoTivity should work on an operating 
system kernel?

If it's the former, I agree and we have that. If it's the latter, I disagree 
vehemently. IoTivity should consume the product of other Open Source projects 
creating lightweight kernels.

> The other is the organizational misalignment with OCF.
> 
> IoTivity is currently separate open source project independent from OCF.
> 
> However, relationship is not so good. Very few support from OCF (just 
> infra budget support) and from the OCF view it show very few response 
> from OCF request. To allow more power with more responsibility into 
> each IoTivity position will facilitate better communication.

As I've explained in previous meetings and emails, I don't have a solution for 
the communication problem and the lack of attention from OCF and the majority 
of its member companies. I'll defer to you and to others who have more 
experience.

> So that TSC organization looks good, but BSC proposal looks little bit 
> overhead considering OCF OSWG.

Hmm

Here's an interesting thing: as I've been designing this proposal for IoTivity, 
I was also designing an almost identical one for another open source project 
that is the reference implementation of the interoperability specifications 
produced by another industry group (sounds familiar?). I just took the IoTivity 
one and had them review it. It turns out it was a lot of overhead on the BSC / 
GB side. So the proposal for them is to have only a TSC.

So I agree on scaling back the GB side for IoTivity. We don't have a budget 
that we need to manage, for example. However, beause IoTivity is a Linux 
Foundation Collaborative project, the GB needs to exist, even if they only meet 
twice a year just to check if everything is still going on correctly.

That also leaves the Events and Community subcommittee. Events is definitely a 
non-technical task, but since we don't have money to sponsor anything anyway, 
do we need the work? If it's just the Developer Community that is left, we can 
justify it as a technical work.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

[dev] Jenkins Build Error again

[최우제 (Uze Choi)]

Hi CJ,

Today, Jenkins does not initiate build due to 
hudson.remoting.RemotingSystemException.
Not sporadically but always.
Could you check and make it normal ASAP?
For the release preparation, pending verification causes critical issue.

BR, Uze Choi
-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Friday, April 14, 2017 5:18 PM
To: 'iotivity-helpdesk at rt.linuxfoundation.org'
Cc: iotivity-dev at lists.iotivity.org
Subject: [IoTivity Helpdesk #39786] AutoReply: Windows Build Error in Jenkins

Hi CJ again,

There are lot of build fails looks like server system issue.
We cannot make the tag due to pending merge for test start

Every commit has one or two items with build fail. 
I just listed up from my reviewed commit.
Could you take any action to resolve it? We have a time constraint to handle 
IoTivity release soon.

https://build.iotivity.org/ci/job/iotivity-verify-windows-vs2013/10988/ 
https://build.iotivity.org/ci/job/iotivity-verify-windows-vs2013/11000/console

https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8785/
https://build.iotivity.org/ci/job/iotivity-verify-tizen/12841/console 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured/12766/ 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8764/
https://build.iotivity.org/ci/job/iotivity-verify-simulator/12800/ 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8772/console
 
https://build.iotivity.org/ci/job/iotivity-verify-linux_unsecured/12808/

BR, Uze Choi
-Original Message-
From: IoTivity Helpdesk via RT 
[mailto:iotivity-helpd...@rt.linuxfoundation.org] 
Sent: Thursday, April 13, 2017 1:31 PM
To: uzchoi at samsung.com
Subject: [IoTivity Helpdesk #39786] AutoReply: Windows Build Error in Jenkins


Greetings,

Your support ticket regarding:
"Windows Build Error in Jenkins",
has been entered in our ticket tracker.  A summary of your ticket appears below.

If you have any follow-up related to this issue, please reply to this email or 
include:

 [IoTivity Helpdesk #39786]

in the subject line of subsequent emails.

Thank you,
Linux Foundation Support Team

-
Hi C.J

Frequently error happen in Windows build,
https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10770/console
 https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10799/console
How can we solve this issue?
When we cannot contact you in time, we should wait one day or so until you 
notice it.

BR, Uze Choi

[dev] Question about iotivity simulator error

[최우제 (Uze Choi)]

For some reasons, eclipse plugin happens to be not installed properly.

Please make sure perspective icon exist as follows.





BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of
???/?/?(?)ICS?(addy.kim at lge.com)
Sent: Wednesday, April 19, 2017 1:26 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Question about iotivity simulator error



Hi, All

This is Jeonghwan Kim from LGE.



I tried to install simulator refer to Option 1 on
https://wiki.iotivity.org/iotivity_tool_guide.

But I meet an issue when I tried to execution.

Anyone have solution?



My environment is below and Eclipse Log is attached.

Ubuntu 14.04 / Eclipse neon.



Thank you in advanced.



Best

Jeonghwan Kim

-- next part --
HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8589 bytes
Desc: ?? ?? .
URL: 

[dev] [for 1.3 release] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi Randeep,

As a security project maintainer, could you respond back and resolve the
issue?

BR, Uze Choi

From: Muhammad Mushfiqul Islam [mailto:i.mush...@samsung.com] 
Sent: Tuesday, April 18, 2017 12:43 PM
To: Uze Choi
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [for 1.3 release] list sharing and update request for
some missing blocks



Hello,

I think we are ready for testing.

But I need clarification on security updates. We are observing some new
APIs on 1.3.0-RC1 for Provisioning Manager. These APIs were available
neither on master branch nor on the new/updated API list you provided
earlier.

Will they be considered as public API or internal private API?

Here is the list:

PM csdk:
OCStackResult OCPDMCleanupForTimeout()
OCStackResult OCIsSubownerOfDevice()
OCStackResult OCProvisionACL2()
OCStackResult OCGetCSRResource()
OCStackResult OCGetRolesResource()
OCStackResult OCDeleteRoleCertificateByCredId()
OCStackResult OCProvisionSymmetricRoleCredentials()
OCStackResult OCProvisionCertificate()
OCStackResult OCSaveOwnCertChain()
OCStackResult OCSaveOwnRoleCert()
OCStackResult OCRemoveCredential()



PM CPP sdk:
static OCStackResult pdmCleanupForTimeout()
static OCStackResult setDeviceIdSeed()





- Thanks & Regards,

Mushfiqul Islam Antu







- Original Message -

Sender : Uze Choi  Principal Engineer/IoT Lab./Samsung
Electronics

Date : 2017-04-17 17:33 (GMT+6)

Title : [dev] [for 1.3 release] list sharing and update request for some
missing blocks

To : iotivity-dev at lists.iotivity.org



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

Done

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

Done(Todd)

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

Done(Todd)

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done(Rick)

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev










-- next part --
HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?? ?? .
URL: 

[dev] Fwd: [isg] Notes from ISG call 2017-04-10/11

[최우제 (Uze Choi)]

Hi All,



Attached material shared by Dwarka has just my proposal, but happen to has just 
company name without my name.

That attachment was written only for ISG. To share it ioTivity, more 
explanation needs  to be addressed as follows.



Currently IoTivity suffer from short of contribution and activity.

I think this is due to the technology incompleteness. Currently IoTivity just 
mostly focus on D2D and Cloud server little bit.

However, most of company deliver the product with cloud inter-relation. And 
cross domain based on cloud solution.

I believe, IoTivity should be extended with cloud further and the other 
vertical such as industrial domain.

For the better complete solution provider, Lightweight kernel is also required.



The other is the organizational misalignment with OCF.

IoTivity is currently separate open source project independent from OCF.

However, relationship is not so good. Very few support from OCF (just infra 
budget support) and from the OCF view it show very few response from OCF 
request. To allow more power with more responsibility into each IoTivity 
position will facilitate better communication.

So that TSC organization looks good, but BSC proposal looks little bit overhead 
considering OCF OSWG.



Looking at the beyond OCF1.0 compliant, we need to hurry up setting up the 
reorganization.

Some items looks more discussion but others may not.

Once some consensus we get, we need to move forward ASAP.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Dwarkaprasad 
Dayama
Sent: Tuesday, April 18, 2017 1:48 PM
To: 'Thiago Macieira'; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Fwd: [isg] Notes from ISG call 2017-04-10/11



Hi IoTivity dev community members,



As shared by Thiago, I am sharing another suggestion for reorg behalf of Uze.

Feedback is welcome to make better open source project organization.



Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation ? OpenSource WG Vice-Chair | Spec. Cord. TG Chair

Iotivity Steering Group ? Advisory Committee



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Tuesday, April 18, 2017 3:09 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Fwd: [isg] Notes from ISG call 2017-04-10/11



Dear developers



Please find the notes from last Monday's ISG call.



Also, as noted, we'd like to have further discussion on the structure of the 
IoTivity project. Please find attached the beginning of said discussion. The 
organisation of the source code into Projects and subsystems is up to the 
developers working in them, so treat the attachment as a suggestion.



Uze will post a different suggestion.



-- Forwarded Message --



Subject: [isg] Notes from ISG call 2017-04-10/11

Date: segunda-feira, 10 de abril de 2017, 16:44:23 PDT

From: Macieira, Thiago 

To: isg at lists.iotivity.org 



IoTivity Steering Group meeting 2017-04-10

Attendees:

? Kathleen

? Thiago

? Valerie

? Uze

? Dwarka

? Omar

? MJ Jeong

? Kyeongwoon Lee



? IoTivity Governance

oConcerns from Samsung

? Does this create more work for Project Leaders? More meetings to attend?

? Is this the correct project organisation? For example, how does 
Constrained and Node show up?

oNext steps:

oThiago will post current proposal for discussion among developers

oUze will post counter-proposal with different project/subcommittee 
setup

? IoTivity API

? Lots of confusion between what?s public and what?s 
private API

? ISG did approve creation of API Function, but there were 
no volunteers

? Omar will see if he can find a volunteer


-

-- 

Thiago Macieira - thiago.macieira (AT) intel.com

Software Architect - Intel Open Source Technology Center



-- next part --
HTML ?? ??...
URL: 

[dev] IoTivity 1.3-rel vs CTT 1.5.4 - Test Results

[최우제 (Uze Choi)]

Hello, Regarding discovery logic, are there any other contributor?

This problem prevents next step continue.

We cannot make any progress due to this blocker.

Ziran is busy in versioning related patch as of now. Contribution will be very 
welcomed

BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Friday, April 14, 2017 3:55 PM
To: Habib Virji (habib.virji at samsung.com); 'Ziran Sun'; 'i.mushfiq at 
samsung.com'
Cc: 'nathan.heldt-sheller at intel.com'; 'Daniel.Mihai at microsoft.com'; 
'vkandalla at graniteriverlabs.com'; 'lab_mgr at openconnectivity.org'; 
'Towhidul Islam'; 'Mark Trayer'; '???'; 'ofer at tekoia.com'; 
'richard.a.bardini at intel.com'; ''; 'b.scriber at cablelabs.com'; 
'dbartolome at at4wireless.com'; '???'; 'david.r.kaufman at honeywell.com'; 
'todd.malsbary at intel.com'; 'srikguru at microsoft.com'; '???'; 'ed.agis at 
intel.com'; 'joseph.l.morrow at intel.com'; '???'; 'craig at ecaspia.com'; 
'Jacek Hryszkiewicz'; 'Mitch Kettrick'
Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results



Ziran/Habib,

Could you check the discovery response payload applying the OCF1.0 spec?

BR, Uze Choi

From: Jacek Hryszkiewicz [mailto:jacek.hryszkiew...@comarch.com] 
Sent: Friday, April 14, 2017 3:31 PM
To: 'Mitch Kettrick'; 'Ziran Sun'; i.mushfiq at samsung.com
Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla 
at graniteriverlabs.com; lab_mgr at openconnectivity.org; 'Towhidul Islam'; 
'Mark Trayer'; '???'; '???'; ofer at tekoia.com; richard.a.bardini at 
intel.com; ''; b.scriber at cablelabs.com; dbartolome at at4wireless.com; 
'???'; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander 
at cisco.com; srikguru at microsoft.com; '???'; ed.agis at intel.com; '???'; 
joseph.l.morrow at intel.com; '???'; craig at ecaspia.com
Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results



Hi,



Issue 1:

This is IUT issue.

CTT sends RETIREVE request for oic/res with the interface oic.if.baseline. 
Proper response for such request is an array of objects (see schema and RAML) 
while here IUT responds with an object:

{"n":"Vendor Smart Home AirCon 

[dev] [for 1.3 release] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi Dwarka, I meant not CTT but Iotivity TC from QA view.

And some patches are required as I heard from Ziran.



BR, UZe Cho

From: Dwarkaprasad Dayama [mailto:dwarka.day...@samsung.com] 
Sent: Monday, April 17, 2017 10:00 PM
To: '??? (Uze Choi)'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [for 1.3 release] list sharing and update request for
some missing blocks



Hi Uze,



For Versioning TC ready status is Done. I haven?t seen any more changes
coming in recently.



Regards

Dwarka


--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation - OpenSource WG Vice-Chair | Spec. Cord. TG
Chair

Iotivity Steering Group - Advisory Committee



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, April 17, 2017 8:33 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [for 1.3 release] list sharing and update request for some
missing blocks



Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] IoTivity 1.3-rel vs CTT 1.5.4 - Test Results

[최우제 (Uze Choi)]

Hello, Regarding discovery logic, are there any other contributor?

This problem prevent next step continue.

We cannot take any progress due to this blocker.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Friday, April 14, 2017 3:55 PM
To: Habib Virji (habib.virji at samsung.com); 'Ziran Sun'; 'i.mushfiq at 
samsung.com'
Cc: 'nathan.heldt-sheller at intel.com'; 'Daniel.Mihai at microsoft.com'; 
'vkandalla at graniteriverlabs.com'; 'lab_mgr at openconnectivity.org'; 
'Towhidul Islam'; 'Mark Trayer'; '???'; 'ofer at tekoia.com'; 
'richard.a.bardini at intel.com'; ''; 'b.scriber at cablelabs.com'; 
'dbartolome at at4wireless.com'; '???'; 'david.r.kaufman at honeywell.com'; 
'todd.malsbary at intel.com'; 'srikguru at microsoft.com'; '???'; 'ed.agis at 
intel.com'; 'joseph.l.morrow at intel.com'; '???'; 'craig at ecaspia.com'; 
'Jacek Hryszkiewicz'; 'Mitch Kettrick'
Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results



Ziran/Habib,

Could you check the discovery response payload applying the OCF1.0 spec?

BR, Uze Choi

From: Jacek Hryszkiewicz [mailto:jacek.hryszkiew...@comarch.com] 
Sent: Friday, April 14, 2017 3:31 PM
To: 'Mitch Kettrick'; 'Ziran Sun'; i.mushfiq at samsung.com
Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla 
at graniteriverlabs.com; lab_mgr at openconnectivity.org; 'Towhidul Islam'; 
'Mark Trayer'; '???'; '???'; ofer at tekoia.com; richard.a.bardini at 
intel.com; ''; b.scriber at cablelabs.com; dbartolome at at4wireless.com; 
'???'; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander 
at cisco.com; srikguru at microsoft.com; '???'; ed.agis at intel.com; '???'; 
joseph.l.morrow at intel.com; '???'; craig at ecaspia.com
Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results



Hi,



Issue 1:

This is IUT issue.

CTT sends RETIREVE request for oic/res with the interface oic.if.baseline. 
Proper response for such request is an array of objects (see schema and RAML) 
while here IUT responds with an object:

{"n":"Vendor Smart Home AirCon 

[dev] [for 1.3 release] list sharing and update request for some missing blocks

[최우제 (Uze Choi)]

Hi All, this is update which I know



Introspection, Versioning, Endpoint are having pending patches and open
issues as of now. (Sri., Ziran, bg.chun please update them)

Security patches are expected to be merged by this week (Nathan commented)

MPM and AllJoyn Bridge still do not know the status. (Todd, please update
it)

CoAP Native Cloud project. (JK, please share the progress)

>From the CTT testing, discovery logic looks broken, this is test blocker
and should be cleared ASAP . (Ziran/Habib, please check it)

Provisioning manager is also broken due to unidentified patch. (Sergiy is
fixing it now)

>From Testing case, Antu, If you have any update please update table context.

Please care programming document on wiki also.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

IOT-1965 in review

Json2cbor update

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

Endpoint PM issue.

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

Routing issue

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

(Due: 4/21)

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [RC1 Tagged] RE: 1.3-rel Branch out/QA start request.

[최우제 (Uze Choi)]

1.3.0-RC1 is tagged on 1.3-rel branch.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, April 14, 2017 4:19 PM
To: iotivity-maintainers at lists.iotivity.org
Cc: iotivity-dev at lists.iotivity.org
Subject: [dev] [RC1 Taggable check] RE: 1.3-rel Branch out/QA start request.



Hi Each maintainer,

I?d like to make a RC1 tag on 1.3-rel.

If have the issue for test start for each module, please correct them and 
make the branch code working well.

And let me know to hold on tag prior to merging launched.

BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, April 12, 2017 6:16 AM
To: uzchoi at samsung.com; Kevin Kane; Mats Wichmann; iotivity-dev at 
lists.iotivity.org
Subject: RE: [dev] 1.3-rel Branch out/QA start request.



Uze,

I notice that you had created the 1.3-rel branch but no tag.

Will there be a tag?



I have created the 1.3-rel branch for iotivity-upnp-bridge 
(https://gerrit.iotivity.org/gerrit/#/admin/projects/iotivity-upnp-bridge,branches)

I will add the a similar tag when put in iotivity.

We will test 1.3-rel branch for iotivity-upnp-bridge with 1.3-rel branch 
iotivity.



Thanks,

-Rick



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ???
Sent: Monday, April 10, 2017 3:50 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.



Definitely.

Please mergeback into master after work on 1.3-rel if not release branch 
specific.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 07:31 (GMT+9)
Title : RE: RE: [dev] 1.3-rel Branch out/QA start request.

For changes that are already pending, that sounds fine, especially since the 
branches haven?t yet diverged at all. But from this point forward, for any new 
changes, let?s submit directly to 1.3-rel and then have a regular merge cadence.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:24 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Hi Kevin,

Thank you for your suggestion.

It will be good to strictly follow the release branch merging policy.

However for the better efficiency, let's accept currently pending commits 
merged into master branch first and cherrypick in to 1.3-rel as a next step.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 06:14 (GMT+9)
Title : RE: [dev] 1.3-rel Branch out/QA start request.

It'd be better for any 1.3 changes/bug fixes to be committed directly to 
1.3-rel, and then 1.3-rel should be merged regularly into master to pick those 
changes up for the future. I'd suggest any pending changes on master that 
should be in 1.3 be abandoned and resubmitted to 1.3-rel. All the 
cherry-picking that happened between 1.2-rel and master did not work well at 
all.

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Monday, April 10, 2017 1:50 PM
To: ??? (Uze Choi) ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.

On 04/10/2017 04:57 AM, ??? (Uze Choi) wrote:
> Hi All,
> 
>  
> 
> 1.3-rel branch has been created. 1.3.0 Release period just started.
> 
> There are approximately 70 change sets waiting merge on the master 
> branches
> 
> Except this patches, All code merge should have the release management Lead 
> review +1 on the release branch.


So for owners of waiting changesets... how do we proceed?  The small number I 
have in the queue (five public) I would not consider release-critical, but also 
letting master and 1.3-rel diverge is not wonderful, makes lots of work later 
for someone - I'm remembering what Phil and others had to do to get master back 
in sync with 1.2-rel.

Advice please?



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev
 

 
=02%7C01%7Ckkane%40microsoft.com%7C3a7057b259e34a700d8608d4805326b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274542026472282=kaW7CiPhNlVkyehkZTEnFkQMMNTJXNXUHlkjKaXuMWQ%3D=0











  

[dev] [IoTivity Helpdesk #39786] AutoReply: Windows Build Error in Jenkins

[최우제 (Uze Choi)]

Hi CJ again,

There are lot of build fails looks like server system issue.
We cannot make the tag due to pending merge for test start

Every commit has one or two items with build fail. 
I just listed up from my reviewed commit.
Could you take any action to resolve it? We have a time constraint to handle 
IoTivity release soon.

https://build.iotivity.org/ci/job/iotivity-verify-windows-vs2013/10988/ 
https://build.iotivity.org/ci/job/iotivity-verify-windows-vs2013/11000/console

https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8785/
https://build.iotivity.org/ci/job/iotivity-verify-tizen/12841/console 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured/12766/ 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8764/
https://build.iotivity.org/ci/job/iotivity-verify-simulator/12800/ 
https://build.iotivity.org/ci/job/iotivity-verify-linux_secured_with_tcp/8772/console
 
https://build.iotivity.org/ci/job/iotivity-verify-linux_unsecured/12808/

BR, Uze Choi
-Original Message-
From: IoTivity Helpdesk via RT 
[mailto:iotivity-helpd...@rt.linuxfoundation.org] 
Sent: Thursday, April 13, 2017 1:31 PM
To: uzchoi at samsung.com
Subject: [IoTivity Helpdesk #39786] AutoReply: Windows Build Error in Jenkins


Greetings,

Your support ticket regarding:
"Windows Build Error in Jenkins",
has been entered in our ticket tracker.  A summary of your ticket appears below.

If you have any follow-up related to this issue, please reply to this email or 
include:

 [IoTivity Helpdesk #39786]

in the subject line of subsequent emails.

Thank you,
Linux Foundation Support Team

-
Hi C.J

Frequently error happen in Windows build,
https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10770/console
 https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10799/console
How can we solve this issue?
When we cannot contact you in time, we should wait one day or so until you 
notice it.

BR, Uze Choi

[dev] [RC1 Taggable check] RE: 1.3-rel Branch out/QA start request.

[최우제 (Uze Choi)]

Hi Each maintainer,

I?d like to make a RC1 tag on 1.3-rel.

If have the issue for test start for each module, please correct them and 
make the branch code working well.

And let me know to hold on tag prior to merging launched.

BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, April 12, 2017 6:16 AM
To: uzchoi at samsung.com; Kevin Kane; Mats Wichmann; iotivity-dev at 
lists.iotivity.org
Subject: RE: [dev] 1.3-rel Branch out/QA start request.



Uze,

I notice that you had created the 1.3-rel branch but no tag.

Will there be a tag?



I have created the 1.3-rel branch for iotivity-upnp-bridge 
(https://gerrit.iotivity.org/gerrit/#/admin/projects/iotivity-upnp-bridge,branches)

I will add the a similar tag when put in iotivity.

We will test 1.3-rel branch for iotivity-upnp-bridge with 1.3-rel branch 
iotivity.



Thanks,

-Rick



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ???
Sent: Monday, April 10, 2017 3:50 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.



Definitely.

Please mergeback into master after work on 1.3-rel if not release branch 
specific.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 07:31 (GMT+9)
Title : RE: RE: [dev] 1.3-rel Branch out/QA start request.

For changes that are already pending, that sounds fine, especially since the 
branches haven?t yet diverged at all. But from this point forward, for any new 
changes, let?s submit directly to 1.3-rel and then have a regular merge cadence.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:24 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Hi Kevin,

Thank you for your suggestion.

It will be good to strictly follow the release branch merging policy.

However for the better efficiency, let's accept currently pending commits 
merged into master branch first and cherrypick in to 1.3-rel as a next step.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 06:14 (GMT+9)
Title : RE: [dev] 1.3-rel Branch out/QA start request.

It'd be better for any 1.3 changes/bug fixes to be committed directly to 
1.3-rel, and then 1.3-rel should be merged regularly into master to pick those 
changes up for the future. I'd suggest any pending changes on master that 
should be in 1.3 be abandoned and resubmitted to 1.3-rel. All the 
cherry-picking that happened between 1.2-rel and master did not work well at 
all.

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Monday, April 10, 2017 1:50 PM
To: ??? (Uze Choi) ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.

On 04/10/2017 04:57 AM, ??? (Uze Choi) wrote:
> Hi All,
> 
>  
> 
> 1.3-rel branch has been created. 1.3.0 Release period just started.
> 
> There are approximately 70 change sets waiting merge on the master 
> branches
> 
> Except this patches, All code merge should have the release management Lead 
> review +1 on the release branch.


So for owners of waiting changesets... how do we proceed?  The small number I 
have in the queue (five public) I would not consider release-critical, but also 
letting master and 1.3-rel diverge is not wonderful, makes lots of work later 
for someone - I'm remembering what Phil and others had to do to get master back 
in sync with 1.2-rel.

Advice please?



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev
 

 
=02%7C01%7Ckkane%40microsoft.com%7C3a7057b259e34a700d8608d4805326b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274542026472282=kaW7CiPhNlVkyehkZTEnFkQMMNTJXNXUHlkjKaXuMWQ%3D=0











  

 

-- next part --
HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?? ?? .
URL: 

[dev] 1.3-rel Branch out/QA start request.

[최우제 (Uze Choi)]

Any automatic tool can we apply?

Do we need to talk LF infra team?

BR, Uze Choi

From: Omar Maabreh [mailto:om...@microsoft.com] 
Sent: Friday, April 14, 2017 6:59 AM
To: Soemin Tjong; Bell, Richard S; ??? (Uze Choi); Kevin Kane; 'Mats Wichmann'; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-rel Branch out/QA start request.



I think we really should consider having a regular process to merge from 
1.3-rel to master.

1.   It would be much more efficient than moving changes one by one.

2.   We already saw in 1.2 that it was error prone and a lot of changes got 
left out, and it took a lot of time afterwards to go and reconcile.

3.   No more having to go research to find out if a particular fix made 
into master?



The process could be pretty light-weight and can be done on a regular cadence 
(perhaps once a week).



Thanks,

- Omar



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Soemin Tjong
Sent: Wednesday, April 12, 2017 12:08 PM
To: Bell, Richard S ; ??? (Uze Choi) ; Kevin Kane ; 'Mats Wichmann' ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.




This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about   spoofing

  Feedback

I like Kevin?s suggestion, automatic and regular merge from 1.3-rel to master 
is efficient for everyone.   

Relevant maintainers/committers should be ready to help with merge conflicts.  



Unless if there are cases where changes are to remain only in 1.3.  

But those should be exceptions and how they are handled should be discussed 
separately.



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Bell, Richard S
Sent: Wednesday, April 12, 2017 9:25 AM
To: ??? (Uze Choi) ; Kevin Kane ; 'Mats Wichmann' ; iotivity-dev at 
lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.



Uze,

So you are saying that there will be no automatic merging from 1.3-rel to 
master.

That the it  is responsibility maintainer and merges will be done manually?



Thanks,

-Rick





From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, April 11, 2017 8:56 PM
To: 'Kevin Kane' ; 'Mats Wichmann' ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.



There is no regular merging release branch to master. This work is maintainer 
responsibility with help of committer.

If a commit is related with release, it should be launched on release branch 
first and merge back to master branch with maintainer responsibility.



BR, Uze Choi

From: Kevin Kane [  mailto:kk...@microsoft.com] 
Sent: Wednesday, April 12, 2017 2:49 AM
To:   uzchoi at samsung.com; Mats Wichmann;  
 iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Two more things:



1.  Do we have a resource available to make sure there are regular merges 
from 1.3-rel to master? This also means there should never be a cherry-pick 
from 1.3-rel to master.
2.  For changes already up for master to be later cherry-picked: There was 
confusion during 1.2 about who was responsible for doing the cherry-picks. I 
suggest this time around, if an author has submitted a change to master and 
believes it should be on 1.3-rel, the author is responsible for doing the 
cherry-pick and getting the appropriate people on the review, to shepherd the 
change into 1.3-rel. There should be no expectation that anyone else will 
cherry-pick the change to 1.3-rel.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:50 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Definitely.

Please mergeback into master after work on 1.3-rel if not release branch 
specific.

BR Uze Choi



- Original Message -
Sender : Kevin Kane <  kkane at microsoft.com>
Date : 2017-04-11 07:31 (GMT+9)
Title : RE: RE: [dev] 1.3-rel Branch out/QA start request.

For changes that are already pending, that sounds fine, especially since the 
branches haven?t yet diverged at all. But from this point forward, for any new 
changes, let?s submit directly to 1.3-rel and then have a regular merge cadence.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:24 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Hi Kevin,

Thank you for your suggestion.

It will be good to strictly follow the release branch merging policy.

However for the 

[dev] still trying to figure out API docs - octimer.h

[최우제 (Uze Choi)]

>From these four files.
resource/csdk/connectivity/api/cautilinterface.h is need to be open public.
But, this also requires resource/csdk/connectivity/api/cacommon.h

Other links is not required.
 resource/csdk/connectivity/api/cainterface.h
 resource/csdk/connectivity/api/casecurityinterface.h

fix not to use below in cacommon.h looks required
#ifdef HAVE_SYS_POLL_H
#ifdef HAVE_WINSOCK2_H

BR, Uze Choi
-Original Message-
From: Mats Wichmann [mailto:m...@wichmann.us] 
Sent: Friday, April 14, 2017 2:16 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: Re: [dev] still trying to figure out API docs - octimer.h

On 04/13/2017 12:29 AM, ??? (Uze Choi) wrote:
> The resource/csdk/connectivity files are public open purpose.
> There was a discussion as below thru mailing list for this 3 weeks 
> before with Jiwhan.Seo.
> 
> --
> Since there were so many requirements to handle CA layer in person.
> I believe that this header can be helpped for lots of scenarios.
> please refer below the patchset
> https://gerrit.iotivity.org/gerrit/#/c/18157/
> --
> 
> BR, Uze Choi

Okay, circled back to check a bit more.

Uze says the files in csdk/connectivity should be open, presumably meaning the 
four headers that are currently listed in the Doxyfile

resource/csdk/connectivity/api/cacommon.h
resource/csdk/connectivity/api/cainterface.h
resource/csdk/connectivity/api/casecurityinterface.h
resource/csdk/connectivity/api/cautilinterface.h

None of these files are copied to out/, however, so that should probably be 
corrected.

Among the files which ARE copied to out/, it's not a completely self-contained 
set:

ocpayload.h includes securevirtualresourcetypes.h, which is a file not copied 
to out/  (this is a file that does appear in the c-api Doxyfile).
 That file in turn includes byte_array.h, which is neither copied to out/ nor 
listed in the c-api Doxyfile.  One of the connectivity headers above also 
includes this byte_array.h.

octypes.h includes iotivity_config.h which there was some discussion on 
recently (I think there was a patch that tried to reduce inclusion of this 
header), and it's somewhat problematic to include as a "published"
header since it's designed to change based on doing checks on the build host.

What should we do next to sort this out?

[dev] Windows Build Error in Jenkins

[최우제 (Uze Choi)]

Thanks, it works well after they are merged.

BR, Uze Choi

From: Way Vadhanasin [mailto:wayakorn.vadhana...@microsoft.com] 
Sent: Thursday, April 13, 2017 3:24 PM
To: ??? (Uze Choi); iotivity-helpdesk at rt.linuxfoundation.org
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Windows Build Error in Jenkins



My understanding is these Jenkins failure due to inability to delete files
(on Windows) are caused by hung/deadlocked tests. CJ and Dan recently fixed
the issues with these:



https://gerrit.iotivity.org/gerrit/#/c/18713

https://gerrit.iotivity.org/gerrit/#/c/18821



Thanks,

Way



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Wednesday, April 12, 2017 9:30 PM
To: iotivity-helpdesk at rt.linuxfoundation.org
Cc: iotivity-dev at lists.iotivity.org
Subject: [dev] Windows Build Error in Jenkins



Hi C.J



Frequently error happen in Windows build,

https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10770/console
  

 https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10799/console
  

How can we solve this issue?

When we cannot contact you in time, we should wait one day or so until you
notice it.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Android sample app crash issue.

[최우제 (Uze Choi)]

Hi Randeep,

I heard that this is related with your side.

Could you fix it ASAP?

BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, April 13, 2017 4:08 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Android sample app crash issue.



Hi Rick,



Could you check this issue at high priority?

https://jira.iotivity.org/browse/IOT-2037

All the other Android app crash with same reason.

This is a blocker for IoTivity QA start.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Android sample app crash issue.

[최우제 (Uze Choi)]

Hi Rick,



Could you check this issue at high priority?

https://jira.iotivity.org/browse/IOT-2037

All the other Android app crash with same reason.

This is a blocker for IoTivity QA start.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] still trying to figure out API docs - octimer.h

[최우제 (Uze Choi)]

The resource/csdk/connectivity files are public open purpose.
There was a discussion as below thru mailing list for this 3 weeks before
with Jiwhan.Seo.

--
Since there were so many requirements to handle CA layer in person.
I believe that this header can be helpped for lots of scenarios.
please refer below the patchset
https://gerrit.iotivity.org/gerrit/#/c/18157/ 
--

BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Dave Thaler via iotivity-dev
Sent: Thursday, April 06, 2017 5:06 AM
To: Mats Wichmann; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] still trying to figure out API docs - octimer.h

My understanding is
* The resource/csdk/connectivity files are not supposed to be public, it's
an internal layer
* Any files in an /internal subdir are certainly not supposed to be public
* Some of the headers under resource/csdk/security/provisioning are
supposed to be public so they can be used by OBT's.  The fact that they're
not copied to out/ by the build is, in my view, a bug.

I'm not certain about the others, but I would assume that by default,
nothing else in the second list should be public.
And sample code should never include headers except those copied to out/
but I believe there are bugs there where samples do the wrong thing today.
Unit test code will of course use them and call internal APIs, but sample
code should not.

-Original Message-
From: Mats Wichmann [mailto:m...@wichmann.us] 
Sent: Wednesday, April 5, 2017 12:13 PM
To: Dave Thaler ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] still trying to figure out API docs - octimer.h

On 04/05/2017 11:06 AM, Dave Thaler wrote:
> not published to out/ so none of them are public APIs.

Okay, by this metric I think we have a bit of a mismatch.  If I'm not doing
my searches wrong, doxygen finds 60 header files based on the INPUT
directive it's given in the c-doc Doxyfile. Of those only 13 seem to appear
in out/ :

include/resource/ocpayload.h
include/resource/ocpresence.h
include/resource/ocstackconfig.h
include/resource/ocstack.h
include/resource/octypes.h
include/resource/rd_client.h
include/resource/RDClient.h
include/service/easy-setup/easysetup.h
include/service/easy-setup/escommon.h
include/service/easy-setup/ESEnrolleeCommon.h
include/service/notification/NSCommon.h
include/service/notification/NSConsumerInterface.h
include/service/notification/NSProviderInterface.h

(RDClient.h being the previously identified one that is in C++ and thus
unlikely to be part of the "C API")

The places "in the source" where doxygen has picked files from are - and it
looks from this like there's some recursion going on that should not be
(RECURSIVE flag is set to NO):

resource/csdk/connectivity/api/cacommon.h
resource/csdk/connectivity/api/cainterface.h
resource/csdk/connectivity/api/casecurityinterface.h
resource/csdk/connectivity/api/cautilinterface.h
resource/csdk/connectivity/src/bt_le_adapter/linux/utils.h
resource/csdk/include/octypes.h
resource/csdk/resource-directory/include/rd_client.h
resource/csdk/resource-directory/include/RDClient.h
resource/csdk/resource-directory/include/rd_database.h
resource/csdk/resource-directory/include/rd_server.h
resource/csdk/routing/include/routingmanager.h
resource/csdk/routing/include/routingmanagerinterface.h
resource/csdk/routing/include/routingmessageparser.h
resource/csdk/routing/include/routingtablemanager.h
resource/csdk/routing/include/routingutility.h
resource/csdk/security/include/base64.h
resource/csdk/security/include/iotvticalendar.h
resource/csdk/security/include/pbkdf2.h
resource/csdk/security/include/pinoxmcommon.h
resource/csdk/security/include/pkix_interface.h
resource/csdk/security/include/securevirtualresourcetypes.h
resource/csdk/security/include/srmutility.h
resource/csdk/security/provisioning/include/cloud/occloudprovisioning.h
resource/csdk/security/provisioning/include/cloud/utils.h
resource/csdk/security/provisioning/include/internal/credentialgenerator.h
resource/csdk/security/provisioning/include/internal/multipleownershiptransf
ermanager.h
resource/csdk/security/provisioning/include/internal/otmcontextlist.h
resource/csdk/security/provisioning/include/internal/ownershiptransfermanage
r.h
resource/csdk/security/provisioning/include/internal/provisioningdatabaseman
ager.h
resource/csdk/security/provisioning/include/internal/secureresourceprovider.
h
resource/csdk/security/provisioning/include/ocprovisioningmanager.h
resource/csdk/security/provisioning/include/oxm/oxmjustworks.h
resource/csdk/security/provisioning/include/oxm/oxmmanufacturercert.h
resource/csdk/security/provisioning/include/oxm/oxmpreconfpin.h
resource/csdk/security/provisioning/include/oxm/oxmrandompin.h
resource/csdk/security/provisioning/include/pmtypes.h
resource/csdk/security/provisioning/include/pmutility.h

[dev] Windows Build Error in Jenkins

[최우제 (Uze Choi)]

Hi C.J



Frequently error happen in Windows build,

https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10770/console 

 https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2013/10799/console 

How can we solve this issue?

When we cannot contact you in time, we should wait one day or so until you
notice it.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] 1.3-rel Branch out/QA start request.

[최우제 (Uze Choi)]

There is no regular merging release branch to master. This work is maintainer 
responsibility with help of committer.

If a commit is related with release, it should be launched on release branch 
first and merge back to master branch with maintainer responsibility.



BR, Uze Choi

From: Kevin Kane [mailto:kk...@microsoft.com] 
Sent: Wednesday, April 12, 2017 2:49 AM
To: uzchoi at samsung.com; Mats Wichmann; iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Two more things:



1.  Do we have a resource available to make sure there are regular merges 
from 1.3-rel to master? This also means there should never be a cherry-pick 
from 1.3-rel to master.
2.  For changes already up for master to be later cherry-picked: There was 
confusion during 1.2 about who was responsible for doing the cherry-picks. I 
suggest this time around, if an author has submitted a change to master and 
believes it should be on 1.3-rel, the author is responsible for doing the 
cherry-pick and getting the appropriate people on the review, to shepherd the 
change into 1.3-rel. There should be no expectation that anyone else will 
cherry-pick the change to 1.3-rel.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:50 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Definitely.

Please mergeback into master after work on 1.3-rel if not release branch 
specific.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 07:31 (GMT+9)
Title : RE: RE: [dev] 1.3-rel Branch out/QA start request.

For changes that are already pending, that sounds fine, especially since the 
branches haven?t yet diverged at all. But from this point forward, for any new 
changes, let?s submit directly to 1.3-rel and then have a regular merge cadence.



From: ??? [mailto:uzc...@samsung.com] 
Sent: Monday, April 10, 2017 3:24 PM
To: Kevin Kane ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Hi Kevin,

Thank you for your suggestion.

It will be good to strictly follow the release branch merging policy.

However for the better efficiency, let's accept currently pending commits 
merged into master branch first and cherrypick in to 1.3-rel as a next step.

BR Uze Choi



- Original Message -
Sender : Kevin Kane 
Date : 2017-04-11 06:14 (GMT+9)
Title : RE: [dev] 1.3-rel Branch out/QA start request.

It'd be better for any 1.3 changes/bug fixes to be committed directly to 
1.3-rel, and then 1.3-rel should be merged regularly into master to pick those 
changes up for the future. I'd suggest any pending changes on master that 
should be in 1.3 be abandoned and resubmitted to 1.3-rel. All the 
cherry-picking that happened between 1.2-rel and master did not work well at 
all.

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Monday, April 10, 2017 1:50 PM
To: ??? (Uze Choi) ; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.

On 04/10/2017 04:57 AM, ??? (Uze Choi) wrote:
> Hi All,
> 
>  
> 
> 1.3-rel branch has been created. 1.3.0 Release period just started.
> 
> There are approximately 70 change sets waiting merge on the master 
> branches
> 
> Except this patches, All code merge should have the release management Lead 
> review +1 on the release branch.


So for owners of waiting changesets... how do we proceed?  The small number I 
have in the queue (five public) I would not consider release-critical, but also 
letting master and 1.3-rel diverge is not wonderful, makes lots of work later 
for someone - I'm remembering what Phil and others had to do to get master back 
in sync with 1.2-rel.

Advice please?



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev
 

 
=02%7C01%7Ckkane%40microsoft.com%7C3a7057b259e34a700d8608d4805326b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274542026472282=kaW7CiPhNlVkyehkZTEnFkQMMNTJXNXUHlkjKaXuMWQ%3D=0











  

 

-- next part --
HTML ?? ??...
URL: 

[dev] 1.3-rel Branch out/QA start request.

[최우제 (Uze Choi)]

Hi All,



1.3-rel branch has been created. 1.3.0 Release period just started.

There are approximately 70 change sets waiting merge on the master branches 

Except this patches, All code merge should have the release management Lead 
review +1 on the release branch.



Antu(IoTivity QA Lead), Please start the release branch iotivity code against 
CTT Tool with the latest engineering version.



If each feature contributor has update on the progress, please let me know.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, April 07, 2017 5:37 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Branch out/QA start schedule for 1.3-release



Hi All,



1.3-rel Branch out schedule is early next Monday.

QA will start also early next week.

I recommend code to be merged by this week.

On the release branch, code merge will requires additional confirm from release 
function lead.



current status of 1.3 feature progress is as follows.


Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

1 Patch reviewing

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

N/A

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

From:   iotivity-dev-bounces 
at lists.iotivity.org [  
mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, March 31, 2017 5:13 PM
To:   iotivity-dev at 
lists.iotivity.org
Subject: [dev] 1.3-release feature code completion check



Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test 
perspective respectively.

Because there are lots of items in the release, Let me remove the feature with 
no responding in spite of requests.

* Example to answer. Introspection ?implementation: 100%, TC is made by 
IoTivity QA and 70% progress.



Introspection code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Versioning code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Endpoint  code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Security update  Feature is not merged yet, already we are communicating it. 
Let me tracking.



MPM   expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

AllJoyn Bridgeexpected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

WiFi Easy-Setup update   resource model update has been merged into master 
branch.

 Test is agreed with IoTivity QA lead? And progress for TC 
implementation from percentage view?

CoAP Native Cloud project (Resource Model Update, Web Socket)

 expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Generic Java Binding   expected scope is merged into master?

Test is agreed with IoTivity QA lead? And progress for TC 

[dev] Branch out/QA start schedule for 1.3-release

[최우제 (Uze Choi)]

Hi All,



1.3-rel Branch out schedule is early next Monday.

QA will start also early next week.

I recommend code to be merged by this week.

On the release branch, code merge will requires additional confirm from release 
function lead.



current status of 1.3 feature progress is as follows.


Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

1 Patch reviewing

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

payload separation 

In progress

IoTivity QA

Ziran

No API


Endpoint 

100%

merged

N/A

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

1 Patch reviewing

In progress

Todd

Todd

Wiki exist


AllJoyn Bridge   

60%

In progress

4 patch (iotivity.git)

In progress

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki exist


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

From:   iotivity-dev-bounces 
at lists.iotivity.org [  
mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, March 31, 2017 5:13 PM
To:   iotivity-dev at 
lists.iotivity.org
Subject: [dev] 1.3-release feature code completion check



Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test 
perspective respectively.

Because there are lots of items in the release, Let me remove the feature with 
no responding in spite of requests.

* Example to answer. Introspection ?implementation: 100%, TC is made by 
IoTivity QA and 70% progress.



Introspection code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Versioning code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Endpoint  code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Security update  Feature is not merged yet, already we are communicating it. 
Let me tracking.



MPM   expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

AllJoyn Bridgeexpected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

WiFi Easy-Setup update   resource model update has been merged into master 
branch.

 Test is agreed with IoTivity QA lead? And progress for TC 
implementation from percentage view?

CoAP Native Cloud project (Resource Model Update, Web Socket)

 expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Generic Java Binding   expected scope is merged into master?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?



BR, Uze Choi (IoTivity Release Function Lead)

-- next part --
HTML ?? ??...
URL: 

[dev] C API: conditional code

[최우제 (Uze Choi)]

I prefer this concept also. We can apply this rule in case of invalid parameter 
for specific compile option.

Then, in case of bool/void return, how can we return ?not implemented? error 
code?

BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Junghyun Oh
Sent: Friday, April 07, 2017 1:57 PM
To: Mats Wichmann
Cc: IoTivity Developer List
Subject: Re: [dev] C API: conditional code



+1 on "stub out functions if they don't apply  "



2017. 4. 6. ?? 11:27? "Mats Wichmann" ?? ??:


Some of the code that *is* in the C API is bracketed in conditional
compilation.

For example, ocpayload.h has:

#ifdef __WITH_TLS__
bool OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char
*name, const OicSecKey_t *value);
bool OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const
char *name, const OicSecKey_t *value);
bool OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const
char *name, OicSecKey_t *value);
#endif


I'm not really fond of the idea that the API has different components
depending on how the stack has been compiled.  Do we want to do this?
Or is it better to stub out functions if they don't apply - that is, the
above three would be present but return some form of "not implemented"
error if called?

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

-- next part --
HTML ?? ??...
URL: 

[dev] 1.3-release feature code completion check

[최우제 (Uze Choi)]

To make sure, it should work with 1.3.0 version in the end.

BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, April 05, 2017 10:53 PM
To: ??? (Uze Choi); 'Muhammad Mushfiqul Islam'; Nash, George
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



I understand and we will be aligned with iotivity?.

I assuming that we will be testing iotivity-upnp-bridge.



Thanks,

-Rick 



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, April 4, 2017 6:48 PM
To: Bell, Richard S ; 'Muhammad Mushfiqul Islam' 
; Nash, George 
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



Hi Rick, Thank you for your answer.



All release components should be aligned together regardless of repo separation.

I expect IoTivity QA team may not test these modules by themselves. But they 
need to verify whether these pass the reasonable criteria.

So communication with IoTivity QA is essential as of now.



Could you update the answer based on my reply?

BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, April 05, 2017 10:24 AM
To: ??? (Uze Choi); Muhammad Mushfiqul Islam; Nash, George
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



Uze,

Yes, I just got back this week from vacation?



Generic Java Binding   expected scope is merged into master? ? Yes

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

[Rick] Generic Java Binding is complete and has been checked into master of 
iotivity repository for some time.

There is separate build. Please see Generic Java Binding 
  wiki and I attached jira 
ticket?

Please contact George NSH on how do the testing.

?   Generic Java Binding  : 
(https://jira.iotivity.org/browse/IOT-1089, Bell, Richard S richard.s.bell at 
intel.com)

o   Generalize Java API from Android specific to general Java Platforms 
including J2SE.

o   Allows Java development on any OS (i.e. Linux, Windows, Android, IOS, and 
etc.) not limited to Android 



UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   



[Rick] UPnP Bridge is not in the iotivity repository. UPnP Bridge is in a 
separate repository iotivity-upnp-bridge.

I attached jira ticket?

? UPnP Bridge Updates ( 
 
https://jira.iotivity.org/browse/IOT-1995 Rick Bell,   richard.s.bell at intel.com):

o   OCF1.0 Bridge Device compatible.

o   Sample OCF Light. 

o   Adopt MPM Plugin for translation engine. 

o   Sync with UPnP Spec update (Data Model Review)

Our team had tested the UPnP Bridge for IoTIvity 1.2.0.

If the QA team is willing to take over testing., we can work with them.



Thanks,

-Rick Bell





From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 3, 2017 9:47 PM
To: Bell, Richard S 
Subject: RE: [dev] 1.3-release feature code completion check



Gently reminder.

I expect you are very busy after come back to office.

BR, Uze Choi

From: ??? (Uze Choi) [  
mailto:uzc...@samsung.com] 
Sent: Monday, April 03, 2017 11:14 AM
To: Bell, Richard S (  richard.s.bell at 
intel.com)
Subject: FW: [dev] 1.3-release feature code completion check



Hi Rick,



Regarding Generic Java bind, and UPnP update. May I recognize all they are in 
the master branch? Progress as 100%.

Did you discuss with QA lead how to test this feature? All TC are made?

Please check it and answer to me ASAP.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Saturday, April 01, 2017 12:19 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



Edited inline from implementation perspective of Introspection



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, March 31, 2017 1:13 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] 1.3-release feature code completion check



Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test 
perspective respectively.

Because there are lots of items in the release, Let me remove the feature with 
no responding in spite of requests.

* Example to answer. Introspection ?implementation: 100%, TC is 

[dev] 1.3-release feature code completion check

[최우제 (Uze Choi)]

Hi All,



This is summary from answer and so on.

More clear answer from each entity will help checking the status. 

This table is largely based on my assumption. Please correct if anything wrong.




Feature

Overall

Initial code

Update fix

TC ready

Test Executor

Contributor

Documentation


Introspection

90%

merged

Patch reviewing

Done

IoTivity QA

Srikrishna

No API


Versioning

80%

merged

payload separation 

checking

IoTivity QA

Ziran(?Habib)

No API


Endpoint 

100%

merged

N/A

Done

IoTivity QA

bg.chun

No API


Security update 

60%

In progress

-

Done

IoTivity QA

Nathan

not yet


MPM  

80%

merged

Checking

In progress

Todd

Todd

Wiki page


AllJoyn Bridge   

80%

merged

Checking

Done

Todd

Todd

not yet


UPnP Bridge

80%

merged

needs 1.3 compat.

Done

Rick

Rick

not yet


WiFi Easy-Setup update  

100%

merged

N/A

Done

IoTivity QA

Jihun

Wiki page


CoAP Native Cloud project

70%

In progress

-

Done

JK

JK

not yet


Generic Java Binding  

90%

merged

N/A

Done

IoTivity QA

Rick

not yet



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, March 31, 2017 5:13 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] 1.3-release feature code completion check



Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test 
perspective respectively.

Because there are lots of items in the release, Let me remove the feature with 
no responding in spite of requests.

* Example to answer. Introspection ?implementation: 100%, TC is made by 
IoTivity QA and 70% progress.



Introspection code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Versioning code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Endpoint  code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Security update  Feature is not merged yet, already we are communicating it. 
Let me tracking.



MPM   expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

AllJoyn Bridgeexpected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

WiFi Easy-Setup update   resource model update has been merged into master 
branch.

 Test is agreed with IoTivity QA lead? And progress for TC 
implementation from percentage view?

CoAP Native Cloud project (Resource Model Update, Web Socket)

 expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   

Generic Java Binding   expected scope is merged into master?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?



BR, Uze Choi (IoTivity Release Function Lead)

-- next part --
HTML ?? ??...
URL: 

[dev] 1.3-release feature code completion check

[최우제 (Uze Choi)]

Hi Rick, Thank you for your answer.



All release components should be aligned together regardless of repo separation.

I expect IoTivity QA team may not test these modules by themselves. But they 
need to verify whether these pass the reasonable criteria.

So communication with IoTivity QA is essential as of now.



Could you update the answer based on my reply?

BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, April 05, 2017 10:24 AM
To: ??? (Uze Choi); Muhammad Mushfiqul Islam; Nash, George
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



Uze,

Yes, I just got back this week from vacation?



Generic Java Binding   expected scope is merged into master? ? Yes

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

[Rick] Generic Java Binding is complete and has been checked into master of 
iotivity repository for some time.

There is separate build. Please see Generic Java Binding 
  wiki and I attached jira 
ticket?

Please contact George NSH on how do the testing.

?   Generic Java Binding  : 
(https://jira.iotivity.org/browse/IOT-1089, Bell, Richard S richard.s.bell at 
intel.com)

o   Generalize Java API from Android specific to general Java Platforms 
including J2SE.

o   Allows Java development on any OS (i.e. Linux, Windows, Android, IOS, and 
etc.) not limited to Android 



UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?   



[Rick] UPnP Bridge is not in the iotivity repository. UPnP Bridge is in a 
separate repository iotivity-upnp-bridge.

I attached jira ticket?

? UPnP Bridge Updates ( 
 
https://jira.iotivity.org/browse/IOT-1995 Rick Bell,   richard.s.bell at intel.com):

o   OCF1.0 Bridge Device compatible.

o   Sample OCF Light. 

o   Adopt MPM Plugin for translation engine. 

o   Sync with UPnP Spec update (Data Model Review)

Our team had tested the UPnP Bridge for IoTIvity 1.2.0.

If the QA team is willing to take over testing., we can work with them.



Thanks,

-Rick Bell





From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, April 3, 2017 9:47 PM
To: Bell, Richard S 
Subject: RE: [dev] 1.3-release feature code completion check



Gently reminder.

I expect you are very busy after come back to office.

BR, Uze Choi

From: ??? (Uze Choi) [  
mailto:uzc...@samsung.com] 
Sent: Monday, April 03, 2017 11:14 AM
To: Bell, Richard S (  richard.s.bell at 
intel.com)
Subject: FW: [dev] 1.3-release feature code completion check



Hi Rick,



Regarding Generic Java bind, and UPnP update. May I recognize all they are in 
the master branch? Progress as 100%.

Did you discuss with QA lead how to test this feature? All TC are made?

Please check it and answer to me ASAP.



BR, Uze Choi

From: Srikrishna Gurugubelli [mailto:srikg...@microsoft.com] 
Sent: Saturday, April 01, 2017 12:19 AM
To: ??? (Uze Choi); iotivity-dev at lists.iotivity.org
Subject: RE: [dev] 1.3-release feature code completion check



Edited inline from implementation perspective of Introspection



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Friday, March 31, 2017 1:13 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] 1.3-release feature code completion check



Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test 
perspective respectively.

Because there are lots of items in the release, Let me remove the feature with 
no responding in spite of requests.

* Example to answer. Introspection ?implementation: 100%, TC is made by 
IoTivity QA and 70% progress.



Introspection code merged into master.

any remaining fix item? Implement progress from percentage view?

Fixing IoT-1965 is in progress 
(https://gerrit.iotivity.org/gerrit/18397)  (80%)

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Versioning code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation from 
percentage view?

Endpoint  code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress 

[dev] Build environment update request

[최우제 (Uze Choi)]

Hi C.J



Build on Windows have an error as follows.

All changes are failed in build verification in vs2013, vs2015/

I suspect this is due to libCoAP version sync.



https://build.iotivity.org/ci/job/iotivity-verify-windows-
vs2015/12181/console 

16:46:12 *** Info:
*

16:46:12 * Your libCoAP repo is not up to date with the latest version we
require (IoTivity-1.2.1c).

16:46:12 * Please update using the following commands:

16:46:12 *   cd C:\j\workspace\iotivity-verify-windows-
vs2015\extlibs\libcoap\libcoap

16:46:12 *   git fetch && git checkout -f IoTivity-1.2.1c

16:46:12

***

16:46:12  
16:46:12 Build step 'Execute Windows batch command' marked build as failure



Dave, libCoAP version tag has been updated and applied into the code or
script? And only into Windows environment? 



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] 1.3-release feature code completion check

[최우제 (Uze Choi)]

Hi All feature contributor.



These are new feature list beyond existing feature from 1.2.x.

Let me check the progress of each item from percentage view.

Please answer the progress of each item from implementation and test
perspective respectively.

Because there are lots of items in the release, Let me remove the feature
with no responding in spite of requests.

* Example to answer. Introspection -implementation: 100%, TC is made by
IoTivity QA and 70% progress.



Introspection code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?

Versioning code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?

Endpoint  code merged into master.

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?   

Security update  Feature is not merged yet, already we are communicating
it. Let me tracking.



MPM   expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?   

AllJoyn Bridgeexpected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?   

UPnP Bridge Updates expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?   

WiFi Easy-Setup update   resource model update has been merged into master
branch.

 Test is agreed with IoTivity QA lead? And progress for
TC implementation from percentage view?

CoAP Native Cloud project (Resource Model Update, Web Socket)

 expected scope is merged into master?

any remaining fix item? Implement progress from percentage view?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?   

Generic Java Binding   expected scope is merged into master?

Test is agreed with IoTivity QA lead? And progress for TC implementation
from percentage view?



BR, Uze Choi (IoTivity Release Function Lead)

-- next part --
HTML ?? ??...
URL: 

[dev] [OCF oswg] RE: Request to postpone IoTivity 1.3-rel branch date from April 7th to April 17th

[최우제 (Uze Choi)]

Thank you Nathan and Mitch,



I know there are lots of missed part from release perspective.

>From today, let me check the readiness per feature.



Anyway, we cannot delay the branch out schedule at least for test start.

Considering security implementation progress and weighting from OCF spec.
perspective,

We can allow the feature implementation push after branch out.



BR, Uze Choi

From: oswg at openconnectivity.org [mailto:o...@openconnectivity.org] On
Behalf Of Mitch Kettrick
Sent: Friday, March 31, 2017 10:05 AM
To: 'Heldt-Sheller, Nathan'; iotivity-dev at lists.iotivity.org;
oswg at openconnectivity.org; security_os_tg at openconnectivity.org
Cc: '???(Uze Choi)'; '??? ?? OCF Sec'
Subject: [OCF oswg] RE: Request to postpone IoTivity 1.3-rel branch date
from April 7th to April 17th



Hi Nathan,



I don't think pushing this out one week will impact PF #12 too much.
Vendors will still have one week to integrate v1.3 if they choose.



I would rather have as many security CRs implemented in v1.3 than trying to
rush and miss out on some key features.  As Nathan said, so many of the
security CRs are related to and dependent on each other.  Trying to pull
out one or two of the CRs that Nathan is working on will potentially make
the whole thing fall apart.  Putting it back together will most likely
require normative spec changes that should be avoided when possible.



This is not my decision but I don't think Nathan's request sounds
unreasonable.



Mitch



From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] 
Sent: Thursday, March 30, 2017 4:51 PM
To: iotivity-dev at lists.iotivity.org; oswg at openconnectivity.org;
security_os_tg at openconnectivity.org
Cc: ???(Uze Choi) (uzchoi at samsung.com); Mitch Kettrick; ??? ?? OCF Sec
Subject: Request to postpone IoTivity 1.3-rel branch date from April 7th to
April 17th



Hello OSWG, IoTivity-dev and OSWG Security TG,



As many of you know, being a volunteer project, we?ve been short-handed on
developers, and struggling to find resources for several Security features.
I?ve been asking for months for additional help with a few features, but
being unable to find volunteers, I have picked up implementation of these
myself.



However just after returning from the Amsterdam F2F, I learned that one of
our key development resources was moving on to another job.  I?m not able
to pick up this slack, since I?m already overloaded.   And because of the
inter-dependent nature of these features, although myself and others have
tried, it has been infeasible to cut out any additional CRs from the
Security Spec? to do so would be more work than just implementing what we
have (not to mention significant normative CRs).



The good news is that just today I?ve gotten some temporary resource
commitment from inside Intel, to pick up these newly-ownerless tasks.
However I think because of the time lost over the past few weeks, and spin-
up required, it would greatly increase our odds of success to have another
week of development time before creating the 1.3-rel branch.  Moreover, at
the last OSWG Security TG meeting, I believe Dongik Lee mentioned that
their team would like a little more time (if possible) to implement a
couple additional items they?re working on.


TLDR; if there is not a hard-stop reason why we need to branch next Friday
April 7th, I propose we take an additional work-week (plus the weekend for
those of us who need to work through it) and create the 1.3-rel branch on
Monday April 17th.



Uze, I think the decision is yours ultimately, but I?m sending to the
entire list to gather feedback in case there are folks counting on this
April 7th date for a reason we?re not aware of.



Thanks,
Nathan Heldt-Sheller

OSWG Security TG Chair






  

Virus-free.   www.avg.com 



-- next part --
HTML ?? ??...
URL: 

[dev] [Iotivity-maintainers] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

Regarding security path, we need to listen from Security maintainer/sub 
maintainers.

Do we have a good reason separate security paths as below?
./resource/csdk/security/include/
./resource/csdk/security/provisioning/include/

Is it good place for C/C++ common header file?
./resource/csdk/include  (octypes only...)
How about to change it into ./resource/share/include or others?

Regarding out directory,
is it OK to put in into two folders ,prior to correcting the script to place 
all required header?
./include/c_common
 ./include/resource

BR, Uze Choi
-Original Message-
From: Daniel Mihai [mailto:daniel.mi...@microsoft.com] 
Sent: Tuesday, March 28, 2017 11:53 AM
To: ??? (Uze Choi); Dave Thaler; 'Mats Wichmann'; 'Nash, George'; 'Philippe 
Coval'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Iotivity-maintainers] C API docs: which Doxyfile?

I like the structure below. 

Not a big deal but: I would remove security/provisioning/include/oxm and 
security/provisioning/include/cloud and move their header files into 
security/provisioning/include. 

As you said, the Out directory seems to be missing useful headers. Hopefully we 
can change sometime the SConscript files for example apps to use just headers 
and LIBs from Out. For example, I have just looked at the way 
devicediscoveryclient.cpp is currently compiled: it has an undesirable mix of 
include paths from ./resource and from ./out.

Dan

-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com]
Sent: Monday, March 27, 2017 6:45 PM
To: Dave Thaler ; 'Mats Wichmann' ; Daniel Mihai ; 'Nash, George' 
; 'Philippe Coval' ; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Iotivity-maintainers] C API docs: which Doxyfile?

Only what we need to define is source directory structure and out directory 
header directory structure.
Let debug one by one.
This is initial proposal what should we change??

[IoTivity Source code]
C
 ./resource/c_common/include<-- new proposal...(merged into single 
directory..)
 ./resource/csdk/include  (octypes only...)  ./resource/csdk/stack/include  
./resource/csdk/security/include  ./resource/csdk/security/provisioning/include
 ./resource/csdk/security/provisioning/include/oxm
 ./resource/csdk/security/provisioning/include/cloud
 ./resource/csdk/routing/include
 ./resource/csdk/resource-directory/include

C++
 ./resource/include (All C++ header)
 ./resource/csdk/include  (octypes common to C API)

[Out directory]

C/C++ : lots of missing header file here...
 ./include/c_common
 ./include/resource  

BR, Uze Choi
-Original Message-
From: Dave Thaler [mailto:dtha...@microsoft.com]
Sent: Tuesday, March 28, 2017 3:03 AM
To: Mats Wichmann; Daniel Mihai; ??? (Uze Choi); 'Nash, George'; 'Philippe 
Coval'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Iotivity-maintainers] C API docs: which Doxyfile?

> From: Mats Wichmann
> So I'm guessing in the short term only the "installed location" 
> question can reasonably be addressed.  That is a single directory in 
> "out", but still split into a number of subdirs.  Is that "good 
> enough" or is there more work to be done?  Does anyone actually build against 
> the "out" tree?

Yes.

And I'm fine with Dan's recommendation.

Dave

[dev] [Iotivity-maintainers] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

Only what we need to define is source directory structure and out directory 
header directory structure.
Let debug one by one.
This is initial proposal what should we change??

[IoTivity Source code]
C
 ./resource/c_common/include<-- new proposal...(merged into single 
directory..)
 ./resource/csdk/include  (octypes only...)
 ./resource/csdk/stack/include
 ./resource/csdk/security/include
 ./resource/csdk/security/provisioning/include
 ./resource/csdk/security/provisioning/include/oxm
 ./resource/csdk/security/provisioning/include/cloud
 ./resource/csdk/routing/include
 ./resource/csdk/resource-directory/include

C++
 ./resource/include (All C++ header)
 ./resource/csdk/include  (octypes common to C API)

[Out directory]

C/C++ : lots of missing header file here...
 ./include/c_common
 ./include/resource  

BR, Uze Choi
-Original Message-
From: Dave Thaler [mailto:dtha...@microsoft.com] 
Sent: Tuesday, March 28, 2017 3:03 AM
To: Mats Wichmann; Daniel Mihai; ??? (Uze Choi); 'Nash, George'; 'Philippe 
Coval'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Iotivity-maintainers] C API docs: which Doxyfile?

> From: Mats Wichmann
> So I'm guessing in the short term only the "installed location" 
> question can reasonably be addressed.  That is a single directory in 
> "out", but still split into a number of subdirs.  Is that "good 
> enough" or is there more work to be done?  Does anyone actually build against 
> the "out" tree?

Yes.

And I'm fine with Dan's recommendation.

Dave

[dev] [Iotivity-maintainers] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

Good point, Dan.

One simple question from the path issue.
Do you comment on installed header path or development source itself?
Developer perspective this well organized path is important but this is 
installed header view point.

BR, Uze Choi
-Original Message-
From: Daniel Mihai [mailto:daniel.mi...@microsoft.com] 
Sent: Saturday, March 25, 2017 9:48 AM
To: ??? (Uze Choi); 'Nash, George'; 'Philippe Coval'; iotivity-dev at 
lists.iotivity.org
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I corrected my "undesirable stdlib path" example path below:

-Original Message-
From: Daniel Mihai
Sent: Friday, March 24, 2017 2:12 PM
To: '??? (Uze Choi)' ; 'Nash, George' ; 'Philippe Coval' ; iotivity-dev 
at lists.iotivity.org
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

This is not a big deal but my opinion is that having a single header file for 
each directory under c_common is an inefficient use of directories. 

I look at c_common as similar to "the IoTivity CRT". I believe that a typical 
CRT has malloc.h and stdlib.h in a single directory. There is no: 

/malloc/include/malloc.h or /stdlib/include/stdlib.h 

and programmers don't have to remember such different paths. Similarly, I think 
oic_malloc.h and oic_string.h should live in a single common/include (assuming 
that both of these headers are intended to be Public).

Dan

-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com]
Sent: Thursday, March 23, 2017 10:03 PM
To: Daniel Mihai ; 'Nash, George' ; 'Philippe Coval' ; 
iotivity-dev at lists.iotivity.org
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

First of all,
resource/c_common/include for all headers under the resource/c_common is 
acceptable idea?
Any issue from here or good technic?
BR, Uze Choi
-Original Message-
From: Daniel Mihai [mailto:daniel.mi...@microsoft.com]
Sent: Friday, March 24, 2017 12:02 AM
To: ??? (Uze Choi); 'Nash, George'; 'Philippe Coval'; iotivity-maintainers at 
lists.iotivity
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I agree with Uze. (I thought that was already the proposal we were discussing)

Dan

-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com]
Sent: Thursday, March 23, 2017 3:50 AM
To: Daniel Mihai ; 'Nash, George' ; 'Philippe Coval' ; 
iotivity-maintainers at lists.iotivity
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

Let me continue the directory restructuring for header file.

Merging all header file into single directory looks not feasible because of 
separate sub project from iotivity internally.
How about placing them into some sets of directory normalized feature level 
unit such as common, security, resource-directory, routing, connectivity, 
include(base).
This can lead simpler structure also. 

BR, Uze Choi
-Original Message-
From: iotivity-maintainers-bounces at lists.iotivity.org 
[mailto:iotivity-maintainers-boun...@lists.iotivity.org] On Behalf Of Daniel 
Mihai via Iotivity-maintainers
Sent: Saturday, March 18, 2017 3:48 AM
To: Nash, George; Philippe Coval; iotivity-maintainers at lists.iotivity.org
Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I like the proposals so far. 

Here are my current thoughts:

1. We should move the non-Public resource/c_common header files into 
resource/c_common/src. 
2. For Public resource/c_common header files: no need for 
./resource/c_common/include/iotivity/oic_malloc or 
./resource/c_common/include/iotivity/oic_string. Instead of those two separate 
paths, we should use a single ./resource/c_common/include/iotivity.

Dan

-Original Message-
From: iotivity-maintainers-bounces at lists.iotivity.org 
[mailto:iotivity-maintainers-boun...@lists.iotivity.org] On Behalf Of Nash, 
George
Sent: Friday, March 17, 2017 11:17 AM
To: Philippe Coval ; iotivity-maintainers at 
lists.iotivity.org
Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I personally like the idea of having everything in an iotivity namespace. Not 
sure I like the idea of having the `resource` be part of the path.

In my opinion the best solution would be a slight re-organization of the 
headers. I would reverse the folder structure instead of /include it 
should be include/iotivity/

Example:
./resource/c_common/octhread/include -> 
./resource/c_common/include/iotivity/octhread
./resource/c_common/oic_malloc/include -> 
./resource/c_common/include/iotivity/octhread
./resource/c_common/oic_time/include -> 
./resource/c_common/include/iotivity/oic_time
./resource/c_common/oic_string/include -> ./resource/c_common/include/ 
iotivity/oic_string ./resource/c_common/windows/include -> 
./resource/c_common/include/ iotivity/windows 
./resource/c_common/ocrandom/include -> ./resource/c_common/include/ 
iotivity/ocrandom

This would reorganize the structure so the CPPPATH would be the locations 
CPPPATH= 

[dev] IoTivity documentation standards

[최우제 (Uze Choi)]

Hi JiHwan,

I think this is good feature to users.
Then should we open all functions to user or hide something to user?
I found Java JNI specific around 10 APIs there. Can we separate split them?
Furthermore, we should open cacommon.h file for data type used in 
cautilinterface.h.

BR, Uze Choi

From: JiHwan Seo [mailto:jihwan@samsung.com] 
Sent: Friday, March 24, 2017 3:55 PM
To: Mats Wichmann; Uze Choi; ASHOKBABU CHANNA; 'Nash, George'; 'C.J. Collier'
Cc: 'IoTivity Developer List'
Subject: RE: Re: [dev] IoTivity documentation standards



Hi Uze and Mats.



Since there were so many requirements to handle CA layer in person.

I believe that this header can be helpped for lots of scenarios.

please refer below the patchset

https://gerrit.iotivity.org/gerrit/#/c/18157/ 



BR

Jihwan

- Original Message -

Sender : Mats Wichmann 

Date : 2017-03-23 23:56 (GMT+9)

Title : Re: [dev] IoTivity documentation standards



On 03/23/2017 08:24 AM, ??? wrote:
> Thanks Ashok.
> Then cautilinterface.h also has lots of functions.
> All are required open?


This header has no @file section, is there a description of the purpose
of the header available?



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev










-- next part --
HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?? ?? .
URL: 

[dev] [Iotivity-maintainers] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

First of all, 
resource/c_common/include for all headers under the resource/c_common is 
acceptable idea?
Any issue from here or good technic?
BR, Uze Choi
-Original Message-
From: Daniel Mihai [mailto:daniel.mi...@microsoft.com] 
Sent: Friday, March 24, 2017 12:02 AM
To: ??? (Uze Choi); 'Nash, George'; 'Philippe Coval'; iotivity-maintainers at 
lists.iotivity
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I agree with Uze. (I thought that was already the proposal we were discussing)

Dan

-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Thursday, March 23, 2017 3:50 AM
To: Daniel Mihai ; 'Nash, George' ; 'Philippe Coval' ; 
iotivity-maintainers at lists.iotivity
Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

Let me continue the directory restructuring for header file.

Merging all header file into single directory looks not feasible because of 
separate sub project from iotivity internally.
How about placing them into some sets of directory normalized feature level 
unit such as common, security, resource-directory, routing, connectivity, 
include(base).
This can lead simpler structure also. 

BR, Uze Choi
-Original Message-
From: iotivity-maintainers-bounces at lists.iotivity.org 
[mailto:iotivity-maintainers-boun...@lists.iotivity.org] On Behalf Of Daniel 
Mihai via Iotivity-maintainers
Sent: Saturday, March 18, 2017 3:48 AM
To: Nash, George; Philippe Coval; iotivity-maintainers at lists.iotivity.org
Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I like the proposals so far. 

Here are my current thoughts:

1. We should move the non-Public resource/c_common header files into 
resource/c_common/src. 
2. For Public resource/c_common header files: no need for 
./resource/c_common/include/iotivity/oic_malloc or 
./resource/c_common/include/iotivity/oic_string. Instead of those two separate 
paths, we should use a single ./resource/c_common/include/iotivity.

Dan

-Original Message-
From: iotivity-maintainers-bounces at lists.iotivity.org 
[mailto:iotivity-maintainers-boun...@lists.iotivity.org] On Behalf Of Nash, 
George
Sent: Friday, March 17, 2017 11:17 AM
To: Philippe Coval ; iotivity-maintainers at 
lists.iotivity.org
Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?

I personally like the idea of having everything in an iotivity namespace. Not 
sure I like the idea of having the `resource` be part of the path.

In my opinion the best solution would be a slight re-organization of the 
headers. I would reverse the folder structure instead of /include it 
should be include/iotivity/

Example:
./resource/c_common/octhread/include -> 
./resource/c_common/include/iotivity/octhread
./resource/c_common/oic_malloc/include -> 
./resource/c_common/include/iotivity/octhread
./resource/c_common/oic_time/include -> 
./resource/c_common/include/iotivity/oic_time
./resource/c_common/oic_string/include -> ./resource/c_common/include/ 
iotivity/oic_string ./resource/c_common/windows/include -> 
./resource/c_common/include/ iotivity/windows 
./resource/c_common/ocrandom/include -> ./resource/c_common/include/ 
iotivity/ocrandom

This would reorganize the structure so the CPPPATH would be the locations 
CPPPATH= [?#/resource/c_common/include?, ?#/resource/csdk/include?, 
?#resource/include?]

In the code the #include could use the path style inclusion. (if for some 
reason we don?t want to use path style inclusion we could still put the full 
path in the CPPPATH)

i.e.
#include 
#include 
#include 

All iotivity headers would start with `iotivity/` a lot of other projects have 
done a similar approach.

This simple organization change helps but it does not tell which are intended 
for general public use and which are internal to the project itself.

The AllJoyn project solved the public header issue in a simple way. If the 
header was in the include directory it was public. Anything not public was 
placed in the src directory. IoTivity already does something similar to this 
using the `include/internal` directory to indicate headers that are not public. 
Maybe we just need to do a check to make sure all intern headers end up in an 
internal directory.

In addition would also suggest all include directories be named 'include' none 
should be named 'inc'.  The naming is currently inconsistent across the entire 
code base.

George

-Original Message-
From: iotivity-maintainers-bounces at lists.iotivity.org 
[mailto:iotivity-maintainers-boun...@lists.iotivity.org] On Behalf Of Philippe 
Coval
Sent: Friday, March 17, 2017 4:58 AM
To: iotivity-maintainers at lists.iotivity.org
Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile?


On 17/03/17 12:36, Ashok Babu Channa wrote:
> Move all header files under csdk/include makes appropriate from my opinion.
>
> resource/include - C++ API
> resource/csdk/include- CAPI.
>
> Regards,ok

Sounds good, may I suggest 

[dev] Should IoTivity Arduino support be dropped?

[최우제 (Uze Choi)]

Our discussion was as follows in F2F meeting in AMS.



The release perspective, Arduino/iOS(MacOS) are not tested. But Jenkins 
perspective Arduino/iOS(MacOS) builds are verified.

If there is any issue in these platform build (especially Arduino), remove this 
build from Jenkins verification.

Otherwise keep it until iotivity-constraint to be released in public for 
Arduino case.

We are still open for iOS build submaintainer.



BR ,Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Dave Thaler via 
iotivity-dev
Sent: Thursday, March 23, 2017 1:24 PM
To: Thiago Moura; Thiago Macieira
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Should IoTivity Arduino support be dropped?



It was never certifiable before, and not fully working either (e.g., security 
never worked), so any jenkins CI ?testing? just slows down the builds for 
everything else without any real value.

We just don?t want to destabilize the source until after 1.3 releases and then 
we can do clean up.



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Moura
Sent: Wednesday, March 22, 2017 8:40 PM
To: Thiago Macieira 
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Should IoTivity Arduino support be dropped?



> but such cleaning patches should wait until after 1.3 is released.



> And yes the helpdesk ticket is still waiting for action from CJ.


I am not sure if I follow the plan.. Arduino is still part of the 1.3 release 
but isn't going to be tested anymore?



On Wed, Mar 22, 2017 at 11:23 PM, Thiago Macieira  wrote:

On quarta-feira, 22 de mar?o de 2017 09:47:48 PDT Thiago Moura wrote:
> Well, it's been awhile and no decision on this topic.

The decision was made after discussion on the mailing list: Arduino support is
being removed from the IoTivity Standard. If anyone wants to revive it,
they're welcome to do so in Constrained.

> I am very curious if anyone here is developing real products based on
> arduino (due/mega).

Intel's research shows no one develops products with Arduino. They use it for
early proof-of-concepts, then throw everything away and rewrite the code (no
code reuse) when going to actual product prototypes.

At most, Arduino gets used by hobbyists for one-off implementations in their
own homes. So it's worthwhile to make it work, but not at the expense of real
products.

> Back to the subject.. I think dropping support for Arduino will benefit
> everyone - Increase maintainability(code and build system cleanup), faster
> CI and less headaches for project managers. I've found this
> opened/unresolved tickets on Jira, most of them pending for more than 1

I agree.


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center







-- 

Thiago Guedes Cunha de Moura
Graduando em Ci?ncia da Computa??o
Instituto de Ci?ncias Exatas e Biol?gicas - Universidade Federal de Ouro Preto

cel.: (31)99484-9864

-- next part --
HTML ?? ??...
URL: 

[dev] Jira usage and Jira update

[최우제 (Uze Choi)]

Let me propose Mandating ?fix version? field.

BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Dwarkaprasad 
Dayama
Sent: Thursday, March 23, 2017 7:35 PM
To: 'Christian Gran'; 'Thiago Moura'; 'Mats Wichmann'; iotivity-dev at 
lists.iotivity.org
Subject: Re: [dev] Jira usage and Jira update



Hi Christian,



Good to see the progress.



Let us also remove OIC field and keep only Bugzilla field with proper rules on 
how to use it. This will help to cross link IoTivity JIRA & OCF Bugzilla. What 
you say?



Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation ? Open Source WG Vice-Chair

Open Connectivity Foundation ? Spec Coordination TG Chair

Iotivity Steering Group ? Advisory Committee



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Christian Gran
Sent: Thursday, March 23, 2017 7:27 PM
To: Thiago Moura ; Mats Wichmann ; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Jira usage and Jira update



Hi, 



thanks for the good feedback :-)

I have updated the Wiki pages accordingly:

https://wiki.iotivity.org/jira_proposed_changes

https://wiki.iotivity.org/jira_how_to_use



Summary of the updates based on the feedback received:

*   remove the EXAMPLE project
*   use Jira for IoTivity-constrained, either as a component or own project
*   create a new project for IoTivity-Node? 
*   for remote access keep component, but close old tickets
*   rename install/uninstall to build
*   remove OS field or simplify it to major OS to simplify ticket creation
*   remove Transport field
*   remove SDK/Services field
*   remove Operating System field
*   remove Operating System Type
*   remove Processor/Architecture field
*   -> the idea is to remove couple of fields that are for most tickets not 
relevant at all. The information - if needed - could be captured in the 
Description field. This seems to be much better then to create tickets where 
all these values are untouched and are used with their default values - which 
just means that there is false information kept there.



Link between Jira and Gerrit:

For linking between Jira and Gerrit added the proposal to the ?how to use Jira 
page?:

?When committing code to Gerrit, that is related to a Jira ticket, then provide 
a link to the ticket with the commit."





One general question about projects vs components in Jira:

How do you feel about multiple projects in Jira (like IoTivity, 
IoTivity-constrained, IoTivity-Node) ?

Do you want to use different projects in Jira as well - or do you just want to 
use one project (IoTivity) and use the component field 

for the information that this is IoTivity-constrained or Node related?

Opinions?



?more feedback?



thanks

  Christian





On 23 Mar 2017, at 04:59, Thiago Moura  wrote:



Great Christian! 


I'd also suggest: 

* Remove that EXAMPLE project



* Make use of the Constrained Framework project (should't be renamed to 
IoTivity-constrained ?)

  -> Lot's of things happening on gerrit but nothing on Jira



* Move Node.js bindings component to a new IoTivity-Node project

  -> Btw, Isn't it an official iotivity project?.. Can't find it on 
https://wiki.iotivity.org/projects_and_functions



+1 for scrum board



On Wed, Mar 22, 2017 at 10:26 AM, Mats Wichmann  wrote:

On 03/22/2017 04:04 AM, Christian Gran wrote:
> Hi,
>
> as "Planning Function Lead? for IoTivity started to look a bit in how we use 
> Jira :-)
>
> In my opinion we could do a few changes here and there and we would also 
> benefit if we would update to the latest version.
> This would make the overall planning process for IoTivity a much easier :-)
>
> I have created two Wiki pages - one for proposed changes to Jira and one with 
> proposals how we could use Jira.
> https://wiki.iotivity.org/jira_proposed_changes
> https://wiki.iotivity.org/jira_how_to_use
>
> My proposal is also to use the Scrum Board, which seems to be included in the 
> latest version:
> https://www.atlassian.com/software/jira/agile#scrum
> With the Scrum board we could much better prioritize tickets and group these 
> into Sprints to plan for a release.
>
> Any thoughts on this?

A couple of things on our Jira,

I understand the need to gather complete information to diagnose a
problem (I have been a developer responding to bug tickets for many many
years), but it just feels like there are too many fields where an active
choice is required - it makes reporting cumbersome.  e.g. if while
looking in the source code I find a problem which needs reporting, it's
a pain if I have to pick between 32/64 bit; and from this viewpoint
operating system has different granularity than from a binary viewpoint
- code could be 

[dev] IoTivity documentation standards

[최우제 (Uze Choi)]

Hi Ashok,

Can you check the connectivity/api list once more?

AFAIK, Originally, this api folder was not intended to App/Service developer.

But some APIs are useful to both to IoTivity intenal developer and app 
developer, they are opened.

We can consider header separation for these special APIs.

BR, Uze Choi

From: Nash, George [mailto:george.n...@intel.com] 
Sent: Thursday, March 23, 2017 12:55 AM
To: uzchoi at samsung.com; 'C.J. Collier'; 'Mats Wichmann'
Cc: 'IoTivity Developer List'
Subject: RE: [dev] IoTivity documentation standards



Thanks Uze for taking the time to help figure out which header files are 
intended for the public API:



It looks like a few of the headers from your list differ from the list that was 
in my recent commit https://gerrit.iotivity.org/gerrit/#/c/17991/



The current commit contains all header files in ../../csdk/connectivity/api/



i.e.

../../csdk/connectivity/api/cacommon.h (not in list)

../../csdk/connectivity/api/cainterface.h (not in list)

../../csdk/connectivity/api/casecurityinterface.h (not in list)

../../csdk/connectivity/api/cautilinterface.h (in list)



It does not contain the header files in ../../csdk/security/include/internal





Let me know if I should update the list of INPUT files for the Doxyfile.



George

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, March 21, 2017 8:29 PM
To: Nash, George ; 'C.J. Collier' ; 'Mats Wichmann' 
Cc: 'IoTivity Developer List' 
Subject: RE: [dev] IoTivity documentation standards



I am happy to see meaningful  discussion happen so I can expect improvement the 
doxygen documentation.

Step by step, Let?s focus on the External C API first, C++ and Java in sequence.

Think about the internal API as next step.



Let me suggest document enhancement task as several steps.

0. We can consider to relocate the header file into appropriate folder.

1. filter out which is not intended public API from the header file.

2. fill in the context for function and parameter description on the missed API.

3. review and fix the explanation from sample application view.

Even though description is filled with guided way, we are not make sure 
explanation is enough to understand.



   ../../csdk/stack/include/ocstack.h

../../csdk/stack/include/octypes.h

../../csdk/stack/include/ocpayload.h

../../csdk/stack/include/ocpresence.h

 ../../csdk/stack/include/payload_logging.h

../../csdk/stack/include/ocstackconfig.h

../../csdk/connectivity/api/cautilinterface.h



 ../../csdk/security/include

 ../../csdk/security/include/internal(This need to be checked 
again from Randeep)

../../csdk/security/provisioning/include



../../csdk/resource-diretory/include

../../csdk/routing/include



../../c_common/ocrandom/include/ocrandom.h \

 ../../c_common/oic_malloc/include/oic_malloc.h \

 ../../c_common/oic_string/include/oic_string.h \

 ../../c_common/oic_time/include/oic_time.h \



 ../../service/easy-setup/inc \

 ../../service/easy-setup/enrollee/inc \

 ../../service/notification/include \

 ../../service/coap-http-proxy/include \



Regarding Mat question, [in] [out] should be mandatory only in the C API, not 
C++, Java.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Nash, George
Sent: Tuesday, March 21, 2017 7:11 AM
To: C.J. Collier; Mats Wichmann
Cc: IoTivity Developer List
Subject: Re: [dev] IoTivity documentation standards



Mats,



I am glad that you have brought up some of these issues. I disagree that the 
efficient doxygen comments page sounds mandatory. However, all of the 
suggestions probably are best to be followed.



(a)Based on recent commits that I have made. There is definitely a strong 
desire to use the [in], [out] markup.  It would probably be wise to add it to 
the wiki page.

(b)   There is no convention that I know of.  This is an area that could be 
improved.

(c)There is a huge advantage of having the documentation in the headers vs. 
the source files. The header is the only part that is readable by developers in 
the distributed sdk. By putting the documentation in the header we are helping 
developers that use the code. I think using the headers is the correct choice.

(d)   I have not actually seen this be an issue. Doxygen cannot apply the 
documentation to anything so it does not end up in the output. I don?t know if 
this was being over cautious or if it is a real problem. I personally have not 
seen it in the output.

(e)   There is some discussion for public vs. private APIs. Unfortunately the 
discussion somehow got moved over to the maintainers email list (much smaller 
group that has +2 permission in gerrit.) not the iotivity-dev email list.  I 
have already done some cleanup for the 

[dev] Jira registration "Fix version" field.

[최우제 (Uze Choi)]

If issue is to be fixed in this release, please set Fix Version/s as
?IoTivity 1.3.0? which has been newly created.

This will help to track the defect status.

Moreover, during Release triage there will be another chance to exclude the
issue out of 1.3.0 release scope.

BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [QA plan request for new feature] RE: [Request Again]: Request on IoTivity 1.3 release items.

[최우제 (Uze Choi)]

Hi Antu(IoTivity QA lead),
Can you share the test plan for each newly added item.
If they are not agreed before QA start, it will be better to exclude items from 
release scope.
BR, Uze Choi
-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, March 20, 2017 7:18 PM
To: 'Malsbary, Todd'; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] [Request Again]: Request on IoTivity 1.3 release items.

Todd,
Please add jira ticket id/link into wiki. 
https://wiki.iotivity.org/1.3_release_plan
BR, Uze Choi
-Original Message-
From: Malsbary, Todd [mailto:todd.malsb...@intel.com]
Sent: Saturday, March 18, 2017 6:36 AM
To: iotivity-dev at lists.iotivity.org; uzchoi at samsung.com
Subject: Re: [dev] [Request Again]: Request on IoTivity 1.3 release items.

Hi Uze,

I updated the wiki for the AllJoyn Bridge and reached out to Antu.  I'm also 
following up on MPM.

-Todd

On Fri, 2017-03-17 at 13:26 +0900, ??? (Uze Choi) wrote:
> Greeting,
>  
> [Jira Registration/Tagging into wiki]
> Rick, Todd, Vijay, JeeHyeok,
> MPM, AllJoyn Bridge, Cloud update and UPnP Bridge update are not done 
> yet.
> Please create the jira ticket and update the context into wiki.
>  
> [Test case/execution Plan]
> Nathan, Rick, Todd, Vijay, JeeHyeok,
> Please communicate with IoTivity QA ASAP.
>  
> BR, Uze Choi
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo 
> unces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
> Sent: Thursday, March 16, 2017 5:51 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] Request on IoTivity 1.3 release items.
>  
> Hi, Feature contributors in 1.3 release.
>  
> Please check as below. and respond by this week.
>  
> [Jira Registration/Tagging into wiki]
> Please add Jira tick link on https://wiki.iotivity.org/1.3_release_pl
> an. as like security related item.
> Introspection, Versioning, Endpoint
> MPM, AllJoyn Bridge, UPnP Bridge
> CoAP Native Cloud Project items.
> Generic Java Binding.
> [Test case/execution Plan]
>For each development item, discuss with IoTivity QA(Antu @samsung.com>) how to test your module.
> Finally, IoTivity QA should confirm the Test Plan.
>  
> BR, Uze Choi
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo 
> unces at lists.iotivity.org] On Behalf Of Christian Gran
> Sent: Monday, February 20, 2017 9:08 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb
>  
> Hi,
>  
> for the release process of IOTivity 1.3 the next milestone is the 
> feature freeze at 24th of Feb.
> Please provide your input which features you will have ready by that 
> time and update the wiki page 
> https://wiki.iotivity.org/1.3_release_plan a ccordingly.
> Please send me a short note when you are done with the updates for 
> your module.
>  
> thanks
>   Christian
>  
>  
> ___
> 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

[dev] IoTivity documentation standards

[최우제 (Uze Choi)]

I am happy to see meaningful  discussion happen so I can expect improvement the 
doxygen documentation.

Step by step, Let?s focus on the External C API first, C++ and Java in sequence.

Think about the internal API as next step.



Let me suggest document enhancement task as several steps.

0. We can consider to relocate the header file into appropriate folder.

1. filter out which is not intended public API from the header file.

2. fill in the context for function and parameter description on the missed API.

3. review and fix the explanation from sample application view.

Even though description is filled with guided way, we are not make sure 
explanation is enough to understand.



   ../../csdk/stack/include/ocstack.h

../../csdk/stack/include/octypes.h

../../csdk/stack/include/ocpayload.h

../../csdk/stack/include/ocpresence.h

 ../../csdk/stack/include/payload_logging.h

../../csdk/stack/include/ocstackconfig.h

../../csdk/connectivity/api/cautilinterface.h

 ../../csdk/security/include

 ../../csdk/security/include/internal(This need to be checked 
again from Randeep)

../../csdk/security/provisioning/include



../../csdk/resource-diretory/include

../../csdk/routing/include



../../c_common/ocrandom/include/ocrandom.h \

 ../../c_common/oic_malloc/include/oic_malloc.h \

 ../../c_common/oic_string/include/oic_string.h \

 ../../c_common/oic_time/include/oic_time.h \



 ../../service/easy-setup/inc \

 ../../service/easy-setup/enrollee/inc \

 ../../service/notification/include \

 ../../service/coap-http-proxy/include \



Regarding Mat question, [in] [out] should be mandatory only in the C API, not 
C++, Java.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Nash, George
Sent: Tuesday, March 21, 2017 7:11 AM
To: C.J. Collier; Mats Wichmann
Cc: IoTivity Developer List
Subject: Re: [dev] IoTivity documentation standards



Mats,



I am glad that you have brought up some of these issues. I disagree that the 
efficient doxygen comments page sounds mandatory. However, all of the 
suggestions probably are best to be followed.



(a)Based on recent commits that I have made. There is definitely a strong 
desire to use the [in], [out] markup.  It would probably be wise to add it to 
the wiki page.

(b)   There is no convention that I know of.  This is an area that could be 
improved.

(c)There is a huge advantage of having the documentation in the headers vs. 
the source files. The header is the only part that is readable by developers in 
the distributed sdk. By putting the documentation in the header we are helping 
developers that use the code. I think using the headers is the correct choice.

(d)   I have not actually seen this be an issue. Doxygen cannot apply the 
documentation to anything so it does not end up in the output. I don?t know if 
this was being over cautious or if it is a real problem. I personally have not 
seen it in the output.

(e)   There is some discussion for public vs. private APIs. Unfortunately the 
discussion somehow got moved over to the maintainers email list (much smaller 
group that has +2 permission in gerrit.) not the iotivity-dev email list.  I 
have already done some cleanup for the csdk. This is still a work in progress. 



See: https://gerrit.iotivity.org/gerrit/#/c/17991/ (public API headers), 
https://gerrit.iotivity.org/gerrit/#/c/17923/ (All headers/code including 
internal only)



Also please don?t use the @internal doxygen tag it does not do what you think 
it does. All it does it hide the documentation not the class, function, or 
variable. It is better to use @cond  @endcond.  It would good if all the 
internal documentation used the same tag so it could be included in the 
internal only documentation.



I think the top suggestion for all documentation should be ?check the output? 
till you actually read the output generated by doxygen you cannot be sure it is 
doing what you think it is doing. I have had to make some major changes to 
documentation because it simply was not doing what the developer thought it was 
doing.



I would love to add a doxygen build that would fail if you produce any doxygen 
warnings but that could be a large task.



George 





From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of C.J. Collier
Sent: Monday, March 20, 2017 1:50 PM
To: Mats Wichmann 
Cc: IoTivity Developer List 
Subject: Re: [dev] IoTivity documentation standards



Hello Mats,



Having not participated in the documentation of the API to date, I am certainly 
not an authority on the matter.  But I'll give my two cents anyway!



First, the questions regarding wiki page contents might be best directed to Jon 
A. 

[dev] Jenkins Build verification error notification.

[최우제 (Uze Choi)]

Hi All,

Currently, there are some unit test build error from the Jenkins build.

They are from the notification service but it does not happen always.

Temporarily unit test execution in notification service is commented out,
the latest code after https://gerrit.iotivity.org/gerrit/#/c/18077/ will
work correctly.

Poovizhi Avudai, please check notification unit test case error below.

BR, Uze Choi



https://gerrit.iotivity.org/gerrit/#/c/18067/

https://build.iotivity.org/ci/job/iotivity-verify-unit_tests/11563/

23:02:18 service/notification/cpp-
wrapper/unittest/NSProviderServiceTest.cpp:253: Failure
23:02:18 Value of: msgID
23:02:18   Actual: 1931169840
23:02:18 Expected: expectedMsgId
23:02:18 Which is: 2
23:02:18 [  FAILED  ]
NotificationProviderServiceTest.ExpectCallNotifyOnConsumerByAcceptIsTrue
(1000 ms)





https://gerrit.iotivity.org/gerrit/#/c/18069/

https://build.iotivity.org/ci/job/iotivity-verify-unit_tests/11564/console

23:11:59 [ RUN  ]
NotificationProviderTest.ExpectCallbackSubscribeRequestWithAccepterProvider
23:12:00 [   OK ] NotifyAllObserverTest.NotifyAllObservers (2061 ms)
23:12:00 [ RUN  ] NotifyAllObserverTest.NotifyAllObserversWithLowQos
23:12:00 Segmentation fault (core dumped)
23:12:00 scons: ***
[out/linux/x86_64/debug/service/notification/unittest/utservice/notification
/unittest/notification_provider_test] Error 139



https://gerrit.iotivity.org/gerrit/#/c/17991/

https://build.iotivity.org/ci/job/iotivity-verify-unit_tests/11524/console

10:33:29 service/notification/cpp-
wrapper/unittest/NSProviderServiceTest.cpp:253: Failure
10:33:29 Value of: msgID
10:33:29   Actual: 1886240427
10:33:29 Expected: expectedMsgId
10:33:29 Which is: 2
10:33:29 [  FAILED  ]
NotificationProviderServiceTest.ExpectCallNotifyOnConsumerByAcceptIsTrue
(1001 ms)





-- next part --
HTML ?? ??...
URL: 

[dev] please let's not change file modes carelessly

[최우제 (Uze Choi)]

Hi C.J.
Could you make a script to check it and trigger whenever commit happen?
BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Stefan Schmidt
Sent: Thursday, March 16, 2017 4:28 PM
To: Mats Wichmann; IoTivity Developer List
Subject: Re: [dev] please let's not change file modes carelessly

Hello.

On 03/16/2017 12:43 AM, Mats Wichmann wrote:
>
> A pull on master just now shows:
>
>  mode change 100644 => 100755 build_common/SConscript  mode change 
> 100644 => 100755 build_common/tizen/SConscript  mode change 100644 => 
> 100755 
> resource/csdk/connectivity/build/tizen/packaging/com.oic.ca.spec
>  mode change 100644 => 100755
> resource/csdk/connectivity/build/tizen/scons/SConscript
>  mode change 100644 => 100755
> resource/csdk/connectivity/src/camessagehandler.c
>  mode change 100644 => 100755 resource/csdk/logger/SConscript  mode 
> change 100644 => 100755 
> resource/csdk/stack/samples/tizen/build/scons/SConscript
>  mode change 100644 => 100755 resource/csdk/stack/src/occlientcb.c
>  mode change 100644 => 100755 resource/csdk/stack/src/ocstack.c  mode 
> change 100644 => 100755 tools/tizen/iotivity.spec
>
> None of these files should be mode 755. Do why know why they changed? 
> I can't seem to get git to tell me what the change was, not smart enough.

In all cases I have seen this over the years the culprit have always been
that the files have been created or changed on a Windows machine and git
just kept the file modes when pushing (directly or to gerrit)

> There are now 536 non-directory files with "execute permission" in the 
> tree, while only a very small number should have it (*.sh, *.bat, 
> etc.)

Sounds like this needs a quick script magic run to fix the existing ones
and more attention during review for the future. :) Or a git hook enforcing
it if you want to go that way.

regards
Stefan Schmidt


___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] [Request Again]: Request on IoTivity 1.3 release items.

[최우제 (Uze Choi)]

Todd,
Please add jira ticket id/link into wiki. 
https://wiki.iotivity.org/1.3_release_plan 
BR, Uze Choi
-Original Message-
From: Malsbary, Todd [mailto:todd.malsb...@intel.com] 
Sent: Saturday, March 18, 2017 6:36 AM
To: iotivity-dev at lists.iotivity.org; uzchoi at samsung.com
Subject: Re: [dev] [Request Again]: Request on IoTivity 1.3 release items.

Hi Uze,

I updated the wiki for the AllJoyn Bridge and reached out to Antu.  I'm also 
following up on MPM.

-Todd

On Fri, 2017-03-17 at 13:26 +0900, ??? (Uze Choi) wrote:
> Greeting,
>  
> [Jira Registration/Tagging into wiki]
> Rick, Todd, Vijay, JeeHyeok,
> MPM, AllJoyn Bridge, Cloud update and UPnP Bridge update are not done 
> yet.
> Please create the jira ticket and update the context into wiki.
>  
> [Test case/execution Plan]
> Nathan, Rick, Todd, Vijay, JeeHyeok,
> Please communicate with IoTivity QA ASAP.
>  
> BR, Uze Choi
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo 
> unces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
> Sent: Thursday, March 16, 2017 5:51 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] Request on IoTivity 1.3 release items.
>  
> Hi, Feature contributors in 1.3 release.
>  
> Please check as below. and respond by this week.
>  
> [Jira Registration/Tagging into wiki]
> Please add Jira tick link on https://wiki.iotivity.org/1.3_release_pl
> an. as like security related item.
> Introspection, Versioning, Endpoint
> MPM, AllJoyn Bridge, UPnP Bridge
> CoAP Native Cloud Project items.
> Generic Java Binding.
> [Test case/execution Plan]
>For each development item, discuss with IoTivity QA(Antu @samsung.com>) how to test your module.
> Finally, IoTivity QA should confirm the Test Plan.
>  
> BR, Uze Choi
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo 
> unces at lists.iotivity.org] On Behalf Of Christian Gran
> Sent: Monday, February 20, 2017 9:08 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb
>  
> Hi,
>  
> for the release process of IOTivity 1.3 the next milestone is the 
> feature freeze at 24th of Feb.
> Please provide your input which features you will have ready by that 
> time and update the wiki page 
> https://wiki.iotivity.org/1.3_release_plan a ccordingly.
> Please send me a short note when you are done with the updates for 
> your module.
>  
> thanks
>   Christian
>  
>  
> ___
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] Smart Home API proposal.

[최우제 (Uze Choi)]

Hi Glen,

Please reflect the previous valuable comments from others as much as possible 
during development.
Let me create the branch with this name.

BR, Uze Choi

From: ??? [mailto:glen@samsung.com] 
Sent: Monday, March 20, 2017 4:16 PM
To: iotivity-dev at lists.iotivity.org; ???
Subject: Re: [dev] Smart Home API proposal.



Hi all and Uze Choi,



As we discussed, we'd like to start proposed Smart Home API that provides 
another API in IoTivity service layer.

So, i have updated the wiki page for Smart Home API proposal that include 
problem definition and concept, features, advantage, and some example of ours. 

Plus, we are goint to implement Smart Home API based on required enhanced 
features.

https://wiki.iotivity.org/proposal_for_iotivity_smart_home_api



@Uze Choi

We'd like to start this work in separated branch named "smarthome_api".

Please create a branch for us.



BR,

Glen Youngjin Kim.



- Original Message -

Sender : ???  Principal Engineer/IoT Lab(S/W??)/

Date : 2017-03-08 16:01 (GMT+9)

Title : RE: Re: [dev] Smart Home API proposal.



Considering frequent adding and changing resource and property in the real 
world, code generation should be done again and again during developement which 
lead generated skelton code to be copied and replaced again. 

Furthermore code generation is a little bit old style I feel. Recently well 
abstrated API following less user code is more trendy( this comment does not 
mean Smart Home API.)



According to Younggin comment design goal looks different.

Whether code generation or not is othogonal from the main idea of his API 
proposal.



Omar could you explain why IPCA is closer to code generation ?



BR Uze Choi



- Original Message -
Sender : Omar Maabreh via iotivity-dev 
Date : 2017-03-08 07:12 (GMT+1)
Title : Re: [dev] Smart Home API proposal.

Totally agree that code generation is the right solution to this problem which 
we'd all like to solve.
The IPCA api's that are in gerrit right now are a first step in enabling this.

Thanks,
- Omar

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Tuesday, March 07, 2017 10:06 PM
To: iotivity-dev at lists.iotivity.org; glen.kim at samsung.com
Subject: Re: [dev] Smart Home API proposal.

Em quarta-feira, 8 de mar?o de 2017, ?s 01:31:27 CET, ??? escreveu:
> I think making RAML definition is not easy in 3rd party developer's 
> point of view. they need to know specification to make it again.
> therefore, i think this is reasonable proposal which provides API 
> usability improvement and way to make OCF service and device easily.

I don't think the goals are at odds. We do want the easy API. I just don't want 
*us* to spend time developing it for each and every resource type that OCF 
comes up with. I'd like us to create a code generator that does that job for 
us, for current as well as any future resource types.

That way, developers won't need to deal with the RAML files or Swagger files. 
They'll use the generated API.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
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

 

Glen YoungJin Kim 

IoT Lab | Convergence Team | Software Center 

SAMSUNG ELECTRONICS CO., LTD. 

010-3356-9627 

  glen.kim at samsung.com











-- next part --
HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?? ?? .
URL: 

[dev] [Request Again]: Request on IoTivity 1.3 release items.

[최우제 (Uze Choi)]

Greeting,



[Jira Registration/Tagging into wiki]

Rick, Todd, Vijay, JeeHyeok,

MPM, AllJoyn Bridge, Cloud update and UPnP Bridge update are not done yet.

Please create the jira ticket and update the context into wiki.



[Test case/execution Plan]

Nathan, Rick, Todd, Vijay, JeeHyeok,

Please communicate with IoTivity QA ASAP.



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, March 16, 2017 5:51 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Request on IoTivity 1.3 release items.



Hi, Feature contributors in 1.3 release.



Please check as below. and respond by this week.



[Jira Registration/Tagging into wiki]

Please add Jira tick link on https://wiki.iotivity.org/1.3_release_plan. as
like security related item.

Introspection, Versioning, Endpoint

MPM, AllJoyn Bridge, UPnP Bridge

CoAP Native Cloud Project items.

Generic Java Binding.

[Test case/execution Plan]

   For each development item, discuss with IoTivity
QA(Antu) how to test your module.

Finally, IoTivity QA should confirm the Test Plan.



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Christian Gran
Sent: Monday, February 20, 2017 9:08 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi,



for the release process of IOTivity 1.3 the next milestone is the feature
freeze at 24th of Feb.

Please provide your input which features you will have ready by that time

and update the wiki page https://wiki.iotivity.org/1.3_release_plan
accordingly.

Please send me a short note when you are done with the updates for your
module.



thanks

  Christian





-- next part --
HTML ?? ??...
URL: 

[dev] Request on IoTivity 1.3 release items.

[최우제 (Uze Choi)]

Hi, Feature contributors in 1.3 release.



Please check as below. and respond by this week.



[Jira Registration/Tagging into wiki]

Please add Jira tick link on https://wiki.iotivity.org/1.3_release_plan. as
like security related item.

Introspection, Versioning, Endpoint

MPM, AllJoyn Bridge, UPnP Bridge

CoAP Native Cloud Project items.

Generic Java Binding.

[Test case/execution Plan]

   For each development item, discuss with IoTivity
QA(Antu) how to test your module.

Finally, IoTivity QA should confirm the Test Plan.



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Christian Gran
Sent: Monday, February 20, 2017 9:08 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi,



for the release process of IOTivity 1.3 the next milestone is the feature
freeze at 24th of Feb.

Please provide your input which features you will have ready by that time

and update the wiki page https://wiki.iotivity.org/1.3_release_plan
accordingly.

Please send me a short note when you are done with the updates for your
module.



thanks

  Christian





-- next part --
HTML ?? ??...
URL: 

[dev] java and cloud

[최우제 (Uze Choi)]

Hi Rick,



Could you elaborate detail for this task from deliverable asset perspective?

: Will you make the Java API base on J2SE platform with continuing to
support Android Java API also. Or merging them into one removing Android.

: API list can you provide for test preparation? (Testing may be executed
by your company I think.)

Do you have a Jira ticket for this? If not please make it.



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Thursday, March 16, 2017 10:02 AM
To: 'Ondrej Tomcik'; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] java and cloud



Hi Ondjej,



Generic Java is the scope of the 1.3 release.

We can expect code to be merged into master by this month.



Generic Java Binding

? I am working on the Wiki page for the Java Binding and will
release it when it is available.

? We will be enabling the Java Binding as part build and Jenkins
Testing in the near future.



Rick do you have any update for this plan?



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Ondrej Tomcik
Sent: Thursday, March 16, 2017 12:11 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] java and cloud



Hello.

Please, is it possible to create IoTivity client in Java or something
different than c++ which is able to connect to cloud?

Java SDK is only for android, i need console application.



Thanks.

OT

-- next part --
HTML ?? ??...
URL: 

[dev] java and cloud

[최우제 (Uze Choi)]

Hi Ondjej,



Generic Java is the scope of the 1.3 release.

We can expect code to be merged into master by this month.



Generic Java Binding

? I am working on the Wiki page for the Java Binding and will
release it when it is available.

? We will be enabling the Java Binding as part build and Jenkins
Testing in the near future.



Rick do you have any update for this plan?



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Ondrej Tomcik
Sent: Thursday, March 16, 2017 12:11 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] java and cloud



Hello.

Please, is it possible to create IoTivity client in Java or something
different than c++ which is able to connect to cloud?

Java SDK is only for android, i need console application.



Thanks.

OT

-- next part --
HTML ?? ??...
URL: 

[dev] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

Hi Ashok, and Randeep,
Could you check validation this header file list for public API?
If needed share the work with sub maintainer.
BR, Uze Choi
-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, March 14, 2017 10:46 AM
To: 'Mats Wichmann'; 'Nash, George'; 'IoTivity Developer List'
Subject: RE: [dev] C API docs: which Doxyfile?

C API is the most fundamental language among them, We need to filter out by
confirming from each maintainer. (Discovery & Connectivity, Security) Let's
debug one by one.

../../csdk/stack/include/ocstack.h \
 ../../csdk/stack/include/octypes.h \
 ../../csdk/stack/include/ocpayload.h \
 ../../csdk/stack/include/ocpresence.h \
 ../../csdk/stack/include/payload_logging.h \
 ../../csdk/stack/include/ocstackconfig.h \
 ../../csdk/stack/include/internal/occlientcb.h \
 ../../csdk/stack/include/internal/occollection.h \
 ../../csdk/stack/include/internal/ocobserve.h \
 ../../csdk/stack/include/internal/ocpayloadcbor.h \
 ../../csdk/stack/include/internal/ocresource.h \
 ../../csdk/stack/include/internal/ocresourcehandler.h \
 ../../csdk/stack/include/internal/ocserverrequest.h \
 ../../csdk/stack/include/internal/ocstackinternal.h \
 ../../csdk/stack/include/internal/oicgroup.h \
 ../../csdk/stack/include/internal/oickeepalive.h \
 ../../csdk/connectivity/api \

 ../../csdk/security/include \
 ../../csdk/security/include\internal \
 ../../csdk/security/provisioning/include \
 ../../csdk/security/provisioning/include/ocprovisioningmanager.
h \
 ../../csdk/security/provisioning/include/pmtypes.h \
 ../../csdk/security/provisioning/include/pmutility.h \
 ../../csdk/security/provisioning/include/internal \
 ../../csdk/security/provisioning/include/oxm \
 ../../csdk/security/provisioning/include/cloud \

BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Tuesday, March 14, 2017 10:25 AM
To: Nash, George; IoTivity Developer List
Subject: Re: [dev] C API docs: which Doxyfile?

On 03/13/2017 03:08 PM, Nash, George wrote:
> You are correct. The current doxygen file is 
> resource/docs/c-doc/Doxyfile
> 
> https://wiki.iotivity.org/generate_api_doc
> 
> Right now the wiki only includes the instructions on generating the API
doc nothing more.
> 
> I do not know why the files don't set the "OPTIMIZE_OUTPUT_FOR_C" flag.
It seems like it should be set.
> 
> There is also a second Doxygen config file devdocs.doxyfile.
> 
> The best I can gather the default Doxyfile is supposed to be for the
public headers. While the devdocs.doxyfile is supposed to run across the
all of the project files. It looks like both files need to be maintained a
little more. The default Doxyfile is definitally including header files
that are internal header files. I did do a little cleanup work recently but
that was just the minimum work to fix the warnings reported when doxygen
was run. The OSWG really wants to improve the documentation but its hard to
know where to start when I am a little unclear about which files are public
and which are not. There is also desire to improve the param markup to mark
in,out values of the params.
> 
> George

Yikes... seems like we need to figure out what the "public API" (among the
various C, C++, Java, etc. API sets) actually is.  How can I help with this?

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] About miniPluginManager of bridging

[최우제 (Uze Choi)]

Hi Morrow,

Question from your answer. 

2.  The software component of the plugin contains the IoTivity instance. 
This same software component uses IoTivity APIs and Hue RestFUL APIs to bridge 
the two ecosystems within the same process. Each plugin instance gets its own 
IoTivity instance.

Let me illustrate simple protocol model :   MPM ? (IPC) -> Plugin  ? (OCF CoAP) 
-> Bridge ? (Hue Restful) -> Hue_Light

Is it correct? If not and ?MPM ? (IPC) -> Plugin  ? (Hue Restful) -> Bridge ? 
(Hue Restful) -> Hue_Light? is valid, I don?t know why there is redundant 
module (bridge or plugin) to bridge two protocol.

BR, Uze Choi

From: Morrow, Joseph L [mailto:joseph.l.mor...@intel.com] 
Sent: Tuesday, March 14, 2017 5:58 AM
To: uzchoi at samsung.com; Bell, Richard S; VanCutsem, Geoffroy; jihwan.seo at 
samsung.com; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Hi Uze,

We mentioned MPM is a replacement plugin framework for IoTivity. It doesn?t 
match the capabilities in any 1-to-1 way other than giving developers the 
tooling necessary to create a plugin.

1.  Different device.

2.  The software component of the plugin contains the IoTivity instance. 
This same software component uses IoTivity APIs and Hue RestFUL APIs to bridge 
the two ecosystems within the same process. Each plugin instance gets its own 
IoTivity instance.

3.  Yes.

Thanks,

Joey Morrow



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Monday, March 13, 2017 1:19 AM
To: Bell, Richard S ; VanCutsem, Geoffroy 
; Morrow, Joseph L ; jihwan.seo at samsung.com; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Hi Vijay/Joey,

Good to see full documentation.
Plugin sample code and loading plugin code will help the better understanding.
You explained that MPM is replacement from Resource Container during F2F OSWG 
session,
However, there are considerable gaps between them, let me ask followings 
include gap.

1)From your architecture, MPM, Hue plugin, Hue Bridge and Hue Light are 
listed.
Hue bridge is also separate process in the same or different device?

2)Which node has a iotivity instance? 

Plugin looks having the IoTivity instance. And Hue Bridge should have it for 
discovery at least.

Furthermore, Each plugin has its own IoTivity instance with separate Iotivity 
lifecycle or shares common iotivity instance?

3)Previous Resource Container has the interface class (BundleResource), it 
has request handler virtual method for GET/POST request.
However, this concept has been removed, which means plugin developer should 
implement this function using IoTivity API by himself?

BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Bell, Richard S
Sent: Friday, March 10, 2017 7:18 PM
To: VanCutsem, Geoffroy; Morrow, Joseph L; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] About miniPluginManager of bridging



Geoffroy,

Thanks that is better.

They are now viewable?

Thanks,

-Rick Bell



From: VanCutsem, Geoffroy 
Sent: Friday, March 10, 2017 11:12 AM
To: Morrow, Joseph L ; Bell, Richard S 
; jihwan.seo at samsung.com; iotivity-dev at 
lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



I?ve updated the wiki page so that:

1.   Both images are displayed full-size (instead of being scaled down to a 
200-pixel width)

2.   Clicking on them takes you directly to the full image in its own page

Feel free to revert these changes if that?s not what you wanted to see.

Geoffroy

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Morrow, Joseph L
Sent: Thursday, March 9, 2017 8:24 PM
To: Bell, Richard S ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] About miniPluginManager of bridging



Hi Rick,

You have to click on them, then that opens the attachment, then you click on it 
in that new page and this opens the image up fully.

You will have to do that two times. I can?t find a way to add the image without 
this process.

Thanks,

Joey Morrow



From: Bell, Richard S 
Sent: Thursday, March 9, 2017 11:05 AM
To: Morrow, Joseph L ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Joey,

Can you put those two images on separate wiki pages?

I can?t really read them.

Thanks,

-Rick



From: Morrow, Joseph L 
Sent: Thursday, March 9, 2017 7:29 PM
To: Bell, Richard S ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Hi Rick and JiHwan,

I have gotten the diagrams updated and now they?re uploaded to the wiki. Please 
find them here:

https://wiki.iotivity.org/bridging_project_architecture

Thanks,

Joey Morrow

From: Bell, Richard S 
Sent: Wednesday, March 

[dev] C API docs: which Doxyfile?

[최우제 (Uze Choi)]

C API is the most fundamental language among them,
We need to filter out by confirming from each maintainer. (Discovery &
Connectivity, Security)
Let's debug one by one.

../../csdk/stack/include/ocstack.h \
 ../../csdk/stack/include/octypes.h \
 ../../csdk/stack/include/ocpayload.h \
 ../../csdk/stack/include/ocpresence.h \
 ../../csdk/stack/include/payload_logging.h \
 ../../csdk/stack/include/ocstackconfig.h \
 ../../csdk/stack/include/internal/occlientcb.h \
 ../../csdk/stack/include/internal/occollection.h \
 ../../csdk/stack/include/internal/ocobserve.h \
 ../../csdk/stack/include/internal/ocpayloadcbor.h \
 ../../csdk/stack/include/internal/ocresource.h \
 ../../csdk/stack/include/internal/ocresourcehandler.h \
 ../../csdk/stack/include/internal/ocserverrequest.h \
 ../../csdk/stack/include/internal/ocstackinternal.h \
 ../../csdk/stack/include/internal/oicgroup.h \
 ../../csdk/stack/include/internal/oickeepalive.h \
 ../../csdk/connectivity/api \

 ../../csdk/security/include \
 ../../csdk/security/include\internal \
 ../../csdk/security/provisioning/include \
 ../../csdk/security/provisioning/include/ocprovisioningmanager.
h \
 ../../csdk/security/provisioning/include/pmtypes.h \
 ../../csdk/security/provisioning/include/pmutility.h \
 ../../csdk/security/provisioning/include/internal \
 ../../csdk/security/provisioning/include/oxm \
 ../../csdk/security/provisioning/include/cloud \

BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Tuesday, March 14, 2017 10:25 AM
To: Nash, George; IoTivity Developer List
Subject: Re: [dev] C API docs: which Doxyfile?

On 03/13/2017 03:08 PM, Nash, George wrote:
> You are correct. The current doxygen file is 
> resource/docs/c-doc/Doxyfile
> 
> https://wiki.iotivity.org/generate_api_doc
> 
> Right now the wiki only includes the instructions on generating the API
doc nothing more.
> 
> I do not know why the files don't set the "OPTIMIZE_OUTPUT_FOR_C" flag.
It seems like it should be set.
> 
> There is also a second Doxygen config file devdocs.doxyfile.
> 
> The best I can gather the default Doxyfile is supposed to be for the
public headers. While the devdocs.doxyfile is supposed to run across the
all of the project files. It looks like both files need to be maintained a
little more. The default Doxyfile is definitally including header files
that are internal header files. I did do a little cleanup work recently but
that was just the minimum work to fix the warnings reported when doxygen
was run. The OSWG really wants to improve the documentation but its hard to
know where to start when I am a little unclear about which files are public
and which are not. There is also desire to improve the param markup to mark
in,out values of the params.
> 
> George

Yikes... seems like we need to figure out what the "public API" (among the
various C, C++, Java, etc. API sets) actually is.  How can I help with this?

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] About miniPluginManager of bridging

[최우제 (Uze Choi)]

Hi Vijay/Joey,

Good to see full documentation.
Plugin sample code and loading plugin code will help the better understanding.
You explained that MPM is replacement from Resource Container during F2F OSWG 
session,
However, there are considerable gaps between them, let me ask followings 
include gap.

1) From your architecture, MPM, Hue plugin, Hue Bridge and Hue Light are 
listed.
Hue bridge is also separate process in the same or different device?

2) Which node has a iotivity instance? 

Plugin looks having the IoTivity instance. And Hue Bridge should have it for 
discovery at least.

Furthermore, Each plugin has its own IoTivity instance with separate Iotivity 
lifecycle or shares common iotivity instance?

3) Previous Resource Container has the interface class (BundleResource), it 
has request handler virtual method for GET/POST request.
However, this concept has been removed, which means plugin developer should 
implement this function using IoTivity API by himself?

BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Bell, Richard S
Sent: Friday, March 10, 2017 7:18 PM
To: VanCutsem, Geoffroy; Morrow, Joseph L; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] About miniPluginManager of bridging



Geoffroy,

Thanks that is better.

They are now viewable?

Thanks,

-Rick Bell



From: VanCutsem, Geoffroy 
Sent: Friday, March 10, 2017 11:12 AM
To: Morrow, Joseph L ; Bell, Richard S 
; jihwan.seo at samsung.com; iotivity-dev at 
lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



I?ve updated the wiki page so that:

1.   Both images are displayed full-size (instead of being scaled down to a 
200-pixel width)

2.   Clicking on them takes you directly to the full image in its own page

Feel free to revert these changes if that?s not what you wanted to see.

Geoffroy

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Morrow, Joseph L
Sent: Thursday, March 9, 2017 8:24 PM
To: Bell, Richard S ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: Re: [dev] About miniPluginManager of bridging



Hi Rick,

You have to click on them, then that opens the attachment, then you click on it 
in that new page and this opens the image up fully.

You will have to do that two times. I can?t find a way to add the image without 
this process.

Thanks,

Joey Morrow



From: Bell, Richard S 
Sent: Thursday, March 9, 2017 11:05 AM
To: Morrow, Joseph L ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Joey,

Can you put those two images on separate wiki pages?

I can?t really read them.

Thanks,

-Rick



From: Morrow, Joseph L 
Sent: Thursday, March 9, 2017 7:29 PM
To: Bell, Richard S ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Hi Rick and JiHwan,

I have gotten the diagrams updated and now they?re uploaded to the wiki. Please 
find them here:

https://wiki.iotivity.org/bridging_project_architecture

Thanks,

Joey Morrow

From: Bell, Richard S 
Sent: Wednesday, March 8, 2017 8:11 AM
To: Morrow, Joseph L ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Joey,

Thanks for support?



-Rick



From: Morrow, Joseph L 
Sent: Wednesday, March 8, 2017 5:09 PM
To: Bell, Richard S ; jihwan.seo at samsung.com; 
iotivity-dev at lists.iotivity.org
Subject: RE: [dev] About miniPluginManager of bridging



Hi JiHwan and Rick,

I am finalizing some architecture docs now. I will post these diagrams to the 
wiki and reply to this thread ASAP when they?re available.

Thanks,

Joey Morrow

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Bell, Richard S
Sent: Wednesday, March 8, 2017 8:06 AM
To: jihwan.seo at samsung.com; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] About miniPluginManager of bridging



Hi,

This what I have?

MPM Documentation: https://wiki.iotivity.org/bridging_project

*   Infrastructure of a Plugin: 
https://wiki.iotivity.org/infrastructure_of_a_plugin

o   MPM infrastructure: https://wiki.iotivity.org/infrastructure_of_mpm

Thanks,

-Rick Bell





From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of JiHwan Seo
Sent: Wednesday, March 8, 2017 2:22 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] About miniPluginManager of bridging



Hi All



I can't find some document including Architecture, Sequence diagram. etc for 
miniPluginManager of Briding from wiki page.

Anyone who know where can i find the document of miniPluginManager?









  

[dev] API Review function

[최우제 (Uze Choi)]

Smart home API will be proposed in public soon.

BR, Uze Choi

From: Thiago Moura [mailto:thiago...@gmail.com] 
Sent: Friday, March 03, 2017 1:36 PM
To: Thiago Macieira
Cc: ??? (Uze Choi); Gregg Reynolds; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] API Review function



and what about this Smart Home API?



On Fri, Mar 3, 2017 at 1:34 AM, Thiago Macieira  
wrote:

Em quinta-feira, 2 de mar?o de 2017, ?s 20:17:35 PST, Thiago Moura escreveu:
> Hi Uze,
> Talking about IPCA.. I noticed the "initial commit" this week on master
> branch, but there was no word about this feature over here. Where does this
> kind of feature discussion happens? And why IPCA only targets Windows?

That commit is the beginning of the discussion.


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center







-- 

Thiago Guedes Cunha de Moura
Graduando em Ci?ncia da Computa??o
Instituto de Ci?ncias Exatas e Biol?gicas - Universidade Federal de Ouro Preto

cel.: (31)99484-9864

-- next part --
HTML ?? ??...
URL: 

[dev] API Review function

[최우제 (Uze Choi)]

I agree that concept should be introduced in public and described in wiki page 
from iotivity feature development process perspective.

Simply, I just listed up whole activities on iotivity as of now regardless 
following this rule.



BR, Uze Choi

From: Thiago Moura [mailto:thiago...@gmail.com] 
Sent: Friday, March 03, 2017 1:18 PM
To: ??? (Uze Choi)
Cc: Gregg Reynolds; Thiago Macieira; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] API Review function



Hi Uze,
Talking about IPCA.. I noticed the "initial commit" this week on master branch, 
but there was no word about this feature over here. Where does this kind of 
feature discussion happens? And why IPCA only targets Windows?



On Thu, Mar 2, 2017 at 9:27 PM, ??? (Uze Choi)  wrote:

In the IoTivity there are several API sets as follows including currently being 
implemented.

There are several API sets as follow in IoTivity.



Standard IoTivity

-   csdk C API (Tested from IoTivity QA)

-   resource(base) C++ API (Tested from IoTivity QA) ? Dependency with csdk 
API

-   resource(base) Java API (Tested from IoTivity QA) ? Dependency with C++ 
API

-   Resource Encapsulation C++ API (Tested from IoTivity QA) ? Dependency 
with C++ API

-   Resource Encapsulation Java API (Tested from IoTivity QA) ? Dependency 
with C++ API

-   IPCA C API (being implemented) -  Dependency with C++ API

-   Smart Home API (being implemented) ? Dependency with csdk API

Constraint IoTivity

-   C API (not Tested from IoTivity QA yet)



We need to select which API set is officially guaranteed for user to use and 
what else is the optional set.

There is Discrepancy across different API set. Currently, Some APIs in the 
higher level are not implemented yet. For example, C API set has some 
functionalities but C++/Java does not have it, even if these are quite 
important features. They should be managed well from API review team.

One comment, dropping specific API set should consider dependency also.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds
Sent: Friday, March 03, 2017 7:52 AM
To: Thiago Macieira
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] API Review function







On Mar 2, 2017 4:29 PM, "Thiago Macieira"  wrote:

On quinta-feira, 2 de mar?o de 2017 14:16:26 PST Thiago Macieira wrote:
> Hello all
>
> Finally getting to my action items from previous meetings of the Steering
> Group. I will send an email on each of the two, new proposed functions,
> detailing what is expected. We're looking for volunteers to assume the
> position of Function Lead for organising IoTivity's API as well as
> Buildsystem. We're asking for candidates since there is no natural
> candidate.

The first of the two proposed functions is the API Review one. We need a person
or a team to be willing to look into any API we design that is meant to be
used by anyone except ourselves, and make sure that the API is consistent.
Soon, we'd also like to make sure that our API is backwards compatible, so
applications written with IoTivity version X will continue to compile and work
with IoTivity version Y, provided Y >= X.

This team will probably be tasked with reviewing the existing API as well,
proposing changes, and establishing guidelines on how to review. The latter
point will impact releasing: when is the API review supposed to happen,
relative to the feature freeze and the releases? When is the API frozen for a
given release? (note that Dino's release suggestion timetable had some
elements of this)

This is a technical function and the Function Lead is expected to be
knowledgeable of C and C++ API designs[*].

[*] the team may propose dropping the C++ API.



+1001


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
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







-- 

Thiago Guedes Cunha de Moura
Graduando em Ci?ncia da Computa??o
Instituto de Ci?ncias Exatas e Biol?gicas - Universidade Federal de Ouro Preto

cel.: (31)99484-9864

-- next part --
HTML ?? ??...
URL: 

[dev] Unit Test execution issue in Jenkins

[최우제 (Uze Choi)]

Hi C.J, it?s Great!

I also hope not to see this kind of bug and not to spend too much time for this 
job execution.

BR, Uze Choi

From: C.J. Collier [mailto:cjcoll...@linuxfoundation.org] 
Sent: Friday, March 03, 2017 6:20 AM
To: Philippe Coval
Cc: iotivity-dev at lists.iotivity.org; ???(Uze Choi)
Subject: Re: [dev] Unit Test execution issue in Jenkins



I received Phil's review and have +2'd and merged.  Hopefully this will keep 
the build failures from recurring.





On Wed, Mar 1, 2017 at 1:37 PM, C.J. Collier  
wrote:

Okay folks!  Looks like I've got the configuration in place.  Please review and 
let me know if I can +2.



https://gerrit.iotivity.org/gerrit/#/c/17589



Cheers,



C.J.





On Wed, Mar 1, 2017 at 11:01 AM, C.J. Collier  wrote:

Hi folks!  Sorry, this list seems to be filtered.  I'll add a rule to notify me 
when messages come in from this list.  But please be aware that I check on the 
RT queue much more frequently, and that the best way to get attention is to 
mail iotivity-helpdesk at rt.linuxfoundation.org.



It looks like the correct solution to this problem is to throttle the builds of 
this job to just one.  The documentation on the JJB config option is here:



https://docs.openstack.org/infra/jenkins-job-builder/properties.html#properties.throttle



And the source for the JJB config lives here:



https://git.iotivity.org/ci-management/tree/jjb/iotivity/iotivity-jobs.yaml#n164



I will create a change request for your review.  Phil & Uze, I will include you 
as reviewers.



C.J.





On Tue, Feb 28, 2017 at 1:17 AM, Philippe Coval  wrote:

On 27/02/17 09:05, ??? (Uze Choi) wrote:



Hi Phil, LF help or anyone else,

Hi everyone, I didn't manage to reach CJ yesterday to progress on that issue.





Currently there are frequent unit test build job failure from Jenkins 
verification.

During Unit Test execution, parallel unit test executing cause racing issue.

yes I think it was already reported in the past (was there a bug ticket?)



For example, A test case expect A resource server but at the same time B test 
case find A resource first and A resource server close its session.

yea, a lock is missing somewhere to prevent task reentrance



Then A test case cannot find A resource. 
https://build.iotivity.org/ci/job/iotivity-verify-unit_tests/10126/ 

Test case should have considered this cases but every test case does not 
consider it well.

As a fallback you can retrigger build but this is not solving anything.





As a solution, can we selectively disable this parallel execution for specific 
job(unit test job) 

yes this is a sane workaround, 
or maybe we could be better isolation using containers or vm ?



or check what is the other issue over there?

Is it Jenkins system operation responsibility or build script manager 
responsibility or others.

I don't have control on jenkins, but CJ has,
I will try to reach him online again and keep you updated.

Regards


-- 

mailto:philippe.coval at osg.samsung.com gpg:0x467094BC
https://blogs.s-osg.org/author/pcoval/








-- next part --
HTML ?? ??...
URL: 

[dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb

[최우제 (Uze Choi)]

Hi Nathan,



Don?t worry. Implementation is not needed to be merged in this first
milestone.

Only feature list need to be fixed and hopefully API to be fixed for QA
team to create test case.

Implementation should be merged by second milestone. (6W later from first
milestone. 5W from now on)



BR, Uze Choi

From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] 
Sent: Wednesday, March 01, 2017 5:09 AM
To: '??? (Uze Choi)'; 'Christian Gran'; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi Uze, others,



As expected, there are still Security features that are not merged into
Master.  The latest dashboard is available on Kavi and linked to from the 1.
3 release plan wiki page (https://wiki.iotivity.org/1.3_release_plan),
which I am taking as definitive.  

As discussed, we expect to merge features (and also merge CRs into Security
Spec) throughout IPR process, as they pass CTT validation.  CTT test cases
are still being developed in parallel.  Several of the major changes should
be coming in this week, and a few others will be late in March.  



Right now the biggest risk I see is that there are three new Security CRs
that have become mandatory in the past few weeks, for which we do not have
developer resources identified.  I?m searching for volunteers and will
update when I have more info.



Thanks,
Nathan



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Sunday, February 26, 2017 11:13 PM
To: 'Christian Gran' ; iotivity-dev at 
lists.iotivity.
org
Subject: Re: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi, IoTivity Feature contributors,



By last week, not only feature but also API should have been fixed.

[Feature list]

?  OCF1.0 Compliant Items

?  OCF - AllJoyn Bridge

?  Introspection

?    Versioning

?  Endpoint

?  Security updates

?  Onboarding States and Device Offboarding (

https://jira.iotivity.org/browse/IOT-1763)

?  Certificate Updates and Role Feature (

https://jira.iotivity.org/browse/IOT-1785)

?  Software Update ( 
https://jira.iotivity.org/browse/IOT-1786)

?  UPnP Bridge Updates

?  Each Project Update

?  WiFi Easy-Setup

?  IoTivity Cloud

?  CoAP over Web-socket

?  Web-browser based dash-board

?  Dockerize each servers

?  API for 3rd Party service integration

?  Introduction to the ? 
Bridging Project.?

?  Porting Iotvity's Csdk stack on ESP8266 WiFi Module

?  Generic Java Binding

(From  
https://wiki.iotivity.org/1.3_release_plan)

If Feature is not posted by mistakenly, please let us know.



Please answer corresponding Jira ticket and whether API code has been
merged or not for each feature.

With full detail info, QA team can start making test case.



We have just passed first release milestone. (see release milestone detail
from  
https://wiki.iotivity.org/release_process)

1.3-rel branch will be created from second milestone. (6W later)



BR, Uze Choi

From:   iotivity-dev-
bounces at lists.iotivity.org [  mailto:iotivity-dev-bounces at 
lists.iotivity.org]
On Behalf Of Christian Gran
Sent: Thursday, February 23, 2017 7:46 PM
To:   iotivity-
dev at lists.iotivity.org
Subject: Re: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi, 



just a reminder that this feature freeze milestone for 1.3 is tomorrow.

There have not been that many updates to the page so far:

https://wiki.iotivity.org/1.3_release_plan



thanks

  Christian









On 20 Feb 2017, at 13:08, Christian Gran  wrote:



Hi,



for the release process of IOTivity 1.3 the next milestone is the feature
freeze at 24th of Feb.

Please provide your input which features you will have ready by that time

and update the wiki page https://wiki.iotivity.org/1.3_release_plan
accordingly.

Please send me a short note when you are done with the updates for your
module.



thanks

  Christian







-- next part --
HTML ?? ??...
URL: 

[dev] API Review and Buildsystem functions

[최우제 (Uze Choi)]

For this Build system, there could be several jobs regarding Jenkins management 
as follows.
- Jenkins server system environment fix such as pre install libraries from 
build fail.
- Resolving (or request to LF) server infra issue from build fail
- Build failure for invalid commit (sometime merged without the rebase with the 
latest)
- Jenkins build script configuration (load balance jobs or execute a job in 
parallel or serially)
- Manage the Jenkins job list across branches.

Tasks include not only code base fix but also policy setting.
This is why I open to discuss this position as function lead.

BR, Uze Choi
-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Friday, March 03, 2017 7:31 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] API Review and Buildsystem functions

On quinta-feira, 2 de mar?o de 2017 14:16:26 PST Thiago Macieira wrote:
> Hello all
> 
> Finally getting to my action items from previous meetings of the 
> Steering Group. I will send an email on each of the two, new proposed 
> functions, detailing what is expected. We're looking for volunteers to 
> assume the position of Function Lead for organising IoTivity's API as 
> well as Buildsystem. We're asking for candidates since there is no 
> natural candidate.

The second of the requested functions is the Buildsystem one. We'd like to ask 
a person or a team of people to take on the challenge of overhauling IoTivity- 
full's buildsystem (currently Scons) and become responsible for reviewing any 
changes to it in the future. These people will be expected to interact with 
other developers and Maintainers, helping with their necessities as the 
codebase evolves.

It is possible we change this from Function to Subsystem (and from Function 
Lead to Maintainer). We're open to suggestions.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] API Review function

[최우제 (Uze Choi)]

In the IoTivity there are several API sets as follows including currently being 
implemented.

There are several API sets as follow in IoTivity.



Standard IoTivity

-   csdk C API (Tested from IoTivity QA)

-   resource(base) C++ API (Tested from IoTivity QA) ? Dependency with csdk 
API

-   resource(base) Java API (Tested from IoTivity QA) ? Dependency with C++ 
API

-   Resource Encapsulation C++ API (Tested from IoTivity QA) ? Dependency 
with C++ API

-   Resource Encapsulation Java API (Tested from IoTivity QA) ? Dependency 
with C++ API

-   IPCA C API (being implemented) -  Dependency with C++ API

-   Smart Home API (being implemented) ? Dependency with csdk API

Constraint IoTivity

-   C API (not Tested from IoTivity QA yet)



We need to select which API set is officially guaranteed for user to use and 
what else is the optional set.

There is Discrepancy across different API set. Currently, Some APIs in the 
higher level are not implemented yet. For example, C API set has some 
functionalities but C++/Java does not have it, even if these are quite 
important features. They should be managed well from API review team.

One comment, dropping specific API set should consider dependency also.



BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds
Sent: Friday, March 03, 2017 7:52 AM
To: Thiago Macieira
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] API Review function







On Mar 2, 2017 4:29 PM, "Thiago Macieira"  wrote:

On quinta-feira, 2 de mar?o de 2017 14:16:26 PST Thiago Macieira wrote:
> Hello all
>
> Finally getting to my action items from previous meetings of the Steering
> Group. I will send an email on each of the two, new proposed functions,
> detailing what is expected. We're looking for volunteers to assume the
> position of Function Lead for organising IoTivity's API as well as
> Buildsystem. We're asking for candidates since there is no natural
> candidate.

The first of the two proposed functions is the API Review one. We need a person
or a team to be willing to look into any API we design that is meant to be
used by anyone except ourselves, and make sure that the API is consistent.
Soon, we'd also like to make sure that our API is backwards compatible, so
applications written with IoTivity version X will continue to compile and work
with IoTivity version Y, provided Y >= X.

This team will probably be tasked with reviewing the existing API as well,
proposing changes, and establishing guidelines on how to review. The latter
point will impact releasing: when is the API review supposed to happen,
relative to the feature freeze and the releases? When is the API frozen for a
given release? (note that Dino's release suggestion timetable had some
elements of this)

This is a technical function and the Function Lead is expected to be
knowledgeable of C and C++ API designs[*].

[*] the team may propose dropping the C++ API.



+1001


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev



-- next part --
HTML ?? ??...
URL: 

[dev] Unit Test execution issue in Jenkins

[최우제 (Uze Choi)]

Hi Phil, LF help or anyone else,



Currently there are frequent unit test build job failure from Jenkins
verification.

During Unit Test execution, parallel unit test executing cause racing issue.

For example, A test case expect A resource server but at the same time B
test case find A resource first and A resource server close its session.
Then A test case cannot find A resource.
https://build.iotivity.org/ci/job/iotivity-verify-unit_tests/10126/ 

Test case should have considered this cases but every test case does not
consider it well.



As a solution, can we selectively disable this parallel execution for
specific job(unit test job) or check what is the other issue over there?

Is it Jenkins system operation responsibility or build script manager
responsibility or others.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb

[최우제 (Uze Choi)]

Hi, IoTivity Feature contributors,



By last week, not only feature but also API should have been fixed.

[Feature list]

?  OCF1.0 Compliant Items

?  OCF - AllJoyn Bridge

?  Introspection

?    Versioning

?  Endpoint

?  Security updates

?  Onboarding States and Device Offboarding (

https://jira.iotivity.org/browse/IOT-1763)

?  Certificate Updates and Role Feature (

https://jira.iotivity.org/browse/IOT-1785)

?  Software Update ( 
https://jira.iotivity.org/browse/IOT-1786)

?  UPnP Bridge Updates

?  Each Project Update

?  WiFi Easy-Setup

?  IoTivity Cloud

?  CoAP over Web-socket

?  Web-browser based dash-board

?  Dockerize each servers

?  API for 3rd Party service integration

?  Introduction to the ? 
Bridging Project.?

?  Porting Iotvity's Csdk stack on ESP8266 WiFi Module

?  Generic Java Binding

(From https://wiki.iotivity.org/1.3_release_plan)

If Feature is not posted by mistakenly, please let us know.



Please answer corresponding Jira ticket and whether API code has been
merged or not for each feature.

With full detail info, QA team can start making test case.



We have just passed first release milestone. (see release milestone detail
from https://wiki.iotivity.org/release_process)

1.3-rel branch will be created from second milestone. (6W later)



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Christian Gran
Sent: Thursday, February 23, 2017 7:46 PM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] IOTivity 1.3 next milestone: Feature Freeze 24th of Feb



Hi, 



just a reminder that this feature freeze milestone for 1.3 is tomorrow.

There have not been that many updates to the page so far:

https://wiki.iotivity.org/1.3_release_plan



thanks

  Christian









On 20 Feb 2017, at 13:08, Christian Gran  wrote:



Hi,



for the release process of IOTivity 1.3 the next milestone is the feature
freeze at 24th of Feb.

Please provide your input which features you will have ready by that time

and update the wiki page https://wiki.iotivity.org/1.3_release_plan
accordingly.

Please send me a short note when you are done with the updates for your
module.



thanks

  Christian







-- next part --
HTML ?? ??...
URL: 

[dev] Regarding upcomming ISG F2F Meeting Agenda

[최우제 (Uze Choi)]

Dwarka, are you starting it on the wiki page or locally? IoTivity wiki
looks best place I think.

It will be best Dwarka to define what should be in there in this document
and Nathan and others to fill the context in.



Nathan, Currently Developer Eco Build TG in OSWG also organizes all
document task and get the candidate to help it..

Please let DEB TG take this job.



BR, Uze Choi

From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] 
Sent: Tuesday, February 21, 2017 11:40 PM
To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Regarding upcomming ISG F2F Meeting Agenda



This is a good agenda start.



Can we add ?OIC 1.1 vs. OCF 1.0 Client User Guide? or some such?
Basically, an effort to create a document to describe very clearly the
differences in behavior between the two versions which Client must
understand?  I think Dwarka has started such a document although I also
need to contribute the Security aspect.  I think it will be good to have
all the experts in the room and make sure we have a complete list of
differences requiring documentation.  Hopefully it is short!


Thanks,
Nathan



From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, February 21, 2017 12:11 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Regarding upcomming ISG F2F Meeting Agenda



Dear ISG member,



As we know, 7th Mar is the ISG F2F meeting place.

Until now, agenda has not been discussed yet, I wish items listed up and
let the relevant person have time to prepare.



Let me list up the list which I can think about.

- API review/Build Function position: Discussion has not been initiated
after last F2F meeting. Let me prepare the initial R presentation.

- IoTivity Organization : OCF relation/Funding/So on.. : I guess Kathleen
will prepare discussion.

- TSC structure: Automotive/Industrial/Home : will it be happen? Who will
do this?

- IoTivity roadmap discussion (Development view/Release view) : Gran
suggested to make it. How about all member helping Gran prepare it.



I?d like to suggest more item regarding development material and
deployment practice also, but let me put it aside until other?s idea sum-
up.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Regarding upcomming ISG F2F Meeting Agenda

[최우제 (Uze Choi)]

Dear ISG member,



As we know, 7th Mar is the ISG F2F meeting place.

Until now, agenda has not been discussed yet, I wish items listed up and
let the relevant person have time to prepare.



Let me list up the list which I can think about.

- API review/Build Function position: Discussion has not been initiated
after last F2F meeting. Let me prepare the initial R presentation.

- IoTivity Organization : OCF relation/Funding/So on.. : I guess Kathleen
will prepare discussion.

- TSC structure: Automotive/Industrial/Home : will it be happen? Who will
do this?

- IoTivity roadmap discussion (Development view/Release view) : Gran
suggested to make it. How about all member helping Gran prepare it.



I?d like to suggest more item regarding development material and
deployment practice also, but let me put it aside until other?s idea sum-
up.



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status

[최우제 (Uze Choi)]

Hi Todd/Chun,



Still OCF1.0 features are not merged yet. When do we get them merged or any 
alternative way to get the proper IoTivity code for PF participation?



AllJoyn-Bridge [Todd]

https://gerrit.iotivity.org/gerrit/#/c/17273/

https://gerrit.iotivity.org/gerrit/#/c/17237/

project:iotivity-alljoyn-bridge



Endpoint 

https://gerrit.iotivity.org/gerrit/#/c/10797/



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Saturday, February 04, 2017 4:25 AM
To: 'myeong.jeong at samsung.com'; 'Malsbary, Todd'; ??? (bg.chun at 
samsung.com)
Cc: 'iotivity-dev at lists.iotivity.org'; 'Mitch Kettrick'; 'Agis, Ed'
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Todd/MJ,



All expected features from OCF1.0 has been merged into master branch except 
endpoint and AllJoyn Bridge.

Please let them merge ASAP.

This delay may spoil the overall OCF 1.0 plan.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, February 01, 2017 1:48 PM
To: 'Agis, Ed'; 'myeong.jeong at samsung.com'; 'Malsbary, Todd'; 'Ziran Sun'
Cc: 'iotivity-dev at lists.iotivity.org'; 'Mitch Kettrick'
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Ed, Thank for your answer.



Hi, Antu(IoTivity QA Lead)

Could you prepare the iotivity simulator in advance to shorten testing time? 
You can get not merged patches by cherry-picking.

IoTivity against CTT requires Simulator Application using IoTivity Framework as 
library.

As far as I guess, new addition such as AllJoyn-bridge will requires addition 
implementation on Simulator side.



BR, Uze Choi

From: Agis, Ed [mailto:ed.a...@intel.com] 
Sent: Wednesday, February 01, 2017 11:24 AM
To: uzchoi at samsung.com; myeong.jeong at samsung.com; Malsbary, Todd; 'Ziran 
Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



   Hello Uze, thank you for reaching out to CWG.  We had a call today with 
Comarch and as you have noted, we are behind with the date originally 
committed.  The merge needs to be completed before end of day this Thursday, so 
we can continue to drive for our joint alignment in preparation of the IoTivity 
engineering snap shot and our CTT release for use at the Plugfest, so we can 
also allow plugfest participants sufficient time to upload the stack that we 
will test with.  



Best regards,

Ed 



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 6:01 PM
To: myeong.jeong at samsung.com; Malsbary, Todd ; 
'Ziran Sun' 
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick ; Agis, Ed 
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Todd/MJ/Ziran,



Could you share when your commit to be merged by?

It was supposed to be done by End of Jan.

Currently, IoTivity QA are waiting for your source code merge.



Ed, any dead timeline for this schedule from CWG view?



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 4:43 PM
To: 'myeong.jeong at samsung.com'; 'DWARKAPRASAD DAYAMA'; 'Malsbary, Todd'; 
'Heldt-Sheller, Nathan'; 'Srikrishna Gurugubelli'; 'Ziran Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick (cpm at 
openconnectivity.org); 'Agis, Ed' (Ed.Agis at intel.com)
Subject: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Each OCF 1.0 feature implementer,



By Jan, we had expected to finalized the OCF1.0 feature merge except security. 
This is the current status.

-  AllJoyn Bridge (Todd)

   
https://gerrit.iotivity.org/gerrit/#/q/status:merged+project:iotivity-alljoyn-bridge+branch:wip
  - Not Merged to master yet


 
https://gerrit.iotivity.org/gerrit/#/q/project:iotivity+owner:%22Todd+Malsbary+%253Ctodd.malsbary%2540intel.com%253E%22+status:pending
  - not merged yet

-  Introspection

 
https://gerrit.iotivity.org/gerrit/#/c/16405/   - Merged

-  Endpoint Information (MJ)

 
https://gerrit.iotivity.org/gerrit/#/c/14123/ -  Reviewing

  
https://gerrit.iotivity.org/gerrit/#/c/10797/ -  Reviewing

-  Versioning (Ziran)

 
https://gerrit.iotivity.org/gerrit/#/c/16505/   - Reviewing

-  OCF 1.0 Security

   Not yet.

[dev] iotivity server-client communication (linux and android)

[최우제 (Uze Choi)]

Hi Choi,

I guess this is mostly due to UDP port blocking in your Wi-Fi AP.

If possible you can configure to allow UDP IPv4_MULTICAST_PORT 5683 for IPv4.

In case of Ethernet network, you probably can communicate each other.

BR, Uze Choi

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ???(??)
Sent: Tuesday, February 07, 2017 11:53 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] iotivity server-client communication (linux and android)



Hi,

I'm trying to work on the iotivity server-client communication,

But I could not make it work,

And it would be so great if you could give help or advises.



The server runs on android (java sdk) and the client runs on linux (Ubuntu, 
C++) platform.

I tried running them in the same Wi-Fi network,

but the client couldn't find the server resource.

Even when I tried to search the server with the server IP address,

it still couldn't find it.



Does anyone know how to connect these two devices, or

is there any documentation that I can refer to?



Thank you in advance :)

-- next part --
HTML ?? ??...
URL: 

[dev] [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status

[최우제 (Uze Choi)]

Hi Todd/MJ,



All expected features from OCF1.0 has been merged into master branch except 
endpoint and AllJoyn Bridge.

Please let them merge ASAP.

This delay may spoil the overall OCF 1.0 plan.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, February 01, 2017 1:48 PM
To: 'Agis, Ed'; 'myeong.jeong at samsung.com'; 'Malsbary, Todd'; 'Ziran Sun'
Cc: 'iotivity-dev at lists.iotivity.org'; 'Mitch Kettrick'
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Ed, Thank for your answer.



Hi, Antu(IoTivity QA Lead)

Could you prepare the iotivity simulator in advance to shorten testing time? 
You can get not merged patches by cherry-picking.

IoTivity against CTT requires Simulator Application using IoTivity Framework as 
library.

As far as I guess, new addition such as AllJoyn-bridge will requires addition 
implementation on Simulator side.



BR, Uze Choi

From: Agis, Ed [mailto:ed.a...@intel.com] 
Sent: Wednesday, February 01, 2017 11:24 AM
To: uzchoi at samsung.com; myeong.jeong at samsung.com; Malsbary, Todd; 'Ziran 
Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



   Hello Uze, thank you for reaching out to CWG.  We had a call today with 
Comarch and as you have noted, we are behind with the date originally 
committed.  The merge needs to be completed before end of day this Thursday, so 
we can continue to drive for our joint alignment in preparation of the IoTivity 
engineering snap shot and our CTT release for use at the Plugfest, so we can 
also allow plugfest participants sufficient time to upload the stack that we 
will test with.  



Best regards,

Ed 



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 6:01 PM
To: myeong.jeong at samsung.com; Malsbary, Todd ; 
'Ziran Sun' 
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick ; Agis, Ed 
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Todd/MJ/Ziran,



Could you share when your commit to be merged by?

It was supposed to be done by End of Jan.

Currently, IoTivity QA are waiting for your source code merge.



Ed, any dead timeline for this schedule from CWG view?



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 4:43 PM
To: 'myeong.jeong at samsung.com'; 'DWARKAPRASAD DAYAMA'; 'Malsbary, Todd'; 
'Heldt-Sheller, Nathan'; 'Srikrishna Gurugubelli'; 'Ziran Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick (cpm at 
openconnectivity.org); 'Agis, Ed' (Ed.Agis at intel.com)
Subject: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Each OCF 1.0 feature implementer,



By Jan, we had expected to finalized the OCF1.0 feature merge except security. 
This is the current status.

-  AllJoyn Bridge (Todd)

   
https://gerrit.iotivity.org/gerrit/#/q/status:merged+project:iotivity-alljoyn-bridge+branch:wip
  - Not Merged to master yet


 
https://gerrit.iotivity.org/gerrit/#/q/project:iotivity+owner:%22Todd+Malsbary+%253Ctodd.malsbary%2540intel.com%253E%22+status:pending
  - not merged yet

-  Introspection

 
https://gerrit.iotivity.org/gerrit/#/c/16405/   - Merged

-  Endpoint Information (MJ)

 
https://gerrit.iotivity.org/gerrit/#/c/14123/ -  Reviewing

  
https://gerrit.iotivity.org/gerrit/#/c/10797/ -  Reviewing

-  Versioning (Ziran)

 
https://gerrit.iotivity.org/gerrit/#/c/16505/   - Reviewing

-  OCF 1.0 Security

   Not yet.



To prepare the upcoming plugfest, 

I?d like to create the tag to test start (Release Lead),
Start the Test against the OCF CTT by IoTivity QA team.



However, there are still some missed part from OCF1.0 feature. (Todd, MJ, Ziran)

Please merge them ASAP and notify for test start.



BR, Uze Choi

From: MyeongGi Jeong [mailto:myeong.je...@samsung.com] 
Sent: Wednesday, January 25, 2017 11:31 AM
To: DWARKAPRASAD DAYAMA; 'Malsbary, Todd'; 'Heldt-Sheller, Nathan'; 'Srikrishna 
Gurugubelli'; Ziran Sun
Cc: Uze Choi
Subject: RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation 
status



Hi, Dwarka.

Actually, EndPoint implementation is finished.

But 2 patchsets are still staying in gerrit code-review.

 

[dev] Proposed Design Approach for [IOT-1379] Multi-Device Support

[최우제 (Uze Choi)]

Hi Dave,

Diagram will help us understood more easily. Posting into IoTivity wiki is
good starting.

Anyway, Let me correct my understand has difference from yours.

For each additional logical device, additional CA stack will be initiated
with OCLocalDeviceHandle.

OCLocalDeviceHandle may be associated with resource handles for its logical
device.

>From Security perspective, multiple ownership transfer should be executed,
which is cumbersome step.

Do you think IoTivity should have multiple sockets for TCP case? It looks
inefficient, multiplexer can be clue to resolve this issue which is same
practice in IoTivity BLE GATT implementation.

Regarding OCDevAddr, Let think about adding the other info also such as
zone id.

BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Dave Thaler via iotivity-dev
Sent: Thursday, February 02, 2017 10:26 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Proposed Design Approach for [IOT-1379] Multi-Device Support



Here's a summary of how I propose this be solved.  Let me know if you see
issues, or have additions since there may be some things I'm forgetting
below.



The primary problem is that local device state is currently global, and it
instead needs to be dynamically allocatable so that there can be multiple
instances.



A secondary problem is the duplication of types between the stack layer and
the connectivity abstraction layer.  Indeed, cacommon.h already contains
the implied todo statement "The CA layer should used the OC types when
build allows that."   The duplication of types prevents type-safety
(because nothing guarantees they match at compile time, you just hope the
tests would fail if someone does something wrong), and causes code to be
less readable due to type casts.   Finally, it causes developer headaches
trying to get the includes and include paths right.



Here's a list of some of the key things that need to be moved from global
to per-local-device-state:

? Port # configuration

? Set of sockets

? Handles to well-known resources (platform, device,
introspection, doxm, pstat, pconf, etc.)

? Security state per well-known security resource (OicSec_Acl_t,
Oic_Sec_Amacl_t, OicSecDoxm_t, etc.)

? Presence state, if WITH_PRESENCE is defined

? ServerResponseTree



Proposed design details:

? In the public octypes.h file used by apps, define an opaque
OCLocalDeviceHandle for use with new "public" APIs (i.e., ones published
into the out/ directory and meant to be callable from apps).

? There will automatically be 1 default local device, such that
all existing public APIs continue to work unmodified.  Only apps that want
to use multiple devices will need to use additional APIs.   Thus, existing
app compat is preserved.

? Add new public APIs (or overloads or optional args in some of
the C++ cases) that accept a local device handle, and new APIs to
add/delete a new local device other than the default one.

? Put previously global but device-specific CA-layer state (like
sockets) into a new structure called, say, CALocalDeviceState_t.

? Put previously global but device-specific stack-layer state
(like security) into a new structure called, say, OCLocalDeviceState.

? Create a new common internal CALocalDevice_t structure in
cacommon.h (where CAGlobals_t already is, so it can be used from both
layers) which contains a pointer to struct CALocalDeviceState, and a
pointer to struct OCLocalDeviceState.  OCLocalDeviceHandle would then be a
public opaque pointer to CALocalDevice_t.

? Rename resource\csdk\stack\include\internal\ocresource.h to
ocresourceinternal.h to prevent confusion (e.g., in source debugging) with
resource\include\OCResource.h on case-insensitive filesystems.   This
follows the naming precedent of ocstack.h vs ocstackinternal.h.  Note that
we cannot rename OCResource.h to OCResource.hpp because it's a public file
and that would break apps.

? To reduce the number of internal APIs that would have to pass
around another pointer, add a field with the CALocalDevice_t pointer into a
couple existing private structs that are commonly passed around (potential
examples: SslEndpoint_t, OCProvisionDev_t, OCServerRequest, DiscoveryInfo).
Question: Do we think it's ok to extend OCDevAddr with a field at the end?
If OCDevAddr is never allocated by an app and passed into the stack, it
would be safe.  If it could be allocated by an app and passed into the
stack, it is not safe to extend since it would break backwards
compatibility. If it can be extended, it's less changes to various APIs,
but it seems more risky to me.



Dave

-- next part --
HTML ?? ??...
URL: 

[dev] WITH_PRESENCE

[최우제 (Uze Choi)]

+1 for a) option.



Initially, it was the additional option to consider the constraint device.

Iotivity open source has another stack for constrained device.

Remove this MACRO will be better option I propose. Additionally, we need to
minimize the build MACRO as much as possible.



BR, Uze Choi

From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Dave Thaler via iotivity-dev
Sent: Thursday, February 02, 2017 10:21 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] WITH_PRESENCE



Why is WITH_PRESENCE always #define'd in the public octypes.h and then
other files #ifdef to check it? 

Seems like we should either 

a)   delete all the ifdef's and assume it's always there, or 

b)  octypes.h should not define it and it should be another compiler
option like we have for TCP, etc.



Dave

-- next part --
HTML ?? ??...
URL: 

[dev] [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status

[최우제 (Uze Choi)]

Ed, Thank for your answer.



Hi, Antu(IoTivity QA Lead)

Could you prepare the iotivity simulator in advance to shorten testing time? 
You can get not merged patches by cherry-picking.

IoTivity against CTT requires Simulator Application using IoTivity Framework as 
library.

As far as I guess, new addition such as AllJoyn-bridge will requires addition 
implementation on Simulator side.



BR, Uze Choi

From: Agis, Ed [mailto:ed.a...@intel.com] 
Sent: Wednesday, February 01, 2017 11:24 AM
To: uzchoi at samsung.com; myeong.jeong at samsung.com; Malsbary, Todd; 'Ziran 
Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



   Hello Uze, thank you for reaching out to CWG.  We had a call today with 
Comarch and as you have noted, we are behind with the date originally 
committed.  The merge needs to be completed before end of day this Thursday, so 
we can continue to drive for our joint alignment in preparation of the IoTivity 
engineering snap shot and our CTT release for use at the Plugfest, so we can 
also allow plugfest participants sufficient time to upload the stack that we 
will test with.  



Best regards,

Ed 



From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 6:01 PM
To: myeong.jeong at samsung.com; Malsbary, Todd ; 
'Ziran Sun' 
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick ; Agis, Ed 
Subject: RE: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Todd/MJ/Ziran,



Could you share when your commit to be merged by?

It was supposed to be done by End of Jan.

Currently, IoTivity QA are waiting for your source code merge.



Ed, any dead timeline for this schedule from CWG view?



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 4:43 PM
To: 'myeong.jeong at samsung.com'; 'DWARKAPRASAD DAYAMA'; 'Malsbary, Todd'; 
'Heldt-Sheller, Nathan'; 'Srikrishna Gurugubelli'; 'Ziran Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick (cpm at 
openconnectivity.org); 'Agis, Ed' (Ed.Agis at intel.com)
Subject: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Each OCF 1.0 feature implementer,



By Jan, we had expected to finalized the OCF1.0 feature merge except security. 
This is the current status.

-  AllJoyn Bridge (Todd)

   
https://gerrit.iotivity.org/gerrit/#/q/status:merged+project:iotivity-alljoyn-bridge+branch:wip
  - Not Merged to master yet


 
https://gerrit.iotivity.org/gerrit/#/q/project:iotivity+owner:%22Todd+Malsbary+%253Ctodd.malsbary%2540intel.com%253E%22+status:pending
  - not merged yet

-  Introspection

 
https://gerrit.iotivity.org/gerrit/#/c/16405/   - Merged

-  Endpoint Information (MJ)

 
https://gerrit.iotivity.org/gerrit/#/c/14123/ -  Reviewing

  
https://gerrit.iotivity.org/gerrit/#/c/10797/ -  Reviewing

-  Versioning (Ziran)

 
https://gerrit.iotivity.org/gerrit/#/c/16505/   - Reviewing

-  OCF 1.0 Security

   Not yet.



To prepare the upcoming plugfest, 

I?d like to create the tag to test start (Release Lead),
Start the Test against the OCF CTT by IoTivity QA team.



However, there are still some missed part from OCF1.0 feature. (Todd, MJ, Ziran)

Please merge them ASAP and notify for test start.



BR, Uze Choi

From: MyeongGi Jeong [mailto:myeong.je...@samsung.com] 
Sent: Wednesday, January 25, 2017 11:31 AM
To: DWARKAPRASAD DAYAMA; 'Malsbary, Todd'; 'Heldt-Sheller, Nathan'; 'Srikrishna 
Gurugubelli'; Ziran Sun
Cc: Uze Choi
Subject: RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation 
status



Hi, Dwarka.

Actually, EndPoint implementation is finished.

But 2 patchsets are still staying in gerrit code-review.

  
https://gerrit.iotivity.org/gerrit/#/c/14123/

  
https://gerrit.iotivity.org/gerrit/#/c/10797/

I guess, the arguing point is related the conceptual issue, not the technical 
one.( for the first patchset )

And the second one, Jenkins build returned failure by some memory leakage, but 
it is not related this patchset.



Thanks.

Best Regards,

--- 

MyeongGi Jeong

Principle Engineer, Software Architect

Software R Center, Samsung Electronics Co., Ltd.

+82-10-3328-1130 | +82-2-6147-7699

[dev] [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status

[최우제 (Uze Choi)]

Hi Todd/MJ/Ziran,



Could you share when your commit to be merged by?

It was supposed to be done by End of Jan.

Currently, IoTivity QA are waiting for your source code merge.



Ed, any dead timeline for this schedule from CWG view?

BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Tuesday, January 31, 2017 4:43 PM
To: 'myeong.jeong at samsung.com'; 'DWARKAPRASAD DAYAMA'; 'Malsbary, Todd'; 
'Heldt-Sheller, Nathan'; 'Srikrishna Gurugubelli'; 'Ziran Sun'
Cc: iotivity-dev at lists.iotivity.org; Mitch Kettrick (cpm at 
openconnectivity.org); 'Agis, Ed' (Ed.Agis at intel.com)
Subject: [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] 
[Follow Up] OCF 1.0 implementation status



Hi Each OCF 1.0 feature implementer,



By Jan, we had expected to finalized the OCF1.0 feature merge except security. 
This is the current status.

-  AllJoyn Bridge (Todd)

   
https://gerrit.iotivity.org/gerrit/#/q/status:merged+project:iotivity-alljoyn-bridge+branch:wip
  - Not Merged to master yet


 
https://gerrit.iotivity.org/gerrit/#/q/project:iotivity+owner:%22Todd+Malsbary+%253Ctodd.malsbary%2540intel.com%253E%22+status:pending
  - not merged yet

-  Introspection

 
https://gerrit.iotivity.org/gerrit/#/c/16405/   - Merged

-  Endpoint Information (MJ)

 
https://gerrit.iotivity.org/gerrit/#/c/14123/ -  Reviewing

  
https://gerrit.iotivity.org/gerrit/#/c/10797/ -  Reviewing

-  Versioning (Ziran)

 
https://gerrit.iotivity.org/gerrit/#/c/16505/   - Reviewing

-  OCF 1.0 Security

   Not yet.



To prepare the upcoming plugfest, 

I?d like to create the tag to test start (Release Lead),
Start the Test against the OCF CTT by IoTivity QA team.



However, there are still some missed part from OCF1.0 feature. (Todd, MJ, Ziran)

Please merge them ASAP and notify for test start.



BR, Uze Choi

From: MyeongGi Jeong [mailto:myeong.je...@samsung.com] 
Sent: Wednesday, January 25, 2017 11:31 AM
To: DWARKAPRASAD DAYAMA; 'Malsbary, Todd'; 'Heldt-Sheller, Nathan'; 'Srikrishna 
Gurugubelli'; Ziran Sun
Cc: Uze Choi
Subject: RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation 
status



Hi, Dwarka.

Actually, EndPoint implementation is finished.

But 2 patchsets are still staying in gerrit code-review.

  
https://gerrit.iotivity.org/gerrit/#/c/14123/

  
https://gerrit.iotivity.org/gerrit/#/c/10797/

I guess, the arguing point is related the conceptual issue, not the technical 
one.( for the first patchset )

And the second one, Jenkins build returned failure by some memory leakage, but 
it is not related this patchset.



Thanks.

Best Regards,

--- 

MyeongGi Jeong

Principle Engineer, Software Architect

Software R Center, Samsung Electronics Co., Ltd.

+82-10-3328-1130 | +82-2-6147-7699





- Original Message -

Sender :   ??/??(S/W??)/

Date : 2017-01-24 16:03 (GMT+9)

Title : [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status



Hi OCF 1.0 Contributors,



IoTivity release management function lead is ready to create a tag for upcoming 
PF in Feb?17. It will be helpful to know the status in regard to Gerrit code / 
patch for each of these items.



-  AllJoyn Bridge

-  Introspection

-  Endpoint Information

-  Versioning

-  OCF 1.0 Security



Starting Thursday, Korea has national holidays until next Tuesday. Hence we 
should start the process at earliest.




Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair

Iotivity Steering Group ? Advisory Committee





From: ??? [mailto:jinc...@samsung.com] 
Sent: Wednesday, January 18, 2017 10:46 AM
To: Malsbary, Todd ; ??? ; 
 ; 'Srikrishna Gurugubelli' ; Ziran Sun ; Habib Virji ; ??? ; 'Dino Natucci' 
; Morrow, Joseph L ; Shetty, Mandeep ; jinchoe at 
gmail.com; dthaler at microsoft.com; Ram.Jeyaraman at microsoft.com
Cc: Heldt-Sheller, Nathan ; ??? 
; ??? ; Mark Trayer 
; Kesavan, Vijay S ; ??? 

Subject: RE: RE: RE: [Follow Up] OCF 1.0 implementation status



Todd

relieved. 
yes, the OIC 1.1 client section still holds. 

OCF 1.0 server differentiates /oic/res responses per requesting Client, 
which indicates its preference with content-type 
(e.g. 

[dev] [Next release Schedule update] RE: Feature list request for Upcomming IoTivity release.

[최우제 (Uze Choi)]

Hi Rick,



Thank for your questioning.

I expect to be no more release from 1.2-rel branch after 1.2.1 release.

However, some but fix on the scope of 1.2.1-release will be on the 1.2-rel.

Developer should selectively pick up from patches after 1.2.1-release for their 
product.



The patch on 1.2-rel after 1.2.1-release should be adopted into the master 
branch. Maintainers should take care of it for their section.

However unfortunately, something have been missed I guess.

Anyway, 1.3-rel branch will be created from master at the end of Feb. with the 
new feature for OCF1.0 spec alignment.



BR, Uze Choi

From: Bell, Richard S [mailto:richard.s.b...@intel.com] 
Sent: Wednesday, February 01, 2017 4:54 AM
To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] [Next release Schedule update] RE: Feature list request for 
Upcomming IoTivity release.



Uze,

Couple clarifications.

What about all the back porting and changes that have occurred to 1.2 branch 
after the release 1.2.1?

So the only official IoTivity release is 1.2.1 should be used and not master of 
1.2 branch.

People should only use the iotivity-1.2.1 
  release tar or zip files 
or 1.2.1 tag not any 1.2.1-RCx or latest on master.



Thanks,

-Rick









From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Monday, January 30, 2017 10:31 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] [Next release Schedule update] RE: Feature list request for 
Upcomming IoTivity release.



Hi All,



>From the last ISG meeting, two topics are cleared as below.

- 1.2.2 release request has been cancelled. 

- next version aligning to OCF1.0 will be 1.3.0 rather than 2.0.0



Furthermore, as some people already know about it,

release schedule has been adjusted by one week discussion with CWG and IoTivity 
Release lead as follows

This is for the better alignment with OCF CTT tool.

- 1.3.0 : May. (OCF1.0) 

- 1.4.0 : Oct (OCF1.1)



Please check the detail from link https://wiki.iotivity.org/1.3_release_plan 



In conclusion, close of call for proposal for IoTivity feature will be 
suspended by Feb.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, January 18, 2017 9:11 PM
To: iotivity-dev at lists.iotivity.org
Subject: Feature list request for Upcomming IoTivity release.



Hi IoTivity feature developers,



This year IoTivity has a release milestone one is in April and the other is in 
Oct except patch version release.

One is for alignment for OCF1.0 spec and OCF CTT (beta or other version) and

The other is for OCF 1.1 spec including spec compliant easy-setup, cloud and 
some new features.



According to the IoTivity Release process 
(https://wiki.iotivity.org/release_process), I?d like to receive the feature 
list by this week.

Please update it on https://wiki.iotivity.org/2.0_release_plan and register 
into jira(some items are already done)



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [OCF1.0 feature merge request] RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status

[최우제 (Uze Choi)]

Hi Each OCF 1.0 feature implementer,



By Jan, we had expected to finalized the OCF1.0 feature merge except security. 
This is the current status.

-  AllJoyn Bridge (Todd)

   
https://gerrit.iotivity.org/gerrit/#/q/status:merged+project:iotivity-alljoyn-bridge+branch:wip
  - Not Merged to master yet


 
https://gerrit.iotivity.org/gerrit/#/q/project:iotivity+owner:%22Todd+Malsbary+%253Ctodd.malsbary%2540intel.com%253E%22+status:pending
  - not merged yet

-  Introspection

 
https://gerrit.iotivity.org/gerrit/#/c/16405/   - Merged

-  Endpoint Information (MJ)

 
https://gerrit.iotivity.org/gerrit/#/c/14123/ -  Reviewing

  
https://gerrit.iotivity.org/gerrit/#/c/10797/ -  Reviewing

-  Versioning (Ziran)

 
https://gerrit.iotivity.org/gerrit/#/c/16505/   - Reviewing

-  OCF 1.0 Security

   Not yet.



To prepare the upcoming plugfest, 

I?d like to create the tag to test start (Release Lead),
Start the Test against the OCF CTT by IoTivity QA team.



However, there are still some missed part from OCF1.0 feature. (Todd, MJ, Ziran)

Please merge them ASAP and notify for test start.



BR, Uze Choi

From: MyeongGi Jeong [mailto:myeong.je...@samsung.com] 
Sent: Wednesday, January 25, 2017 11:31 AM
To: DWARKAPRASAD DAYAMA; 'Malsbary, Todd'; 'Heldt-Sheller, Nathan'; 'Srikrishna 
Gurugubelli'; Ziran Sun
Cc: Uze Choi
Subject: RE: [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation 
status



Hi, Dwarka.

Actually, EndPoint implementation is finished.

But 2 patchsets are still staying in gerrit code-review.

  
https://gerrit.iotivity.org/gerrit/#/c/14123/

  
https://gerrit.iotivity.org/gerrit/#/c/10797/

I guess, the arguing point is related the conceptual issue, not the technical 
one.( for the first patchset )

And the second one, Jenkins build returned failure by some memory leakage, but 
it is not related this patchset.



Thanks.

Best Regards,

--- 

MyeongGi Jeong

Principle Engineer, Software Architect

Software R Center, Samsung Electronics Co., Ltd.

+82-10-3328-1130 | +82-2-6147-7699





- Original Message -

Sender :   ??/??(S/W??)/

Date : 2017-01-24 16:03 (GMT+9)

Title : [Ziran, Todd, Sri, MJ, Nathan] [Follow Up] OCF 1.0 implementation status



Hi OCF 1.0 Contributors,



IoTivity release management function lead is ready to create a tag for upcoming 
PF in Feb?17. It will be helpful to know the status in regard to Gerrit code / 
patch for each of these items.



-  AllJoyn Bridge

-  Introspection

-  Endpoint Information

-  Versioning

-  OCF 1.0 Security



Starting Thursday, Korea has national holidays until next Tuesday. Hence we 
should start the process at earliest.




Regards

Dwarka

--

Software R Center | Software Strategy Team | Open Source Group

Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair

Iotivity Steering Group ? Advisory Committee





From: ??? [mailto:jinc...@samsung.com] 
Sent: Wednesday, January 18, 2017 10:46 AM
To: Malsbary, Todd ; ??? ; 
 ; 'Srikrishna Gurugubelli' ; Ziran Sun ; Habib Virji ; ??? ; 'Dino Natucci' 
; Morrow, Joseph L ; Shetty, Mandeep ; jinchoe at 
gmail.com; dthaler at microsoft.com; Ram.Jeyaraman at microsoft.com
Cc: Heldt-Sheller, Nathan ; ??? 
; ??? ; Mark Trayer 
; Kesavan, Vijay S ; ??? 

Subject: RE: RE: RE: [Follow Up] OCF 1.0 implementation status



Todd

relieved. 
yes, the OIC 1.1 client section still holds. 

OCF 1.0 server differentiates /oic/res responses per requesting Client, 
which indicates its preference with content-type 
(e.g. /application/vnd.ocf+cbor for OCF 1.0 Client).

best regards

JinHyeock 



- Original Message -

Sender : Malsbary, Todd <  todd.malsbary at 
intel.com>

Date : 2017-01-18 02:14 (GMT+9)

Title : RE: RE: [Follow Up] OCF 1.0 implementation status

To : ???<  jinchoe at samsung.com>, ???< 
 uzchoi at samsung.com>, < 
 dwarka.dayama at samsung.com>, 
'Srikrishna Gurugubelli'<  srikguru at 
microsoft.com>, Ziran Sun<  ziran.sun at 
samsung.com>, Habib Virji<  habib.virji at 

[dev] [Next release Schedule update] RE: Feature list request for Upcomming IoTivity release.

[최우제 (Uze Choi)]

Hi All,



>From the last ISG meeting, two topics are cleared as below.

- 1.2.2 release request has been cancelled. 

- next version aligning to OCF1.0 will be 1.3.0 rather than 2.0.0



Furthermore, as some people already know about it,

release schedule has been adjusted by one week discussion with CWG and IoTivity 
Release lead as follows

This is for the better alignment with OCF CTT tool.

- 1.3.0 : May. (OCF1.0) 

- 1.4.0 : Oct (OCF1.1)



Please check the detail from link https://wiki.iotivity.org/1.3_release_plan 



In conclusion, close of call for proposal for IoTivity feature will be 
suspended by Feb.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, January 18, 2017 9:11 PM
To: iotivity-dev at lists.iotivity.org
Subject: Feature list request for Upcomming IoTivity release.



Hi IoTivity feature developers,



This year IoTivity has a release milestone one is in April and the other is in 
Oct except patch version release.

One is for alignment for OCF1.0 spec and OCF CTT (beta or other version) and

The other is for OCF 1.1 spec including spec compliant easy-setup, cloud and 
some new features.



According to the IoTivity Release process 
(https://wiki.iotivity.org/release_process), I?d like to receive the feature 
list by this week.

Please update it on https://wiki.iotivity.org/2.0_release_plan and register 
into jira(some items are already done)



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] [milestone Engineering Snapshot #1] RE: Another IoTivity milestone for ISO/IEC submission.

[최우제 (Uze Choi)]

Hi IoTivity?er



As I noticed before thru below email.

OCF feature will be on the Iotivity master branch by End of January. Currently 
Dwarka is checking whether these are in IoTivity.

Once they are done, let me make the tag with ?OCF1.0 Engineering snapshot #1?.

This iotivity code will be tested against new OCF CTT tool by IoTivity QA team.



Regarding detail milestone, please check below.

https://wiki.iotivity.org ?   
IoTivity 1.3.0 release plan



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Friday, January 20, 2017 2:22 PM
To: iotivity-dev at lists.iotivity.org
Subject: Another IoTivity milestone for ISO/IEC submission.



Hi All,



OCF has decided to submit the OCF specification into ISO/IEC.

OCF specification needs verification from open source implementation prior to 
submission deadline, May.

Once it is verified from implementation perspective, OCF need to have IPR 
review.

In conclusion, OCF specification should be verified thru cross check between 
open source implementation and OCF certification tool by Fed.



OCF requested a testable IoTivity code including additional features from 
OCF1.0 such as versioning, introspection, endpoint and some security updates.

Let me check whether these features are coming inside into the IoTivity by Jan. 
Then I?ll create the tag on master branch.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, January 18, 2017 9:11 PM
To: iotivity-dev at lists.iotivity.org
Subject: Feature list request for Upcomming IoTivity release.



Hi IoTivity feature developers,



This year IoTivity has a release milestone one is in April and the other is in 
Oct except patch version release.

One is for alignment for OCF1.0 spec and OCF CTT (beta or other version) and

The other is for OCF 1.1 spec including spec compliant easy-setup, cloud and 
some new features.



According to the IoTivity Release process 
(https://wiki.iotivity.org/release_process), I?d like to receive the feature 
list by this week.

Please update it on https://wiki.iotivity.org/2.0_release_plan and register 
into jira(some items are already done)



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Another IoTivity milestone for ISO/IEC submission.

[최우제 (Uze Choi)]

Hi All,



OCF has decided to submit the OCF specification into ISO/IEC.

OCF specification needs verification from open source implementation prior
to submission deadline, May.

Once it is verified from implementation perspective, OCF need to have IPR
review.

In conclusion, OCF specification should be verified thru cross check
between open source implementation and OCF certification tool by Fed.



OCF requested a testable IoTivity code including additional features from
OCF1.0 such as versioning, introspection, endpoint and some security
updates.

Let me check whether these features are coming inside into the IoTivity by
Jan. Then I?ll create the tag on master branch.



BR, Uze Choi

From: ??? (Uze Choi) [mailto:uzc...@samsung.com] 
Sent: Wednesday, January 18, 2017 9:11 PM
To: iotivity-dev at lists.iotivity.org
Subject: Feature list request for Upcomming IoTivity release.



Hi IoTivity feature developers,



This year IoTivity has a release milestone one is in April and the other is
in Oct except patch version release.

One is for alignment for OCF1.0 spec and OCF CTT (beta or other version) and

The other is for OCF 1.1 spec including spec compliant easy-setup, cloud
and some new features.



According to the IoTivity Release process
(https://wiki.iotivity.org/release_process), I?d like to receive the
feature list by this week.

Please update it on https://wiki.iotivity.org/2.0_release_plan and register
into jira(some items are already done)



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] IoTivity bridging solution

[최우제 (Uze Choi)]

Thanks, could you share the link for it.
Today bridge project has been approved from the ISG meeting, it will be 
announced soon.
BR, Uze Choi
-Original Message-
From: Morrow, Joseph L [mailto:joseph.l.mor...@intel.com] 
Sent: Friday, January 20, 2017 11:24 AM
To: uzchoi at samsung.com; Macieira, Thiago; iotivity-dev at lists.iotivity.org
Cc: Shetty, Mandeep; Malsbary, Todd
Subject: RE: [dev] IoTivity bridging solution

Hi Uze,

We've already started posting the necessary documentation to the IoTivity Wiki.

Thanks,

Joey Morrow

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? (Uze Choi)
Sent: Tuesday, January 17, 2017 10:20 PM
To: Macieira, Thiago ; iotivity-dev at 
lists.iotivity.org
Subject: Re: [dev] IoTivity bridging solution

posting into iotivity wiki will be recommended way for each feature.

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Wednesday, January 18, 2017 4:10 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] IoTivity bridging solution

Em ter?a-feira, 17 de janeiro de 2017, ?s 05:54:42 PST, Kesavan, Vijay S
escreveu:
> Hi,
> 
> In order to provide a comprehensive and scalable bridging solution for 
> IoTivity the proposal is to start a bridging project encompassing 
> bridging framework, sample bridges, tools for bridge developers etc.
> Initially there will be bridges to non-OCF ecosystems like ZigBee and 
> non-OCF devices like lights, thermostats etc. and the same will be 
> extended to bridge OCF with UPnP and AllJoyn as well.  With this in 
> mind, we propose creating a 'bridge' directory for initial 
> contributions and this will be at the same level as 'resources' and 
> 'services'.  Request the stakeholder to approve this.

Hi Vijay

Can you share an overview of the architecture too? If you have details of the 
implementation, that would also be welcome.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
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

[dev] Feature list request for Upcomming IoTivity release.

[최우제 (Uze Choi)]

Hi IoTivity feature developers,



This year IoTivity has a release milestone one is in April and the other is
in Oct except patch version release.

One is for alignment for OCF1.0 spec and OCF CTT (beta or other version) and

The other is for OCF 1.1 spec including spec compliant easy-setup, cloud
and some new features.



According to the IoTivity Release process
(https://wiki.iotivity.org/release_process), I?d like to receive the
feature list by this week.

Please update it on https://wiki.iotivity.org/2.0_release_plan and register
into jira(some items are already done)



BR, Uze Choi

-- next part --
HTML ?? ??...
URL: 

[dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder

[최우제 (Uze Choi)]

Hi Pawel,



Throw exception is what I suggested first as ?Filtering During casting?.

This requires 32bit limit for Integer as specification at least, I think.



if (no API break > better performance by half memory for int), C Layer
still use int_64t is OK.



BR, Uze Choi

From: Pawel Winogrodzki [mailto:pawe...@microsoft.com] 
Sent: Wednesday, January 18, 2017 11:23 AM
To: ??? (Uze Choi); 'Thiago Macieira'; Dave Thaler
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder



After discussing the issue with   @Dave
Thaler, I have another proposal regarding the possible data loss issue in
my previous e-mail: instead of blindly casting we?d throw an exception for
out of range values. This way the API surface will remain backward
compatible and we will only specify the API?s behavior for invalid values.



What do you think?



Thanks,

Pawel



From: Pawel Winogrodzki 
Sent: Tuesday, January 17, 2017 01:41
To: ??? (Uze Choi) ; 'Thiago Macieira'

Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder



Hi Uze,



I see your point, that retuning zero for values beyond what 32-bit integers
can hold is not the same with current behavior. Currently, if you set
OCRepresentation from OCRepPayload containing a too large/small 64-bit
integer we just cast it to an ?int? quietly.



My idea in general is to still support regular ?int? type exactly the
same way we?re doing it now from the OCRepresentation callers? point of
view. So the Java APIs won?t need any changes. I want to make
OCRepresentation use the 64-bit value for storage, thus making it possible
to handle values from the two other sources I?ve mentioned, but the 32-bit
get/setValue() can still cast that internal value to an ?int?. This
essentially is the same behavior we see now, if we set the internal 32-bit
integer from a 64-bit one.



In short: 

*   get/setValue will work exactly the same way it used to.
*   There will be an additional get/setValue(), which can be
used in OCF 1.0.



Please let me know, if you see issues with that. Also, I'd appreciate
others? opinion on the topic.



Thanks,

Pawel



From:   ??? (Uze Choi)
Sent: Thursday, January 12, 2017 8:33 PM
To: Pawel Winogrodzki  ; 'Thiago Macieira'
 
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder



Hi Pawel,

Then, I need more correct understanding for following comment.
"BUT  the retrieved value is greater/smaller than INT_MAX/INT_MIN,
getValue() will return the same value it currently does in case of an
error (which is zero)."
How does Greater then INT return same value with INT container??
Or do you mean exception occurring for oversized case?
Anyway, we need to start from the fact to support the 64bit integer, using
 will cause problem.
Considering Java API int_64 is not supported, 32 bit integer support for
IoTivity is the only way.

Let me check cases what can we do without API change. Assuming IoTivity to
support only 32bit int as specification.
If A application put the full 32 bit for integer using C++ API.
 setValue,int> can filter it (we need to additionally implement the
blocking code for oversize with error return)
If A application put the greater 32 bit for integer using C API.
 Then, there is no way to block it. In this case 64 bit integer can be
transmitted into other 32 bit machine. 
 If this 32 bit machine use getValue will cause data lose.

This looks a kind of bug in iotivity. Change API will be only way, I expect.

BR, Uze Choi
-Original Message-
From: Pawel Winogrodzki [ 
mailto:pawelwi at microsoft.com] 
Sent: Friday, January 13, 2017 7:56 AM
To: ??? (Uze Choi); 'Thiago Macieira'
Cc:   iotivity-
dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder

Ok, so it seems there are two main concerns related with fixing my problem:
1. We want to maintain backward compatibility.
2. We want to prepare for OCF 1.0 and be able to support 64 bit
integers.

Here's my proposal:

I'll make OCRepresentation use only int64_t internally. I'll explicitly
write what (get|set)Value() is supposed to do, so that it cast
"int64_t" to "int", BUT  the retrieved value is greater/smaller than
INT_MAX/INT_MIN, getValue() will return the same value it currently
does in case of an error (which is zero).

This way all previous applications will work the way they used to, since
they relied only on "int" anyway, so we shouldn't expect values outside of
this scope. If someone was trying to use other values, then their
applications didn't work properly anyway. Also, anyone 

[dev] IoTivity bridging solution

[최우제 (Uze Choi)]

posting into iotivity wiki will be recommended way for each feature.

-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Wednesday, January 18, 2017 4:10 AM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] IoTivity bridging solution

Em ter?a-feira, 17 de janeiro de 2017, ?s 05:54:42 PST, Kesavan, Vijay S
escreveu:
> Hi,
> 
> In order to provide a comprehensive and scalable bridging solution for 
> IoTivity the proposal is to start a bridging project encompassing 
> bridging framework, sample bridges, tools for bridge developers etc.  
> Initially there will be bridges to non-OCF ecosystems like ZigBee and 
> non-OCF devices like lights, thermostats etc. and the same will be 
> extended to bridge OCF with UPnP and AllJoyn as well.  With this in 
> mind, we propose creating a 'bridge' directory for initial 
> contributions and this will be at the same level as 'resources' and 
> 'services'.  Request the stakeholder to approve this.

Hi Vijay

Can you share an overview of the architecture too? If you have details of the 
implementation, that would also be welcome.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] Ongoing 1.2 development

[최우제 (Uze Choi)]

Hi All,

Let me answer for each topic.

[Release Plan]
Each release requires lots of efforts including merge status verification,
QA and so on.
I'd like to spend the effort for specific purpose especially product
planning friendly.
For eaxmaple, Each release should have some reason as follows.
- IoTivity 1.2.1 version has been released to secure the CTT 1.4 compliant
version for '17 product shipping.
- IoTivity 1.2.2 has been suggested by Microsoft for their product, but not
yet officially requested. Let me ask it to Microsoft in this week ISG
meeting.
- IoTivity 2.0.0 version with OCF 1.0 certification beta version alignment
for plugfest or product preparation.
- IoTivity 2.1.0 version with OCF 1.1 certification version alignment for
plugfest or product preparation.

[1.2 branch]
Based on 1.2 feature (more specifically 1.2.1 code), bug fix should be
patched on 1.2-rel with master merge-back (or vice-versa).
This merge back is maintainer responsibility. Currently Phil is helping and
checking for missed items on master branch.

Additional fix beyond these should be patched only into the master branch.
However, currently patches are merged on 1.2-rel without this criteria or
judgement or judgement is different from each project maintainer.
Previously 1.2-rel merged was reviewed by me but not anymore after 1.2.1
release.
If needed, assign the 1.2-rel branch manager and let them check merge is
acceptable or not.

BR, Uze Choi (Iotivity Release Function Lead)
-Original Message-
From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] 
Sent: Wednesday, January 18, 2017 10:38 AM
To: Mats Wichmann; Philippe Coval; iotivity-dev at lists.iotivity.org;
iotivity-maintainers at lists.iotivity.org
Cc: 'Dwarkaprasad Dayama'; ???(Uze Choi) (uzchoi at samsung.com); Randeep Singh
Subject: RE: [dev] Ongoing 1.2 development

Thanks for bringing this up against Mats, Phil,

I've been asking the same question... the Security features for 2.0 are
being developed against Master where possible, but for the most part, the
changes are still dependent on patches that haven't been cherry picked to
Master.  So we have continued new development on the 1.2-rel branch, which
continues to create more cherry picking/merge work.

We need the maintainers to make this a top priority to bring Master up to
date with 1.2-rel, so that new development can be pushed to Master, or
we're going to have a merge backlog and miss our release dates for IoTivity
2.0.

Thanks,
Nathan Heldt-Sheller
OSWG Security TG Chair


-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Mats Wichmann
Sent: Tuesday, January 17, 2017 8:27 AM
To: Philippe Coval ; iotivity-
dev at lists.iotivity.org; iotivity-maintainers at lists.iotivity.org
Subject: Re: [dev] Ongoing 1.2 development

On 01/17/2017 09:19 AM, Philippe Coval wrote:
> Hi Mats

>> If those are all classed as maintenance that's fine, but it's still 
>> been a little unexpected to see so much traffic after the release.

> It would be nice to release a 1.2.2 too.

I think that's what I was leading to, without ever getting to saying so:
if there have been many changes to 1.2.1, it's hard for people basing their
product work on 1.2.1 to keep track. Seems like we ought to be planning on
1.2.2 to roll up the changes, so there's a clean release.  I know doing
another release is a pain and consumes a fair bit of work, but how else to
be reliably confident the changes get in the hands of the people using 1.2
branch?




___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

[dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder

[최우제 (Uze Choi)]

Hi Pawel,

Then, I need more correct understanding for following comment.
"BUT  the retrieved value is greater/smaller than INT_MAX/INT_MIN,
getValue() will return the same value it currently does in case of an
error (which is zero)."
How does Greater then INT return same value with INT container??
Or do you mean exception occurring for oversized case?
Anyway, we need to start from the fact to support the 64bit integer, using
 will cause problem.
Considering Java API int_64 is not supported, 32 bit integer support for
IoTivity is the only way.

Let me check cases what can we do without API change. Assuming IoTivity to
support only 32bit int as specification.
If A application put the full 32 bit for integer using C++ API.
 setValue,int> can filter it (we need to additionally implement the
blocking code for oversize with error return)
If A application put the greater 32 bit for integer using C API.
 Then, there is no way to block it. In this case 64 bit integer can be
transmitted into other 32 bit machine. 
 If this 32 bit machine use getValue will cause data lose.

This looks a kind of bug in iotivity. Change API will be only way, I expect.

BR, Uze Choi
-Original Message-
From: Pawel Winogrodzki [mailto:pawe...@microsoft.com] 
Sent: Friday, January 13, 2017 7:56 AM
To: ??? (Uze Choi); 'Thiago Macieira'
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder

Ok, so it seems there are two main concerns related with fixing my problem:
1. We want to maintain backward compatibility.
2. We want to prepare for OCF 1.0 and be able to support 64 bit
integers.

Here's my proposal:

I'll make OCRepresentation use only int64_t internally. I'll explicitly
write what (get|set)Value() is supposed to do, so that it cast
"int64_t" to "int", BUT  the retrieved value is greater/smaller than
INT_MAX/INT_MIN, getValue() will return the same value it currently
does in case of an error (which is zero).

This way all previous applications will work the way they used to, since
they relied only on "int" anyway, so we shouldn't expect values outside of
this scope. If someone was trying to use other values, then their
applications didn't work properly anyway. Also, anyone who consciously uses
64-bit value will be able to do so.

What do you think?

Thanks,
Pawel

-Original Message-
From: ??? (Uze Choi) [mailto:uzc...@samsung.com]
Sent: Wednesday, January 11, 2017 19:14
To: 'Thiago Macieira' ; Pawel Winogrodzki

Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder

Proposal to selecting C API had been proposed before but discarded in the
IoTivity initial time.
Now, already IoTivity C and C++ language ecosystems are working and people
are using both.
Let's concentrate on how to correctly support them.

In case of using integer in the 32 bit machine with C++ and Java language,
During casting, data will be lost and especially distorted in case of minus
value.
Changing and limiting into int32_t will be only way to resolve them I think.

Additionally we need to make sure 32 bit size for OCF integer authorized.
If not need more consideration.

BR, Uze Choi
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Thursday, January 12, 2017 4:46 AM
To: Pawel Winogrodzki
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Integer representation in OCRepresentation, OCRepPayload
and cbor encoder

On quarta-feira, 11 de janeiro de 2017 19:41:09 PST Pawel Winogrodzki wrote:
> If the C++ APIs may be modified with disregard to backwards 
> compatibility, then I should be able to switch OCRepresentation to use 
> int64_t as the only supported integer type and thus be compatible with
the rest of the code.
> 
> I would need to know, if there is a IoTivity-wide approval to perform 
> such changes, before I start working on them.

In my opinion, it should. The distinction between the C and the C++ API
exists for reasons that are no longer valid. The C API is too low-level to
the point of being obfuscated, like a function "do" that takes 9
parameters, while the 
C++ API is too high level and does not get enough attention, not to 
C++ mention
that it was designed with intentional disregard for compatibility with
older, 
non-C++11 compilers.

We should have a unified API in one language only -- I understand
Microsoft's preference would be for a C API.

We do need an IoTivity-wide approval for replacement, but we can start
adding one meanwhile, intermediate to the existing two, and leave the
approval to when it's complete and can show its own benefits.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
iotivity-dev mailing list
iotivity-dev at