Re: [dev] clear distinction of what is below and above the APIs
Hi Philippe, Thanks for sharing email and wiki link. I am happy to add some more info but owner of this page is Dave Thaler. It will be right thing to get the direction from him first and then I can add information. Regards Dwarka - Samsung Research | R&D Strategy Team | Open Source Group Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF) From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Philippe Coval Sent: Monday, March 12, 2018 10:33 PM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs On 03/12/2018 05:58 AM, Dwarkaprasad Dayama wrote: Hi Mats, I just took pen and started going through all emails for this topic. As you mentioned, different things have been presented in form of opinion. Hence linking them is difficult. Before I move ahead with creating a new chapter in Wiki (which is anyway messed up due to adhoc additions), I would like to hear specifically from API maintainer Dave Thaler if his API guideline chapter can help in this case? Regards Hi Dwarka, I remember Dave posted this: https://lists.iotivity.org/pipermail/iotivity-dev/2017-August/008230.html which I linked from this draft page: https://wiki.iotivity.org/api Feel free to edit page -- mailto:philippe.co...@osg.samsung.com gpg:0x467094BC https://blogs.s-osg.org/author/pcoval/ ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 03/12/2018 05:58 AM, Dwarkaprasad Dayama wrote: Hi Mats, I just took pen and started going through all emails for this topic. As you mentioned, different things have been presented in form of opinion. Hence linking them is difficult. Before I move ahead with creating a new chapter in Wiki (which is anyway messed up due to adhoc additions), I would like to hear specifically from API maintainer _Dave Thaler_ if his API guideline chapter can help in this case? Regards Hi Dwarka, I remember Dave posted this: https://lists.iotivity.org/pipermail/iotivity-dev/2017-August/008230.html which I linked from this draft page: https://wiki.iotivity.org/api Feel free to edit page -- mailto:philippe.co...@osg.samsung.com gpg:0x467094BC https://blogs.s-osg.org/author/pcoval/ ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
Hi Mats, I just took pen and started going through all emails for this topic. As you mentioned, different things have been presented in form of opinion. Hence linking them is difficult. Before I move ahead with creating a new chapter in Wiki (which is anyway messed up due to adhoc additions), I would like to hear specifically from API maintainer Dave Thaler if his API guideline chapter can help in this case? Regards Dwarka - Samsung Research | R&D Strategy Team | Open Source Group Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF) -Original Message- From: Mats Wichmann [mailto:m...@wichmann.us] Sent: Thursday, March 08, 2018 11:08 PM To: Dwarkaprasad Dayama; 'Wouter van der Beek (wovander)'; iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs On 03/08/2018 01:05 AM, Dwarkaprasad Dayama wrote: > Just wanted to bring this thread back to life. > Can we document such information in Wiki? There are more folks asking > same question. > > I can also volunteer if required. Dwarka, why don't you drop in what you found relevant from this thread (seems like we talked about a few different things), and let us know the wiki page so others can chip in. I'm off on a computer-free trip today so I'm not able to volunteer at this time. Don't feel like doing a lot of typing on a phone. === if part of this is "build outside of the iotivity tree" we do need to get more organized on what that would look like. I didn't get a chance to look at Phil's efforts yet. (e.g. - when iotivity headers are "installed" to a common location, should they be in one flat location, so code does "#include ", or should they maintain the heirarchy that is currently created under out/*/deploy, namely resource and subdirectories, c_common, service subdirectories. cheers, -- mats ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 03/08/2018 01:05 AM, Dwarkaprasad Dayama wrote: > Just wanted to bring this thread back to life. > Can we document such information in Wiki? There are more folks asking same > question. > > I can also volunteer if required. Dwarka, why don't you drop in what you found relevant from this thread (seems like we talked about a few different things), and let us know the wiki page so others can chip in. I'm off on a computer-free trip today so I'm not able to volunteer at this time. Don't feel like doing a lot of typing on a phone. === if part of this is "build outside of the iotivity tree" we do need to get more organized on what that would look like. I didn't get a chance to look at Phil's efforts yet. (e.g. - when iotivity headers are "installed" to a common location, should they be in one flat location, so code does "#include ", or should they maintain the heirarchy that is currently created under out/*/deploy, namely resource and subdirectories, c_common, service subdirectories. cheers, -- mats ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
Just wanted to bring this thread back to life. Can we document such information in Wiki? There are more folks asking same question. I can also volunteer if required. Regards Dwarka - Samsung Research | R&D Strategy Team | Open Source Group Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF) -Original Message- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Saturday, February 24, 2018 6:11 AM To: Wouter van der Beek (wovander); iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs On 02/22/2018 08:32 AM, Mats Wichmann wrote: >> Related to this, I am will be working on application level code, e.g. using the IOTivity API. >> I like to contribute this code to IOTivity or other open source project. >> I will not be maintaining it for long, e.g. if the IOTivity API changes it will be broken... >> I guess that means that is it should not be in the main tree of IOTivity... hence we need an solution to store this kind of code. >> Any ideas? > > We should probably have a "contrib" branch for contributions (unless a > case can be made that the code should be taken into the long term > maintenance area). We need anyway to be testing the ability to build > applications outside of the tree which builds the stack (partly due to > what was mentioned above - the environment is too leaky to be building > examples inside the tree, since "everything is available") It turns out we already have an (empty) iotivity-contrib that could be used to drop things into. Just clone it using git clone ssh://$you...@gerrit.iotivity.org:29418/iotivity-contrib and then push using git push origin HEAD:refs-for-master (at least, I assume that will work, if it's not locked down with some odd permissions) ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 08:32 AM, Mats Wichmann wrote: >> Related to this, I am will be working on application level code, e.g. using >> the IOTivity API. >> I like to contribute this code to IOTivity or other open source project. >> I will not be maintaining it for long, e.g. if the IOTivity API changes it >> will be broken... >> I guess that means that is it should not be in the main tree of IOTivity... >> hence we need an solution to store this kind of code. >> Any ideas? > > We should probably have a "contrib" branch for contributions (unless a > case can be made that the code should be taken into the long term > maintenance area). We need anyway to be testing the ability to build > applications outside of the tree which builds the stack (partly due to > what was mentioned above - the environment is too leaky to be building > examples inside the tree, since "everything is available") It turns out we already have an (empty) iotivity-contrib that could be used to drop things into. Just clone it using git clone ssh://$you...@gerrit.iotivity.org:29418/iotivity-contrib and then push using git push origin HEAD:refs-for-master (at least, I assume that will work, if it's not locked down with some odd permissions) ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 02/23/18 00:27, Wouter van der Beek (wovander) wrote: Nice! Thx But why is this info living outside the IOTivity documentation? because it's not related to iotivity's internal, it was done for validation and demo purposes, to make sure iotivity was usuable in production context (install, headers, pkgconfig etc). e.g. how can one know these kind of things? Hence can we have at least links from IOTivity to this documentation and then an set of repos that will act as well I only linked it on this page: https://wiki.iotivity.org/community#downstream_projects The whole idea that I have is that this code is useful but not necessary, and it will be tight to an specific release. e.g. it will become stale if api changes…. Which is ok.. yes, IHMO necessary code should be the priority "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Hence maintenance is limited, it will be checked that it works under certain conditions.. and the conditions should be documented (e.g. the used release version etc..). e.g. see it as reference code for an particular solution. Maybe we should even go that far to make an new github organisation something like “IOTivity-code-snippets” Note, for convenience, I shared also a mirror at: https://github.com/tizenteam/iotivity-example Fell free to branch existing branches or start from blank one: https://github.com/tizenteam/iotivity-example/tree/init I'll be happy to review and merge contribs on this project Also relocation of iotivity-example under iotivity's org would not be a problem for me, Kind Regards, Wouter I can give more details if there is any need, meanwhile you start reading page 25 of : https://www.slideshare.net/SamsungOSG/iotivity-for-automotive-metaocfautomotive-tutorial/25 Regards -- mailto:philippe.co...@osg.samsung.com gpg:0x467094BC https://blogs.s-osg.org/author/pcoval/ ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
Nice! But why is this info living outside the IOTivity documentation? e.g. how can one know these kind of things? Hence can we have at least links from IOTivity to this documentation and then an set of repos that will act as The whole idea that I have is that this code is useful but not necessary, and it will be tight to an specific release. e.g. it will become stale if api changes Which is ok.. Hence maintenance is limited, it will be checked that it works under certain conditions.. and the conditions should be documented (e.g. the used release version etc..). e.g. see it as reference code for an particular solution. Maybe we should even go that far to make an new github organisation something like "IOTivity-code-snippets" Kind Regards, Wouter From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Philippe Coval Sent: 22 February 2018 18:00 To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs On 02/22/18 16:19, Wouter van der Beek (wovander) wrote: Hi All, Hi Wouter ! Related to this, I am will be working on application level code, e.g. using the IOTivity API. I like to contribute this code to IOTivity or other open source project. of course you can create your own repo I will not be maintaining it for long, e.g. if the IOTivity API changes it will be broken... So you expect someone else to fix it ? I guess that means that is it should not be in the main tree of IOTivity... yea I am not sure it makes sense to push in iotivity if there is no maintenance on examples, we had several ones that are no more tested, at least bug can be reported (and fixed) hence we need an solution to store this kind of code. I agrea on need of having some apps of iotivity tree, and keep few reference ones well maintained in it. Any ideas? Well, as said before, I shared this template project, for apps living out of iotivity tree (demos etc), http://git.s-osg.org/iotivity-example/ http://git.s-osg.org/iotivity-example/plain/README.md To deal with API (or breaking) changes, I am relying on branches: http://git.s-osg.org/iotivity-example/log/?h=clock/master http://git.s-osg.org/iotivity-example/log/?h=clock/1.2-rel Check more explanations at: https://blogs.s-osg.org/prototype-insecure-iotivity-apps-secure-library/ To get the pattern, here is slightly improved example: http://git.s-osg.org/iotivity-example/log/?h=brightness/1.2-rel http://git.s-osg.org/iotivity-example/log/?h=brightness/master I can give more details if interested, but first I am open to feedbacks My 2c ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
My opinion: the presence or absence of APIs should not depend on #defines. For example, I would consider any APIs whose presence, absence, or signature is affected by #ifdef __WITH_TLS__ to be a bug that needs to be fixed. -Original Message- From: Mats Wichmann [mailto:m...@wichmann.us] Sent: Thursday, February 22, 2018 2:06 PM To: Dave Thaler ; Wouter van der Beek (wovander) ; Nash, George ; iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs On 02/22/2018 12:15 PM, Dave Thaler wrote: > > The API can evolve, just like OCF specs, evolve so there's no fixed > definition per se. Of course it's not fixed over time, but for any given release there should be a well-known API. Then the next release there will be another well known API, such that we can generate a document which lists the difference between, say, 1.3's API and 1.4's API. What is that definition? It's not what is listed at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iotivity.org%2Fdocumentation&data=04%7C01%7Cdthaler%40microsoft.com%7Cf2aa9c7e08a143383a9e08d57a408597%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636549339899693878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=Lmb4GJ3VC3XDMnPwwUJszTqjfhjfdAwyA1vzMagq3as%3D&reserved=0, because some header portions are omitted by the documentation build as they're bracketed in #if sections, even though those portions are enabled by default in a code build. Until very recently, the documentation build expanded no defines at all, now it defines (only) the ones related to deprecation. In particular, security things are left out of the online definition. You get left with questions like - Are these part of the API or not? #ifdef __WITH_TLS__ bool OC_CALL OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const char *name, OicSecKey_t *value); #endif Is "it depends on how the stack was compiled" really a good answer? (not to mention that the docs will not list those three at all) ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 12:15 PM, Dave Thaler wrote: > > The API can evolve, just like OCF specs, evolve so there's no fixed > definition per se. Of course it's not fixed over time, but for any given release there should be a well-known API. Then the next release there will be another well known API, such that we can generate a document which lists the difference between, say, 1.3's API and 1.4's API. What is that definition? It's not what is listed at https://www.iotivity.org/documentation, because some header portions are omitted by the documentation build as they're bracketed in #if sections, even though those portions are enabled by default in a code build. Until very recently, the documentation build expanded no defines at all, now it defines (only) the ones related to deprecation. In particular, security things are left out of the online definition. You get left with questions like - Are these part of the API or not? #ifdef __WITH_TLS__ bool OC_CALL OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const char *name, OicSecKey_t *value); #endif Is "it depends on how the stack was compiled" really a good answer? (not to mention that the docs will not list those three at all) ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
My views, as the iotivity API maintainer, below... -Original Message- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Wouter van der Beek (wovander) Sent: Thursday, February 22, 2018 9:49 AM To: Nash, George ; Mats Wichmann ; iotivity-dev@lists.iotivity.org Subject: Re: [dev] clear distinction of what is below and above the APIs Sure.. 1) clear definition of the IOTivity API. The API can evolve, just like OCF specs, evolve so there's no fixed definition per se. That said, one guideline is that anything that's mandatory in an OCF spec should have an implementation below the API (though may require values/input from the app across some API). That guideline is not consistently followed in the iotivity API today because the iotivity API today evolved over time with few documented principles and without any API maintainer. 2) definition of what is base functionality (e.g. what should be in the stack) - guidance to developers of code for OCF CR's if that needs to be under the API (read: new api) or below the API My opinion is that by default I assume that everything ought to be below the API. Today, many things have to be implemented by the app because the API doesn't do it for them. I consider this a bad thing in general. - starting point: - all security code needs to be part of the stack, otherwise the stack is incomplete - all discovery resources should be part of the stack Agree. This is also consistent with my views expressed above. - discussion points - infra structure features, are those application resources or are some of them part of the stack. Not sure what "infrastructure features" are referred to, but hopefully the principles I mentioned above are sufficient for others to know what I would say :) 3) mechanism to add application code somewhere that uses an API as defined on above definitions. For example I will create a new resource that will be defined in the core. I do not think that this is an feature that should be part of the IOTivity core stack since it will be an optional resource. I want to distinguish between the "core" stack and "Iotivity APIs". My points above are about Iotivity APIs in general. There may be APIs for the "core" stack, and additional APIs for optional components in iotivity that aren't part of the "core" stack. So just because something isn't in the "core" stack doesn't mean it can't be in the iotivity project and have an iotivity API (it could also be in some other project and have its own API, which is what I think you imply in the next paragraph). There just has to be a way for an app to select which optional components it wants, without having to write all the optional component logic itself. The discussion of whether a given optional component should be in the iotivity project or another project, is about functionality of IoTivity as a project, not a question about APIs per se, and thus not specific to me as API maintainer. So others may want to comment on that Dave. However I will produce some code for it to test the API, this is still an good starting point for any developer that wants to implement such resource. Since I will do this for OCF, I need to open source the code and since it will be based on IOTivity, it makes sense to me that there is an some kind of repo where I can put this code in. together with build instructions and information on which version of IOTivity this is developed. Hope this helps, Wouter -Original Message- From: Nash, George [mailto:george.n...@intel.com] Sent: 22 February 2018 17:07 To: Wouter van der Beek (wovander) mailto:wovan...@cisco.com>>; Mats Wichmann mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: [dev] clear distinction of what is below and above the APIs Could you please add some clarification what you are actually asking from the iotivity-dev community. I have read this email chain multiple times and I am still confused about what exactly you are asking. George Nash -Original Message- From: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Wouter van der Beek (wovander) Sent: Thursday, February 22, 2018 7:39 AM To: Mats Wichmann mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: Re: [dev] clear distinction of what is below and above the APIs Thx, Maybe we should clean up the API as an side effect of this r
Re: [dev] clear distinction of what is below and above the APIs
On 02/22/18 16:19, Wouter van der Beek (wovander) wrote: Hi All, Hi Wouter ! Related to this, I am will be working on application level code, e.g. using the IOTivity API. I like to contribute this code to IOTivity or other open source project. of course you can create your own repo I will not be maintaining it for long, e.g. if the IOTivity API changes it will be broken… So you expect someone else to fix it ? I guess that means that is it should not be in the main tree of IOTivity… yea I am not sure it makes sense to push in iotivity if there is no maintenance on examples, we had several ones that are no more tested, at least bug can be reported (and fixed) hence we need an solution to store this kind of code. I agrea on need of having some apps of iotivity tree, and keep few reference ones well maintained in it. Any ideas? Well, as said before, I shared this template project, for apps living out of iotivity tree (demos etc), http://git.s-osg.org/iotivity-example/ http://git.s-osg.org/iotivity-example/plain/README.md To deal with API (or breaking) changes, I am relying on branches: http://git.s-osg.org/iotivity-example/log/?h=clock/master http://git.s-osg.org/iotivity-example/log/?h=clock/1.2-rel Check more explanations at: https://blogs.s-osg.org/prototype-insecure-iotivity-apps-secure-library/ To get the pattern, here is slightly improved example: http://git.s-osg.org/iotivity-example/log/?h=brightness/1.2-rel http://git.s-osg.org/iotivity-example/log/?h=brightness/master I can give more details if interested, but first I am open to feedbacks My 2c ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
Sure..
1) clear definition of the IOTivity API.
2) definition of what is base functionality (e.g. what should be in the stack)
- guidance to developers of code for OCF CR's if that needs to be under
the API (read: new api) or below the API
- starting point:
- all security code needs to be part of the stack, otherwise
the stack is incomplete
- all discovery resources should be part of the stack
- discussion points
- infra structure features, are those application resources or
are some of them part of the stack.
3) mechanism to add application code somewhere that uses an API as defined on
above definitions.
For example I will create a new resource that will be defined in the core.
I do not think that this is an feature that should be part of the IOTivity core
stack since it will be an optional resource.
However I will produce some code for it to test the API, this is still an good
starting point for any developer that wants to implement such resource.
Since I will do this for OCF, I need to open source the code and since it will
be based on IOTivity, it makes sense to me that there is an some kind of repo
where I can put this code in. together with build instructions and information
on which version of IOTivity this is developed.
Hope this helps,
Wouter
-Original Message-
From: Nash, George [mailto:george.n...@intel.com]
Sent: 22 February 2018 17:07
To: Wouter van der Beek (wovander) ; Mats Wichmann
; iotivity-dev@lists.iotivity.org
Subject: RE: [dev] clear distinction of what is below and above the APIs
Could you please add some clarification what you are actually asking from the
iotivity-dev community. I have read this email chain multiple times and I am
still confused about what exactly you are asking.
George Nash
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Wouter van der
Beek (wovander)
Sent: Thursday, February 22, 2018 7:39 AM
To: Mats Wichmann ; iotivity-dev@lists.iotivity.org
Subject: Re: [dev] clear distinction of what is below and above the APIs
Thx,
Maybe we should clean up the API as an side effect of this request..
e.g. make sure that if someone uses a lower layer that is not intended as API,
it should not link..
Kind Regards,
Wouter
-Original Message-
From: Mats Wichmann [mailto:m...@wichmann.us]
Sent: 22 February 2018 15:32
To: Wouter van der Beek (wovander) ;
iotivity-dev@lists.iotivity.org
Subject: Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 08:19 AM, Wouter van der Beek (wovander) wrote:
I'm maybe the wrong person to respond here, but let me have a go.
> Hi All,
>
>>From IOTivity perspective I like to know if code is being developed for an CR
>>if it needs to go below the API or should be regarded as application level.
> For some things it is pretty obvious but for larger infrastructure items it
> is probably not.
> Is there any guidance from IOTIvity perspective?
> (if not then see this as an request to make that guidance)
Not quite sure understanding the question. If by CR you mean OCF spec change
request, under what circumstance would that not be stack-level code, that is,
part of the implementation of the API ("below")? If there is an infrastructure
element that looks like an application, an example would be useful (others will
probably have a much better understanding)
I don't think we know what the API is, precisely. We have a possibly-correct
list of headers which contain declarations of things that should be part of the
API, but the dependency tree has not been worked out to my knowledge - and
since the libraries are not "cleaned"
(non-public symbols are still visible), you can get away with building code
that reaches outside the API - it will link okay if the libraries provide those
symbols, and there's nothing to detect such usage. Yes this is a new topic from
what you're asking.
>
> Related to this, I am will be working on application level code, e.g. using
> the IOTivity API.
> I like to contribute this code to IOTivity or other open source project.
> I will not be maintaining it for long, e.g. if the IOTivity API changes it
> will be broken...
> I guess that means that is it should not be in the main tree of IOTivity...
> hence we need an solution to store this kind of code.
> Any ideas?
We should probably have a "contrib" branch for contributions (unless a case can
be made that the code should be taken into the long term maintenance area). We
need anyway to be testing the ability to build applications outside of the tree
which builds the stack (partly due to what was mentioned above - the
environment is too leaky to be building examples inside the tree, since
"everything is availab
Re: [dev] clear distinction of what is below and above the APIs
Could you please add some clarification what you are actually asking from the
iotivity-dev community. I have read this email chain multiple times and I am
still confused about what exactly you are asking.
George Nash
-Original Message-
From: iotivity-dev-boun...@lists.iotivity.org
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Wouter van der
Beek (wovander)
Sent: Thursday, February 22, 2018 7:39 AM
To: Mats Wichmann ; iotivity-dev@lists.iotivity.org
Subject: Re: [dev] clear distinction of what is below and above the APIs
Thx,
Maybe we should clean up the API as an side effect of this request..
e.g. make sure that if someone uses a lower layer that is not intended as API,
it should not link..
Kind Regards,
Wouter
-Original Message-
From: Mats Wichmann [mailto:m...@wichmann.us]
Sent: 22 February 2018 15:32
To: Wouter van der Beek (wovander) ;
iotivity-dev@lists.iotivity.org
Subject: Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 08:19 AM, Wouter van der Beek (wovander) wrote:
I'm maybe the wrong person to respond here, but let me have a go.
> Hi All,
>
>>From IOTivity perspective I like to know if code is being developed for an CR
>>if it needs to go below the API or should be regarded as application level.
> For some things it is pretty obvious but for larger infrastructure items it
> is probably not.
> Is there any guidance from IOTIvity perspective?
> (if not then see this as an request to make that guidance)
Not quite sure understanding the question. If by CR you mean OCF spec change
request, under what circumstance would that not be stack-level code, that is,
part of the implementation of the API ("below")? If there is an infrastructure
element that looks like an application, an example would be useful (others will
probably have a much better understanding)
I don't think we know what the API is, precisely. We have a possibly-correct
list of headers which contain declarations of things that should be part of the
API, but the dependency tree has not been worked out to my knowledge - and
since the libraries are not "cleaned"
(non-public symbols are still visible), you can get away with building code
that reaches outside the API - it will link okay if the libraries provide those
symbols, and there's nothing to detect such usage. Yes this is a new topic from
what you're asking.
>
> Related to this, I am will be working on application level code, e.g. using
> the IOTivity API.
> I like to contribute this code to IOTivity or other open source project.
> I will not be maintaining it for long, e.g. if the IOTivity API changes it
> will be broken...
> I guess that means that is it should not be in the main tree of IOTivity...
> hence we need an solution to store this kind of code.
> Any ideas?
We should probably have a "contrib" branch for contributions (unless a case can
be made that the code should be taken into the long term maintenance area). We
need anyway to be testing the ability to build applications outside of the tree
which builds the stack (partly due to what was mentioned above - the
environment is too leaky to be building examples inside the tree, since
"everything is available")
___
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
___
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
Thx,
Maybe we should clean up the API as an side effect of this request..
e.g. make sure that if someone uses a lower layer that is not intended as API,
it should not link..
Kind Regards,
Wouter
-Original Message-
From: Mats Wichmann [mailto:m...@wichmann.us]
Sent: 22 February 2018 15:32
To: Wouter van der Beek (wovander) ;
iotivity-dev@lists.iotivity.org
Subject: Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 08:19 AM, Wouter van der Beek (wovander) wrote:
I'm maybe the wrong person to respond here, but let me have a go.
> Hi All,
>
>>From IOTivity perspective I like to know if code is being developed for an CR
>>if it needs to go below the API or should be regarded as application level.
> For some things it is pretty obvious but for larger infrastructure items it
> is probably not.
> Is there any guidance from IOTIvity perspective?
> (if not then see this as an request to make that guidance)
Not quite sure understanding the question. If by CR you mean OCF spec change
request, under what circumstance would that not be stack-level code, that is,
part of the implementation of the API ("below")? If there is an infrastructure
element that looks like an application, an example would be useful (others will
probably have a much better understanding)
I don't think we know what the API is, precisely. We have a possibly-correct
list of headers which contain declarations of things that should be part of the
API, but the dependency tree has not been worked out to my knowledge - and
since the libraries are not "cleaned"
(non-public symbols are still visible), you can get away with building code
that reaches outside the API - it will link okay if the libraries provide those
symbols, and there's nothing to detect such usage. Yes this is a new topic from
what you're asking.
>
> Related to this, I am will be working on application level code, e.g. using
> the IOTivity API.
> I like to contribute this code to IOTivity or other open source project.
> I will not be maintaining it for long, e.g. if the IOTivity API changes it
> will be broken...
> I guess that means that is it should not be in the main tree of IOTivity...
> hence we need an solution to store this kind of code.
> Any ideas?
We should probably have a "contrib" branch for contributions (unless a case can
be made that the code should be taken into the long term maintenance area). We
need anyway to be testing the ability to build applications outside of the tree
which builds the stack (partly due to what was mentioned above - the
environment is too leaky to be building examples inside the tree, since
"everything is available")
___
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Re: [dev] clear distinction of what is below and above the APIs
On 02/22/2018 08:19 AM, Wouter van der Beek (wovander) wrote:
I'm maybe the wrong person to respond here, but let me have a go.
> Hi All,
>
>>From IOTivity perspective I like to know if code is being developed for an CR
>>if it needs to go below the API or should be regarded as application level.
> For some things it is pretty obvious but for larger infrastructure items it
> is probably not.
> Is there any guidance from IOTIvity perspective?
> (if not then see this as an request to make that guidance)
Not quite sure understanding the question. If by CR you mean OCF spec
change request, under what circumstance would that not be stack-level
code, that is, part of the implementation of the API ("below")? If there
is an infrastructure element that looks like an application, an example
would be useful (others will probably have a much better understanding)
I don't think we know what the API is, precisely. We have a
possibly-correct list of headers which contain declarations of things
that should be part of the API, but the dependency tree has not been
worked out to my knowledge - and since the libraries are not "cleaned"
(non-public symbols are still visible), you can get away with building
code that reaches outside the API - it will link okay if the libraries
provide those symbols, and there's nothing to detect such usage. Yes
this is a new topic from what you're asking.
>
> Related to this, I am will be working on application level code, e.g. using
> the IOTivity API.
> I like to contribute this code to IOTivity or other open source project.
> I will not be maintaining it for long, e.g. if the IOTivity API changes it
> will be broken...
> I guess that means that is it should not be in the main tree of IOTivity...
> hence we need an solution to store this kind of code.
> Any ideas?
We should probably have a "contrib" branch for contributions (unless a
case can be made that the code should be taken into the long term
maintenance area). We need anyway to be testing the ability to build
applications outside of the tree which builds the stack (partly due to
what was mentioned above - the environment is too leaky to be building
examples inside the tree, since "everything is available")
___
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
[dev] clear distinction of what is below and above the APIs
Hi All, >From IOTivity perspective I like to know if code is being developed for an CR >if it needs to go below the API or should be regarded as application level. For some things it is pretty obvious but for larger infrastructure items it is probably not. Is there any guidance from IOTIvity perspective? (if not then see this as an request to make that guidance) Related to this, I am will be working on application level code, e.g. using the IOTivity API. I like to contribute this code to IOTivity or other open source project. I will not be maintaining it for long, e.g. if the IOTivity API changes it will be broken... I guess that means that is it should not be in the main tree of IOTivity... hence we need an solution to store this kind of code. Any ideas? Kind Regards, Wouter ___ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
