Re: Shelving documents

+1 for shelving the gallery spec.


This part of the API is something I really like from a security and 
efficiency view:
     gallery.find(['title', 'uri'], findSuccess, findError,
             {filter: 'foobar', galleries: galleries, mediaType: 
gallery.IMAGE_TYPE });

galleries is an object of galleries to search on (an array at this 
point, but lets pretend not),
and the find qualifier limits the fields being accessed instead of 
assuming all fields are available.

That method was my main take-away from reading the galleries spec.
In one of my projects, we work with multiple galleries. In my life as an 
SQL admin,
I'm certainly aware of per-column permissions.


On 11/9/11 3:02 AM, JOSE MANUEL CANTERA FONSECA wrote:
> Hi there,
> As I said during the F2F meeting I think the text to be put there should
> make it CLEAR that:
> A/ The API has been discontinued because the current DAP WG prefers to
> work on an 'intent-based' approach in order to meet browser use-cases.
> B/ The API it is still useful in a trusted environment context.
> C/ That the referred work may be taken over by a new W3C group or by other
> communities more interested on trusted execution environments.
> All the best
> El 08/11/11 17:21, "Robin Berjon"<>  escribió:
>> Dear all,
>> over the course of this group's existence, we have explored many avenues.
>> Some of those have not seen any recent work on them, and can therefore be
>> very misleading to people outside the group trying to assess what we are
>> doing. In some cases, this results in people starting implementations of
>> approaches we've abandoned. I am seeing books shipping or about to ship
>> with mention of device APIs and mentioning things that we currently don't
>> plan on turning into reality. It also means that people sometimes form a
>> bad opinion of DAP (or, as often as not, of W3C) because ideas we don't
>> believe work are still out there as if they reflected the best of our
>> thinking.
>> As a result, I think that we need to be better citizens when it comes to
>> marking our drafts as "shelved". I have picked this word carefully. It
>> does not mean that we have abandoned the corresponding deliverable. It
>> also doesn't mean that we've abandoned the use cases in a given draft,
>> simply that we are working on an approach that we believe works better.
>> We can, at any time, take a shelved document and return it to active work
>> simply by editing and republishing it.
>> We therefore need some form of process to shelve documents. The idea, as
>> discussed at the meeting last week, is that both the TR and the ED
>> versions will get big warning text as part of the SotD indicating that it
>> is currently shelved. Such decisions will be made through one-week CfCs,
>> as for publications (which they are).
>> Proposed text:
>> """
>> WARNING: The Device APIs WG does not believe that the approach outlined
>> in this document best addresses the problems it set out to work on. We
>> are looking into alternative options which we hope will produce better
>> solutions. In the meantime, please treat this document with caution as it
>> no longer captures the reality of the group's consensus.
>> """
>> I will be following this email with a list of CfCs for several of our
>> documents. If there are more documents that you think should be shelved,
>> please simply bring it up. If you have issues with this process or with
>> the text above, please express them by replying to this message and not
>> to the ones concerning specific documents proposed for shelving ‹ it
>> should be obvious that we will not shelve anything before we have
>> consensus on the process side!
>> --
>> Robin Berjon - - @robinberjon
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.

Received on Wednesday, 9 November 2011 16:46:58 UTC