We've avoided formal balloting up to now but that may be the most expedient way of garnering consensus on these things. This is something we need to discuss in the context of ODP v2.0 planning.
There will always be a need to strike a balance between a least-common-denominator approach which offers little in the way of compelling interest to applications and a full-featured approach that may be very difficult to implement efficiently across all platforms. The explicit allowance of optional features is designed to help bridge this gap by making it clear what features are absolutely required and which are nice-to-haves that while of interest to a significant group of potential applications are not universally important. On Tue, Sep 2, 2014 at 1:25 PM, Rosenboim, Leonid < [email protected]> wrote: > Here is another possible approach: > We can put up these optional features to a vote, where each platform will > express their position on a feature, and we can do the same for current > applications. > If for example only one platform commits to implementing a feature, it > will be rather obvious that the feature is not worthy, unless of course all > apps vote to require it. > There will be some features that will fall off the list pretty quickly > this way I think, and our calls just might become more constructive. > > { Leo } > > On Sep 2, 2014, at 9:37 AM, "Bill Fischofer" <[email protected]> > wrote: > > I'd be happy to make it a MUST but that would require additional buy-in > from the implementation side. > > From a practical standpoint, the way I see OPTIONAL features working is > that each implementation will document which OPTIONAL features it supports > and which it does not. Application writers will then use that information > to determine which ODP platforms they will recommend for deployment of > their application. If an application requires a specific optional feature, > then that may limit the recommended deployment to those platforms that > offer support for it. > > The reason certain features are optional is that they are not deemed > essential to all applications and/or their provision would be unduly > burdensome for some platforms. We don't want to artificially exclude > platform X from claiming that it has a conformant ODP implementation if it > doesn't offer every ODP feature, so its a judgement call as to which ODP > features are required of all implementations and which are optional. In > this case, the group consensus is that while user meta data is a > requirement, persistence is not. > > Bill > > > On Tue, Sep 2, 2014 at 9:56 AM, Victor Kamensky < > [email protected]> wrote: > >> On 1 September 2014 13:51, Bill Fischofer <[email protected]> >> wrote: >> >> <snip> >> >> >> - Persistent data is not required for meta-data support. >> > >> > >> > Correct, that is the current consensus. Persistence is an OPTIONAL >> feature. >> >> I don't see OPTIONAL as a good thing. What do I do as application >> writer? Do I code for both cases? Do I only choose to work with >> implementation that support it? If we have unnecessary functional >> fragmentation it is pushing us into direction what ODP is supposed to >> solve. >> >> I would rather not to have than than declare something optional. >> >> Of course they could be cases where optional is justified but I don't >> think that this is one of those. >> >> Thanks, >> Victor >> > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
