[wp-hackers] Storing Arbitrary Data as Custom Post Types

Mike Schinkel mikeschinkel at newclarity.net
Wed Dec 9 06:12:33 UTC 2009


On Dec 9, 2009, at 12:08 AM, Christopher O'Connell wrote:
> (without getting too O/T on hypermedia), it does constrain it. Consider, if
> each document contains a URL (or a signing url), then this uniquely
> identifies the document.
> 
> Then, the canonical data definitions are those stored in wp-plugins in
> canonical plugins.
> 
> Anyone else have any thoughts? Want to see the bacon? Think I've been off my
> meds for too long?

Either I don't follow or we are talking apples and oranges here.

Some examples might help.

-Mike
P.S. The problem with REST and hypermedia is that in order for a RESTful service to follow hypermedia it needs to agree on some names in the document to know which URLs are used for what aspect. Yet for RESTful services over HTTP there is no standard agreed-upon way to expose matching names hence why I think almost everyone ignored the hypermedia constraint. FWIW.

On Dec 9, 2009, at 12:08 AM, Christopher O'Connell wrote:

> Actually,
> 
> (without getting too O/T on hypermedia), it does constrain it. Consider, if
> each document contains a URL (or a signing url), then this uniquely
> identifies the document.
> 
> Then, the canonical data definitions are those stored in wp-plugins in
> canonical plugins.
> 
> Anyone else have any thoughts? Want to see the bacon? Think I've been off my
> meds for too long?
> 
> ~ Christopher
> 
> On Tue, Dec 8, 2009 at 9:33 PM, Mike Schinkel
> <mikeschinkel at newclarity.net>wrote:
> 
>> On Dec 8, 2009, at 8:11 PM, Christopher O'Connell wrote:
>>> Well, that's more or less where the canonical plugins come in: If each
>>> canonical plugin adheres to a specification for storing data (whether it
>> is
>>> what I have proposed or something else) than other plugins could access
>> the
>>> data of canonical plugins quite simply.
>> 
>> Exactly (assuming you mean that they agree on attribute naming as well as
>> storage methodology, right?)
>> 
>>> The advantage of my proposed solution is that other plugins simply need
>> to
>>> load the definition file from a canonical plugin (presumably somewhere in
>>> wp-plugins) in order to access that data.
>> 
>> Somewhere you'll need to map to a common name, though.  It's a
>> chicken-and-egg problem (and one of the reasons that I have a big problem
>> with the hypermedia constraint in the REST architecture, the one constraint
>> that practically everyone ignores. But I digress.)
>> 
>> 
>>> Indeed I might go so far as to suggest that part of the requirements for
>>> canonical plugins is that those that store data do so in some consistent
>>> fashion.
>> 
>> +1, of course (again, assuming we mean the same thing.)
>> 
>> -Mike
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers



More information about the wp-hackers mailing list