Re: Brainstorming about resources states and al.

[Dare Obasanjo <kpako@xxxxxxxxx>]

--- Thomas Broyer <t.broyer@xxxxxxxxxxx> wrote:

> 
> First: should states (draft/published) be applicable
> to every resource 
> or to Atom entries only?

If draft and published are the only states then it is
possible that they only apply to entries but even this
is tricky. What if I have a draft post with an
attached podcast? Shouldn't the MP3 file then be a
draft?

> Next, let's see what we need and sum up some
> possible solutions.
> 
> Rationale
> ====================
> 
> We want to manage the state of resources with a rich
> and ideally 
> extensible set of states (not limited to
> draft/published).
> We also want to define properties on entries to
> allow/disallow comments, 
> trackback/pingback, etc. we may however need more
> than "allow/disallow" 
> values.
> Finally, we also need a way to tell the APP server
> whether and which URI 
> to trackback/pingback when creating or editing a
> resource (entries only?).

These seem like orthogonal issues and it might be
better that they are discussed separately so the
discussion thread doesn't get too unwieldy.

> Solutions
> ====================
> 
> There are three distinct problems (resource states,
> entry properties and 
> trackbacks/pingbacks) which can be discussed and
> addressed separately. 
> The first two need a set of accepted values and a
> way to set/update the 
> state/property value.
> 
> Resource States
> ------------------------------
> 
> We have two solutions here: restrict the set of
> resource states to a 
> fixed number of values or allow it to be extended.
> The first is not a great deal, we'll just have to
> find the way to 
> set/update the state of a resource (see below). If
> an APP server is 
> allowed to implement only a subset of these states,
> we'll also have to 
> define the behavior of the server if the client
> tries to use an 
> unsupported state (e.g. a "review" state to make the
> resource accessible 
> to "reviewers" but not fully public; on a "single
> user" system, it 
> should be interpreted as "fully private").

This seems like conflating ACLing with resource state.
Unless the ACLing is an implementation detail of the
CMS and not something that clients have to worry
about. 

> If we want to allow every APP server to extend the
> set of states (or 
> actually, define the states it's supporting), we'll
> need a way for the 
> server to send to the client its list of supported
> states. The client 
> would then have to choose among those possible
> values or the server 
> would respond with an error "unsupported resource
> state".
> One solution here would be to augment the
> Introspection Document format 
> to also contain a list of available states for each
> collection.

This is ideal but it gets complex real quick. I
personally would also like a way for a client to query
the server to figure out what markup is supported
(e.g. if the server supports a subset of HTML) but
realize this may be considered excessive by most. 
 


THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"


		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html