Comments on: Persistent Objects with Persevere the client and Jsponic the server

By: Kris Zyp

Kris Zyp — Thu, 01 Nov 2007 04:48:17 +0000

SchizoDuckie:
You are right, it was overly complicated, the client-server REST communication should be as simple and
readable as possible. I have revised Persevere to use semantic REST method communication that is simple
enough you can intuitively persist data to the Persevere server with simple XHR-HTTP requests using a
bare HTTP client (like RESTTest).

By: mikael bergkvist

mikael bergkvist — Thu, 04 Oct 2007 15:59:30 +0000

“If widgetplus does have something to offer to the topic at hand, please link to a page that explains more”

Ok, this page in particular then, http://www.widgetplus.com/testbed2.htm

By: Kris Zyp

Kris Zyp — Wed, 03 Oct 2007 04:11:31 +0000

Justin,
PJS is not constructor, pjs is just a namespace for the API, but you have the right idea. So you could do:
tasks = pjs.load(‘/tasks/’); // causes a get request for the url ‘/tasks’ and assumes that it returns a JSON array of tasks
tasks[1] == pjs.load(‘/tasks/1′) // this should be true
And yes, if you have a relationships setup correctly, you could do
myproject = pjs.load(‘/projects/18′)
mytask = myproject.tasks[2];
As far as the REST operations, Persevere currently does not use the PUT and DELETE verbs. Persevere uses a more idioms more similiar to JavaScript where you don’t delete objects, you delete references to objects, so DELETE is not really an appropriate verb. I can easily use the PUT verb, but to actually follow the HTTP spec for PUTs is just too constraining for dynamic data and scalability. In particular, Persevere wraps multiple operations into single requests. This improves performance and it provides a natural indication of transactions. I could use the PUT method to indicate that data is being put, but I have wanted to be more precise in sticking to the HTTP/REST specifications so I have not done that. I could certainly change that.
I would certainly be interested in seeing what would need to be done to implement JSPON compliance with RoR. Maybe I need to learn RoR…

By: Justin Meyer

Justin Meyer — Wed, 03 Oct 2007 01:07:16 +0000

Mikael, please stop spamming Ajaxian. I’ve seen you link to your homepage at least 3 times in the past month or so (http://ajaxian.com/archives/google-launches-javascript-api-that-allows-you-to-write-back).
But you never link to anything useful to the discussion.

If widgetplus does have something to offer to the topic at hand, please link to a page that explains more.

Kris, I’m using RoR, but I’m often making RESTful JSON services. Something like – get: /tasks/1 returns
{ id: 2, name: ‘mow lawn’ }

On a high level,
What would I have to do to change Rails default services to implement JSPON?

Does JSPON rest services use the same type of URL method maping (i.e. get, post, put, delete, with urls like /tasks/1) as typical REST services?

Assuming the conversion would be trivial, how would I open the resource?
Would their be a different pjs for each model? Something like:
taskpjs = new PJS(‘/tasks’)
taskpjs.load(1)

projectpjs = new PJS(‘/project)
projectpjs.load(18);

If a project had many tasks, I’d also like to do something like

projectpjs.tasks

and get a list of tasks

Is this possible?

By: Kris Zyp

Kris Zyp — Tue, 02 Oct 2007 14:48:49 +0000

SchizoDuckie: Persevere does indeed wrap up all the changes that occur in a given event into a single request (it doesn’t try to send each one individually). This also provides implicit transaction wrapping. However, it doesn’t usually wait for the end of the session. While that is certainly possible to do with Persevere, that does not seem to be advantageous, generally you want information to get back to the server as soon as possible so that other clients can use it.
Mikael: I don’t see any info on your site about persistence, it looks like it is about widgets. And actually the persevere project originally sprung from a widget based framework Authenteo, but I realized that developers probably want a solution that doesn’t require there whole UI tightly coupled to their persistence layer.

By: Mikael Bergkvist

Mikael Bergkvist — Tue, 02 Oct 2007 14:19:34 +0000

We have done this way easier over at http://www.widgetplus.com ..

By: SchizoDuckie

SchizoDuckie — Tue, 02 Oct 2007 13:24:41 +0000

While i get the whole persistency thing, i think this is kinda over-the-top (as with most Java-based stuff) For instance, i quote (from the specs):

append this will append new values to the array. This should have an array as a value. Each array item should be a value to be inserted in the modified array. For example: {"id":"5", "update":{ "append":[{"id":"9"}] }} The array would now have one additional value, the object with an id of "9".

Now WHY would you want to communicate this stuff with every change? You're going to do a JSON request via a JSON dialect to update a JSON array ? This is (IMO) typically the Java kind-of-thinking: The server *must* know about everything that's going on on the client and the server must do the processing. If I would build a persistency layer, i'd transmit the whole serialized objects at the beginning of a user session to load something and at the end of the session (onUnload) to store the state.

By: Ric Johnson

Ric Johnson — Tue, 02 Oct 2007 13:18:11 +0000

The links are broken. Also, you forgot to put in a link to the original story at Json.com