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
