You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Louis Ryan <lr...@google.com> on 2008/06/28 02:29:21 UTC
Proposal : JSON backed canonical data set
Hi,
I would like to propose a canonical data implementation for use in Shindig
for unit and end-to-end testing based on a JSON structure that we check into
SCM.
The idea is pretty simple, define a JSON structure that contains the
canonical data in the form described in the RESTful spec. Something like
{ "people" : < an array of Person JSON objects>,
"activities" : <an array of Activity JSON object for people>,
"data" : <an array of app-data for people>,
"friendLinks" : < a mapping between people id's to simulate friend links>,
"dataLinks" : < a mapping between people id's and their app data>
}
This structure is loaded into a JSON DB driver and used to satisfy service
requests. The driver will support CRUD operations on activities and data in
line with the spec.
Advantages:
- Fully exercises the JSON side of the RESTful spec and its binding to POJOs
etc
- Supports simple mutability
- Its canonical!
- Shared between all the implementations
Im working on creating some data which Ill send out if folks are interested
-Louis
Re: Proposal : JSON backed canonical data set
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Louis Ryan" <lr...@google.com> writes:
>Think of a JSON structure like an untyped hierarchical entity DB as opposed
>to a flattened normalized relational one :)
Yep, my internal translator messed up "data base" and "data base
engine". Again. :-) I now understand what is the intention behind
this. Thanks for clarifying.
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: Proposal : JSON backed canonical data set
Posted by Louis Ryan <lr...@google.com>.
Think of a JSON structure like an untyped hierarchical entity DB as opposed
to a flattened normalized relational one :)
On Tue, Jul 1, 2008 at 2:07 AM, Henning P. Schmiedehausen <hp...@intermeta.de>
wrote:
> "Louis Ryan" <lr...@google.com> writes:
>
> Sounds nice. What, BTW is a "JSON DB Driver"?
>
> Quick question: If you want to make the JSON example to behave like
> coming out of a database (unless I got JSON DB driver wrong), why not
> use a database? Just curious.
>
> Ciao
> Henning
>
>
>
> >------=_Part_14110_31284130.1214612961651
> >Content-Type: text/plain; charset=ISO-8859-1
> >Content-Transfer-Encoding: 7bit
> >Content-Disposition: inline
>
> >Hi,
>
> >I would like to propose a canonical data implementation for use in Shindig
> >for unit and end-to-end testing based on a JSON structure that we check
> into
> >SCM.
>
> >The idea is pretty simple, define a JSON structure that contains the
> >canonical data in the form described in the RESTful spec. Something like
>
> >{ "people" : < an array of Person JSON objects>,
> > "activities" : <an array of Activity JSON object for people>,
> > "data" : <an array of app-data for people>,
> > "friendLinks" : < a mapping between people id's to simulate friend
> links>,
> > "dataLinks" : < a mapping between people id's and their app data>
> >}
>
> >This structure is loaded into a JSON DB driver and used to satisfy service
> >requests. The driver will support CRUD operations on activities and data
> in
> >line with the spec.
>
> >Advantages:
> >- Fully exercises the JSON side of the RESTful spec and its binding to
> POJOs
> >etc
> >- Supports simple mutability
> >- Its canonical!
> >- Shared between all the implementations
>
> >Im working on creating some data which Ill send out if folks are
> interested
>
> >-Louis
>
> >------=_Part_14110_31284130.1214612961651--
>
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine guy
>
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>
> "Professor Peach in the library with the lead piping!" -- Donna
>
Re: Proposal : JSON backed canonical data set
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Louis Ryan" <lr...@google.com> writes:
Sounds nice. What, BTW is a "JSON DB Driver"?
Quick question: If you want to make the JSON example to behave like
coming out of a database (unless I got JSON DB driver wrong), why not
use a database? Just curious.
Ciao
Henning
>------=_Part_14110_31284130.1214612961651
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>Hi,
>I would like to propose a canonical data implementation for use in Shindig
>for unit and end-to-end testing based on a JSON structure that we check into
>SCM.
>The idea is pretty simple, define a JSON structure that contains the
>canonical data in the form described in the RESTful spec. Something like
>{ "people" : < an array of Person JSON objects>,
> "activities" : <an array of Activity JSON object for people>,
> "data" : <an array of app-data for people>,
> "friendLinks" : < a mapping between people id's to simulate friend links>,
> "dataLinks" : < a mapping between people id's and their app data>
>}
>This structure is loaded into a JSON DB driver and used to satisfy service
>requests. The driver will support CRUD operations on activities and data in
>line with the spec.
>Advantages:
>- Fully exercises the JSON side of the RESTful spec and its binding to POJOs
>etc
>- Supports simple mutability
>- Its canonical!
>- Shared between all the implementations
>Im working on creating some data which Ill send out if folks are interested
>-Louis
>------=_Part_14110_31284130.1214612961651--
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: Proposal : JSON backed canonical data set
Posted by Louis Ryan <lr...@google.com>.
Yes, very much a punt on the id for the moment. Ill fixup the dates and
datetimes in the example sometime today as per the spec.
On Mon, Jun 30, 2008 at 12:53 PM, David Primmer <da...@gmail.com>
wrote:
> I too am curious how the 'canonical' id will get specified. I'm
> assuming Louis just 'punted' on this one for now.
>
> However regarding the dates: the dates that seem to matter are not in
> the format that John mentioned. Updated and PostedTime matter. Can't
> "dateOfBirth" : "1/1/1975", be an string?
>
> We definitely need to resolve the date format thing for these two
> fields. Seconds since epoch or XSD Dates.
>
> Here's the RESTful spec:
> Dates and timestamps are represented as strings containing AtomPub
> (RFC3339) format date-time elements; see section 3.3 of [RFC4287].
> These are also known as "XSD Dates". In cases where only a
> day-of-the-year is desired, e.g., a birthday, the year SHOULD be
> specified as 0000.
>
> Which conflicts with the JS
> A string specifying the time at which this activity took place in
> milliseconds since the epoch.
>
> What is the ultimate storage format?
>
> davep
>
> On Mon, Jun 30, 2008 at 12:36 PM, John Panzer <jp...@google.com> wrote:
> > LG, except for the human readable id strings like 'canonical', and that
> the
> > dates are in some unknown format (1/1/1999); would be good to document
> the
> > format or better yet use xsd dates.
> >
> > John Panzer (http://abstractioneer.org)
> >
> > On Mon, Jun 30, 2008 at 12:29 PM, Louis Ryan <lr...@google.com> wrote:
> >
> >> I've created a JIRA issue with a sample JSON DB patch attached here
> >>
> >> https://issues.apache.org/jira/browse/SHINDIG-413
> >>
> >> There are definitely issues with some of the data that I will work on. I
> >> will also ping on the RESTful discussion list to point folks at this
> data
> >> as
> >> I think it makes sense to use the same data in the spec document and in
> the
> >> canonical DB.
> >>
> >> I am working on a driver for this structure and I should have a patch
> ready
> >> today
> >>
> >> On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <dp...@google.com>
> >> wrote:
> >>
> >> > Sounds great to me as well, looking forward to seeing it in the sample
> >> > container.
> >> >
> >> > -Dan
> >> >
> >> > On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
> >> >
> >> > > That would be really useful for ensuring compatibility between PHP
> and
> >> > > Java.
> >> > > It definitely beats the simple xml fetcher thing :)
> >> > >
> >> > > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com>
> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I would like to propose a canonical data implementation for use in
> >> > > Shindig
> >> > > > for unit and end-to-end testing based on a JSON structure that we
> >> check
> >> > > > into
> >> > > > SCM.
> >> > > >
> >> > > > The idea is pretty simple, define a JSON structure that contains
> the
> >> > > > canonical data in the form described in the RESTful spec.
> Something
> >> > like
> >> > > >
> >> > > > { "people" : < an array of Person JSON objects>,
> >> > > > "activities" : <an array of Activity JSON object for people>,
> >> > > > "data" : <an array of app-data for people>,
> >> > > > "friendLinks" : < a mapping between people id's to simulate
> friend
> >> > > links>,
> >> > > > "dataLinks" : < a mapping between people id's and their app data>
> >> > > > }
> >> > > >
> >> > > > This structure is loaded into a JSON DB driver and used to satisfy
> >> > > service
> >> > > > requests. The driver will support CRUD operations on activities
> and
> >> > data
> >> > > in
> >> > > > line with the spec.
> >> > > >
> >> > > > Advantages:
> >> > > > - Fully exercises the JSON side of the RESTful spec and its
> binding
> >> to
> >> > > > POJOs
> >> > > > etc
> >> > > > - Supports simple mutability
> >> > > > - Its canonical!
> >> > > > - Shared between all the implementations
> >> > > >
> >> > > > Im working on creating some data which Ill send out if folks are
> >> > > interested
> >> > > >
> >> > > > -Louis
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Proposal : JSON backed canonical data set
Posted by John Panzer <jp...@google.com>.
Depends on whether we want to be able to perform calculations on
dateOfBirth, for example to see if a user is over 18 (something which raises
its head from time to time). The RESTful spec equivalent XSD date of the
string below would be 1975-01-01. Luckily, this example string just happens
to be unambiguous so I can parse it; I couldn't do that for 10/11/03 for
example.
If we do want to have date of birth as an actual date and not a string, I
think that means that epoch seconds are right out. Unless you want to ban
everyone over age 38 from doing social networking :)
John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 12:53 PM, David Primmer <da...@gmail.com>
wrote:
> I too am curious how the 'canonical' id will get specified. I'm
> assuming Louis just 'punted' on this one for now.
>
> However regarding the dates: the dates that seem to matter are not in
> the format that John mentioned. Updated and PostedTime matter. Can't
> "dateOfBirth" : "1/1/1975", be an string?
>
> We definitely need to resolve the date format thing for these two
> fields. Seconds since epoch or XSD Dates.
>
> Here's the RESTful spec:
> Dates and timestamps are represented as strings containing AtomPub
> (RFC3339) format date-time elements; see section 3.3 of [RFC4287].
> These are also known as "XSD Dates". In cases where only a
> day-of-the-year is desired, e.g., a birthday, the year SHOULD be
> specified as 0000.
>
> Which conflicts with the JS
> A string specifying the time at which this activity took place in
> milliseconds since the epoch.
>
> What is the ultimate storage format?
>
> davep
>
> On Mon, Jun 30, 2008 at 12:36 PM, John Panzer <jp...@google.com> wrote:
> > LG, except for the human readable id strings like 'canonical', and that
> the
> > dates are in some unknown format (1/1/1999); would be good to document
> the
> > format or better yet use xsd dates.
> >
> > John Panzer (http://abstractioneer.org)
> >
> > On Mon, Jun 30, 2008 at 12:29 PM, Louis Ryan <lr...@google.com> wrote:
> >
> >> I've created a JIRA issue with a sample JSON DB patch attached here
> >>
> >> https://issues.apache.org/jira/browse/SHINDIG-413
> >>
> >> There are definitely issues with some of the data that I will work on. I
> >> will also ping on the RESTful discussion list to point folks at this
> data
> >> as
> >> I think it makes sense to use the same data in the spec document and in
> the
> >> canonical DB.
> >>
> >> I am working on a driver for this structure and I should have a patch
> ready
> >> today
> >>
> >> On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <dp...@google.com>
> >> wrote:
> >>
> >> > Sounds great to me as well, looking forward to seeing it in the sample
> >> > container.
> >> >
> >> > -Dan
> >> >
> >> > On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
> >> >
> >> > > That would be really useful for ensuring compatibility between PHP
> and
> >> > > Java.
> >> > > It definitely beats the simple xml fetcher thing :)
> >> > >
> >> > > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com>
> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I would like to propose a canonical data implementation for use in
> >> > > Shindig
> >> > > > for unit and end-to-end testing based on a JSON structure that we
> >> check
> >> > > > into
> >> > > > SCM.
> >> > > >
> >> > > > The idea is pretty simple, define a JSON structure that contains
> the
> >> > > > canonical data in the form described in the RESTful spec.
> Something
> >> > like
> >> > > >
> >> > > > { "people" : < an array of Person JSON objects>,
> >> > > > "activities" : <an array of Activity JSON object for people>,
> >> > > > "data" : <an array of app-data for people>,
> >> > > > "friendLinks" : < a mapping between people id's to simulate
> friend
> >> > > links>,
> >> > > > "dataLinks" : < a mapping between people id's and their app data>
> >> > > > }
> >> > > >
> >> > > > This structure is loaded into a JSON DB driver and used to satisfy
> >> > > service
> >> > > > requests. The driver will support CRUD operations on activities
> and
> >> > data
> >> > > in
> >> > > > line with the spec.
> >> > > >
> >> > > > Advantages:
> >> > > > - Fully exercises the JSON side of the RESTful spec and its
> binding
> >> to
> >> > > > POJOs
> >> > > > etc
> >> > > > - Supports simple mutability
> >> > > > - Its canonical!
> >> > > > - Shared between all the implementations
> >> > > >
> >> > > > Im working on creating some data which Ill send out if folks are
> >> > > interested
> >> > > >
> >> > > > -Louis
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Proposal : JSON backed canonical data set
Posted by David Primmer <da...@gmail.com>.
I too am curious how the 'canonical' id will get specified. I'm
assuming Louis just 'punted' on this one for now.
However regarding the dates: the dates that seem to matter are not in
the format that John mentioned. Updated and PostedTime matter. Can't
"dateOfBirth" : "1/1/1975", be an string?
We definitely need to resolve the date format thing for these two
fields. Seconds since epoch or XSD Dates.
Here's the RESTful spec:
Dates and timestamps are represented as strings containing AtomPub
(RFC3339) format date-time elements; see section 3.3 of [RFC4287].
These are also known as "XSD Dates". In cases where only a
day-of-the-year is desired, e.g., a birthday, the year SHOULD be
specified as 0000.
Which conflicts with the JS
A string specifying the time at which this activity took place in
milliseconds since the epoch.
What is the ultimate storage format?
davep
On Mon, Jun 30, 2008 at 12:36 PM, John Panzer <jp...@google.com> wrote:
> LG, except for the human readable id strings like 'canonical', and that the
> dates are in some unknown format (1/1/1999); would be good to document the
> format or better yet use xsd dates.
>
> John Panzer (http://abstractioneer.org)
>
> On Mon, Jun 30, 2008 at 12:29 PM, Louis Ryan <lr...@google.com> wrote:
>
>> I've created a JIRA issue with a sample JSON DB patch attached here
>>
>> https://issues.apache.org/jira/browse/SHINDIG-413
>>
>> There are definitely issues with some of the data that I will work on. I
>> will also ping on the RESTful discussion list to point folks at this data
>> as
>> I think it makes sense to use the same data in the spec document and in the
>> canonical DB.
>>
>> I am working on a driver for this structure and I should have a patch ready
>> today
>>
>> On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <dp...@google.com>
>> wrote:
>>
>> > Sounds great to me as well, looking forward to seeing it in the sample
>> > container.
>> >
>> > -Dan
>> >
>> > On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
>> >
>> > > That would be really useful for ensuring compatibility between PHP and
>> > > Java.
>> > > It definitely beats the simple xml fetcher thing :)
>> > >
>> > > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I would like to propose a canonical data implementation for use in
>> > > Shindig
>> > > > for unit and end-to-end testing based on a JSON structure that we
>> check
>> > > > into
>> > > > SCM.
>> > > >
>> > > > The idea is pretty simple, define a JSON structure that contains the
>> > > > canonical data in the form described in the RESTful spec. Something
>> > like
>> > > >
>> > > > { "people" : < an array of Person JSON objects>,
>> > > > "activities" : <an array of Activity JSON object for people>,
>> > > > "data" : <an array of app-data for people>,
>> > > > "friendLinks" : < a mapping between people id's to simulate friend
>> > > links>,
>> > > > "dataLinks" : < a mapping between people id's and their app data>
>> > > > }
>> > > >
>> > > > This structure is loaded into a JSON DB driver and used to satisfy
>> > > service
>> > > > requests. The driver will support CRUD operations on activities and
>> > data
>> > > in
>> > > > line with the spec.
>> > > >
>> > > > Advantages:
>> > > > - Fully exercises the JSON side of the RESTful spec and its binding
>> to
>> > > > POJOs
>> > > > etc
>> > > > - Supports simple mutability
>> > > > - Its canonical!
>> > > > - Shared between all the implementations
>> > > >
>> > > > Im working on creating some data which Ill send out if folks are
>> > > interested
>> > > >
>> > > > -Louis
>> > > >
>> > >
>> >
>>
>
Re: Proposal : JSON backed canonical data set
Posted by John Panzer <jp...@google.com>.
LG, except for the human readable id strings like 'canonical', and that the
dates are in some unknown format (1/1/1999); would be good to document the
format or better yet use xsd dates.
John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 12:29 PM, Louis Ryan <lr...@google.com> wrote:
> I've created a JIRA issue with a sample JSON DB patch attached here
>
> https://issues.apache.org/jira/browse/SHINDIG-413
>
> There are definitely issues with some of the data that I will work on. I
> will also ping on the RESTful discussion list to point folks at this data
> as
> I think it makes sense to use the same data in the spec document and in the
> canonical DB.
>
> I am working on a driver for this structure and I should have a patch ready
> today
>
> On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <dp...@google.com>
> wrote:
>
> > Sounds great to me as well, looking forward to seeing it in the sample
> > container.
> >
> > -Dan
> >
> > On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > That would be really useful for ensuring compatibility between PHP and
> > > Java.
> > > It definitely beats the simple xml fetcher thing :)
> > >
> > > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I would like to propose a canonical data implementation for use in
> > > Shindig
> > > > for unit and end-to-end testing based on a JSON structure that we
> check
> > > > into
> > > > SCM.
> > > >
> > > > The idea is pretty simple, define a JSON structure that contains the
> > > > canonical data in the form described in the RESTful spec. Something
> > like
> > > >
> > > > { "people" : < an array of Person JSON objects>,
> > > > "activities" : <an array of Activity JSON object for people>,
> > > > "data" : <an array of app-data for people>,
> > > > "friendLinks" : < a mapping between people id's to simulate friend
> > > links>,
> > > > "dataLinks" : < a mapping between people id's and their app data>
> > > > }
> > > >
> > > > This structure is loaded into a JSON DB driver and used to satisfy
> > > service
> > > > requests. The driver will support CRUD operations on activities and
> > data
> > > in
> > > > line with the spec.
> > > >
> > > > Advantages:
> > > > - Fully exercises the JSON side of the RESTful spec and its binding
> to
> > > > POJOs
> > > > etc
> > > > - Supports simple mutability
> > > > - Its canonical!
> > > > - Shared between all the implementations
> > > >
> > > > Im working on creating some data which Ill send out if folks are
> > > interested
> > > >
> > > > -Louis
> > > >
> > >
> >
>
Re: Proposal : JSON backed canonical data set
Posted by Louis Ryan <lr...@google.com>.
I've created a JIRA issue with a sample JSON DB patch attached here
https://issues.apache.org/jira/browse/SHINDIG-413
There are definitely issues with some of the data that I will work on. I
will also ping on the RESTful discussion list to point folks at this data as
I think it makes sense to use the same data in the spec document and in the
canonical DB.
I am working on a driver for this structure and I should have a patch ready
today
On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <dp...@google.com> wrote:
> Sounds great to me as well, looking forward to seeing it in the sample
> container.
>
> -Dan
>
> On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
>
> > That would be really useful for ensuring compatibility between PHP and
> > Java.
> > It definitely beats the simple xml fetcher thing :)
> >
> > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com> wrote:
> >
> > > Hi,
> > >
> > > I would like to propose a canonical data implementation for use in
> > Shindig
> > > for unit and end-to-end testing based on a JSON structure that we check
> > > into
> > > SCM.
> > >
> > > The idea is pretty simple, define a JSON structure that contains the
> > > canonical data in the form described in the RESTful spec. Something
> like
> > >
> > > { "people" : < an array of Person JSON objects>,
> > > "activities" : <an array of Activity JSON object for people>,
> > > "data" : <an array of app-data for people>,
> > > "friendLinks" : < a mapping between people id's to simulate friend
> > links>,
> > > "dataLinks" : < a mapping between people id's and their app data>
> > > }
> > >
> > > This structure is loaded into a JSON DB driver and used to satisfy
> > service
> > > requests. The driver will support CRUD operations on activities and
> data
> > in
> > > line with the spec.
> > >
> > > Advantages:
> > > - Fully exercises the JSON side of the RESTful spec and its binding to
> > > POJOs
> > > etc
> > > - Supports simple mutability
> > > - Its canonical!
> > > - Shared between all the implementations
> > >
> > > Im working on creating some data which Ill send out if folks are
> > interested
> > >
> > > -Louis
> > >
> >
>
Re: Proposal : JSON backed canonical data set
Posted by Dan Peterson <dp...@google.com>.
Sounds great to me as well, looking forward to seeing it in the sample
container.
-Dan
On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <et...@google.com> wrote:
> That would be really useful for ensuring compatibility between PHP and
> Java.
> It definitely beats the simple xml fetcher thing :)
>
> On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com> wrote:
>
> > Hi,
> >
> > I would like to propose a canonical data implementation for use in
> Shindig
> > for unit and end-to-end testing based on a JSON structure that we check
> > into
> > SCM.
> >
> > The idea is pretty simple, define a JSON structure that contains the
> > canonical data in the form described in the RESTful spec. Something like
> >
> > { "people" : < an array of Person JSON objects>,
> > "activities" : <an array of Activity JSON object for people>,
> > "data" : <an array of app-data for people>,
> > "friendLinks" : < a mapping between people id's to simulate friend
> links>,
> > "dataLinks" : < a mapping between people id's and their app data>
> > }
> >
> > This structure is loaded into a JSON DB driver and used to satisfy
> service
> > requests. The driver will support CRUD operations on activities and data
> in
> > line with the spec.
> >
> > Advantages:
> > - Fully exercises the JSON side of the RESTful spec and its binding to
> > POJOs
> > etc
> > - Supports simple mutability
> > - Its canonical!
> > - Shared between all the implementations
> >
> > Im working on creating some data which Ill send out if folks are
> interested
> >
> > -Louis
> >
>
Re: Proposal : JSON backed canonical data set
Posted by Kevin Brown <et...@google.com>.
That would be really useful for ensuring compatibility between PHP and Java.
It definitely beats the simple xml fetcher thing :)
On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <lr...@google.com> wrote:
> Hi,
>
> I would like to propose a canonical data implementation for use in Shindig
> for unit and end-to-end testing based on a JSON structure that we check
> into
> SCM.
>
> The idea is pretty simple, define a JSON structure that contains the
> canonical data in the form described in the RESTful spec. Something like
>
> { "people" : < an array of Person JSON objects>,
> "activities" : <an array of Activity JSON object for people>,
> "data" : <an array of app-data for people>,
> "friendLinks" : < a mapping between people id's to simulate friend links>,
> "dataLinks" : < a mapping between people id's and their app data>
> }
>
> This structure is loaded into a JSON DB driver and used to satisfy service
> requests. The driver will support CRUD operations on activities and data in
> line with the spec.
>
> Advantages:
> - Fully exercises the JSON side of the RESTful spec and its binding to
> POJOs
> etc
> - Supports simple mutability
> - Its canonical!
> - Shared between all the implementations
>
> Im working on creating some data which Ill send out if folks are interested
>
> -Louis
>