This was ultimately my understanding, that we don?t to break anything that is currently working. A simple scons TARGET_OS=android should properly build on all branches. It would be up to Pat to decide on this, so I?m awaiting his clarification.
From: ASHOKBABU CHANNA [mailto:[email protected]] Sent: Tuesday, March 31, 2015 5:58 PM To: Keane, Erich; Uze Choi Cc: iotivity-dev at lists.iotivity.org Subject: [API change info sharing request] RE: Change in iotivity[master]: Redefine and implement findResource API Dear Erich, We did not understand how CA android build issue is blocking ?publishing of API changes in base stack?. I think these two are separate issues to deal with. Frankly, if you are ready, you can still go-ahead with publishing the APIs. It helps Primitive services to make changes and be ready for v0.9. Current CA Android build will work fine if glib-gnome is built with ndk-build. We are making it easier by providing the patch file and build instructions. We already responded to Vijay?s mail regarding the integration of two adapters and proposed connectivity name. Regards, Ashok ------- Original Message ------- Sender : Keane, Erich<erich.keane at intel.com> Date : Apr 01, 2015 01:45 (GMT+09:00) Title : Re: [dev] Asking regarding CA Branch merging Detail: [API change info sharing request] RE: Change in iotivity[master]: Redefine and implement findResource API My understanding is that we are still held up on Vijay's list. One significant outstanding item that I see is the Android build on CA, which does not properly build using SCONS, which I believe is considered a blocker. I'd emailed both Ashoks earlier last week, though I didn't hear anything back. On Tue, 2015-03-31 at 19:27 +0900, ???(Uze Choi) wrote: > Hi Pat, > > As far as I know, you will merge the CA code into master at the end of this > week. > For smooth integration, we are now changing the primitive service source code > for changed base layer APIs. > And have the plan to push the code into the CA branch. > However, there are lots of discrepancy between CA and master branch including > bugfix and so on from the primitive service point of view. > > So that I wish you merge the CA code into the master with auto-merge command, > which make sure the latest committed primitive source code into master. > Please share the plan of merge detail. > > BR, Uze Choi > -----Original Message----- > From: ???(Uze Choi) [mailto:uzchoi at samsung.com] > Sent: Monday, March 30, 2015 2:28 PM > To: 'Kesavan, Vijay S' > Cc: 'Lankswert, Patrick'; 'iotivity-dev at lists.iotivity.org' > Subject: RE: [API change info sharing request] RE: Change in > iotivity[master]: Redefine and implement findResource API > > Hi Vijay, > > "Early next week we will send an email to the reflector outlining the changes > and actions that have to be taken by those using the APIs." > >> Could you share the API change context ASAP? > To prepare the April release, primitive service should integrate with > updated base layer by CA branch. > Thank you for your information sharing in advance. > > BR, Uze Choi > -----Original Message----- > From: Kesavan, Vijay S [mailto:vijay.s.kesavan at intel.com] > Sent: Friday, March 20, 2015 9:55 AM > To: uzchoi at samsung.com > Cc: Lankswert, Patrick; iotivity-dev at lists.iotivity.org > Subject: RE: [API change info sharing request] RE: Change in > iotivity[master]: Redefine and implement findResource API > > Uze, > > With regards to your questions, as discussed previously, the first version of > Iotivity with CA will support selecting the connection type in relevant APIs. > Additionally, there will be support to distinguish the same resource > discovered on multiple interfaces using a unique identifier, the server ID. > These features along with sample applications are already implemented in the > CA branch. > > Yes, there are differences between the master and CA APIs (C & C++), not very > extensive, and when CA is merged with master the APIs will need update. > Early next week we will send an email to the reflector outlining the changes > and actions that have to be taken by those using the APIs. > > On an unrelated but relevant note, perhaps you are following the discussion > threads in the mailing list suggesting how to handle multiple interfaces. > Some of the suggestion are reasonable and when incorporated are expected to > result in additional API changes. > > Regards, > --Vijay > > -----Original Message----- > From: ???(Uze Choi) [mailto:uzchoi at samsung.com] > Sent: Wednesday, March 18, 2015 8:54 PM > To: Kesavan, Vijay S > Cc: Lankswert, Patrick; iotivity-dev at lists.iotivity.org > Subject: RE: [API change info sharing request] RE: Change in > iotivity[master]: Redefine and implement findResource API > > Hi, Vijay > > Regarding the previous question, I haven't got the response yet. > May I expect your explanation? > First of all, please Let me clear there is any difference the base layer API > between the master branch and connectivity abstraction branch. > > BR, Uze Choi > -----Original Message----- > From: ???(Uze Choi) [mailto:uzchoi at samsung.com] > Sent: Friday, February 13, 2015 1:06 PM > To: Kesavan, Vijay S (vijay.s.kesavan at intel.com) > Cc: 'Patrick Lankswert'; iotivity-dev at lists.iotivity.org > Subject: [API change info sharing request] RE: Change in iotivity[master]: > Redefine and implement findResource API > > Hi Vijay, > > Could you share the Base Layer API change according to the CA layer merging? > As far as I know, two feature were discussed. > - connectivity selection > - host parameter to identify the Resource Server/Clients are same one > according to the different connectivity. > And status together whether implemented or be planned. > > BR, Uze Choi > -----Original Message----- > From: Gerrit Code Review [mailto:gerrit at iotivity.org] > Sent: Wednesday, February 11, 2015 2:52 AM > To: Caiwen Zhang > Cc: Uze Choi; Patrick Lankswert; jenkins-iotivity > Subject: Change in iotivity[master]: Redefine and implement findResource API > > From Erich Keane : > > Erich Keane has posted comments on this change. > > Change subject: Redefine and implement findResource API > ...................................................................... > > > Patch Set 1: > > The parameters are all supposed to be part of the spec, I don't think they > were ever implemented correctly in the C stack however, so the C++ stack > kinda punted. > > We definitely need to revisit this and see whats up. > > -- > To view, visit https://gerrit.iotivity.org/gerrit/321 > To unsubscribe, visit https://gerrit.iotivity.org/gerrit/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: I1ca7ea0ec6114b661aee7c83f0fe4567784b3a56 > Gerrit-PatchSet: 1 > Gerrit-Project: iotivity > Gerrit-Branch: master > Gerrit-Owner: Caiwen Zhang > Gerrit-Reviewer: Erich Keane > Gerrit-Reviewer: Patrick Lankswert > Gerrit-Reviewer: Uze Choi > Gerrit-Reviewer: jenkins-iotivity > Gerrit-HasComments: No > > > _______________________________________________ > 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 [cid:image001.gif at 01D06C53.CED42780] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=1dc10d3d9c28bbee8b5f05cb0e30d7effcd0b48de37be987a1889aa8efbbee47d20c111660ca523c0083d46902da2839c7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/ff0ed2f0/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/ff0ed2f0/attachment.gif>
