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

Christopher O'Connell jwriteclub at gmail.com
Wed Dec 9 05:08:04 UTC 2009


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
>


More information about the wp-hackers mailing list