*"it was supposed to be **the new, official API layer."*
Is it still the plan? What will happen to resource encapsulation and the
smarthome API proposal?
On Fri, Aug 18, 2017 at 9:00 PM, Thiago Macieira
wrote:
> On Friday, 18 August 2017 14:50:43 PDT Gregg Reynolds wrote:
> > even better: IPC
On Friday, 18 August 2017 14:50:43 PDT Gregg Reynolds wrote:
> even better: IPCA. one of infinitely many c++ wrappers on csdk. why on
> earth is it in master?
Because IPCA wasn't supposed to be a vendor extension, it was supposed to be
the new, official API layer. The current csdk would become
On Aug 18, 2017 4:29 PM, "Gregg Reynolds" wrote:
On Aug 18, 2017 3:55 PM, "Mats Wichmann" wrote:
On 08/18/2017 02:40 PM, Thiago Macieira wrote:
> On Friday, 18 August 2017 13:22:18 PDT Gregg Reynolds wrote:
>> iotivity, the project, or iotivity, the ocf implementation?
>
> I meant the code th
On Aug 18, 2017 3:55 PM, "Mats Wichmann" wrote:
On 08/18/2017 02:40 PM, Thiago Macieira wrote:
> On Friday, 18 August 2017 13:22:18 PDT Gregg Reynolds wrote:
>> iotivity, the project, or iotivity, the ocf implementation?
>
> I meant the code that the IoTivity Project releases as "IoTivity".
>
> T
Definitely agree with Mats that feature selection needs to be centralized and
documented, and not scattered throughout scons files!
Bear in mind, it's a very typical model that a vendor creates a "Vendor
Defined" feature which is developed in parallel with a project being Specified.
Then when
On 08/18/2017 02:40 PM, Thiago Macieira wrote:
> On Friday, 18 August 2017 13:22:18 PDT Gregg Reynolds wrote:
>> iotivity, the project, or iotivity, the ocf implementation?
>
> I meant the code that the IoTivity Project releases as "IoTivity".
>
> That happens to be OCF's reference implementation
On Friday, 18 August 2017 13:22:18 PDT Gregg Reynolds wrote:
> iotivity, the project, or iotivity, the ocf implementation?
I meant the code that the IoTivity Project releases as "IoTivity".
That happens to be OCF's reference implementation.
> my 2 cents: the project is an appropriate home for ve
On Aug 18, 2017 3:07 PM, "Thiago Macieira"
wrote:
On Friday, 18 August 2017 12:03:01 PDT Dave Thaler via iotivity-dev wrote:
> “should not vendor-specific features go in vendor-specific
> forks or libs? otherwise we end up with a kitchen sink o' cruft.”
>
> Completely agree with th
On Friday, 18 August 2017 12:03:01 PDT Dave Thaler via iotivity-dev wrote:
> “should not vendor-specific features go in vendor-specific
> forks or libs? otherwise we end up with a kitchen sink o' cruft.”
>
> Completely agree with that. Vendor-specific features should never be code
“should not vendor-specific features go in vendor-specific forks
or libs? otherwise we end up with a kitchen sink o' cruft.”
Completely agree with that. Vendor-specific features should never be coded
(even if #ifdef’ed) into the middle of files in the master branch, in my view.
On Aug 18, 2017 12:20 PM, "Heldt-Sheller, Nathan" <
nathan.heldt-shel...@intel.com> wrote:
Hi George,
Direct Pairing wasn’t ever a Specified feature; it was a Vendor Defined
feature that shouldn’t have been compiled in by default in the first place
(all vendor-defined features should be conditi
You're right, it's the maintainer's job to make sure (at least) the Vendor
Defined features are conditionally compiled. I've tried to stay on top of that
in reviews, but I'm a sub-maintainer so many things get merged without my
review.
I am often asking folks to add conditional compile (you ca
On 08/18/2017 11:20 AM, Heldt-Sheller, Nathan wrote:
> Hi George,
>
> Direct Pairing wasn’t ever a Specified feature; it was a Vendor Defined
> feature that shouldn’t have been compiled in by default in the first place
> (all vendor-defined features should be conditionally compiled out by defaul
Hi George,
Direct Pairing wasn’t ever a Specified feature; it was a Vendor Defined feature
that shouldn’t have been compiled in by default in the first place (all
vendor-defined features should be conditionally compiled out by default).
For Vendor Defined features, the deprecation process is up
On 08/18/2017 09:54 AM, Dave Thaler via iotivity-dev wrote:
> As the new API maintainer, here's a set of proposed API guidelines.
> Please review so and feedback can be incorporated before making official
> guidelines.
> 1.3 Internal APIs
> -
> Internal APIs are considered to be u
As the new API maintainer, here's a set of proposed API guidelines.
Please review so and feedback can be incorporated before making official
guidelines.
1 APIs
--
There are three types of APIs:
1) Public
2) Experimental
3) Internal
1.1 Public APIs
---
Public APIs are
On Friday, 18 August 2017 00:03:08 PDT Heldt-Sheller, Nathan wrote:
> No, I really did mean P2 or below.
>
> For an issue that will not block certification, it’s okay to assign P2, or a
> lower priority than P2 (e.g. P3).
A lower priority has a higher number.
--
Thiago Macieira - thiago.macieir
* Approved buildsystem maintainer – Mats Wichmann
* Approved API function leader – Dave Thaler
* Approved Platform Support maintainer – Dan Mihai
* Governance proposal seems stuck - we should consider simplifying instead
* Reviewed contracted QA proposals
* Recommenda
Hi
Yes I noticed some headers could be needed (for logging, sec)
but were not installed so I send patches for that,
and then I was suggested by Dan to use experimental namespace,
to move them back in place, I believe those API should be stabilized.
and/or specified somewhere.
You can read more a
Hi Gregg,
No, I really did mean P2 or below.
For an issue that will not block certification, it’s okay to assign P2, or a
lower priority than P2 (e.g. P3).
P1 is reserved (for the time being) for certification blocking issues only.
If it’s still confusing, and you need to create a JIRA ticket,
20 matches
Mail list logo
