FW: Data synchronization

[Ruslan Zasukhin]

------ Forwarded Message
From: Andre Garzia <andre at andregarzia.com>
Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
Date: Mon, 3 Sep 2007 20:55:00 -0300
To: How to use Revolution <use-revolution at lists.runrev.com>
Subject: Re: Data synchronization

Hello Alex,

I don't know much about Valentina but I decided to chop in this thread
(which I read and learned much from). If you make a litte server using
Valentina and an HTTP server on front, I'd advise you to work the following
way:

Define a clear HTTP based API for accessing your server. Try to use whats
being called "REST" which is a fancy name for using URLs and HTTP Methods to
simplify interfacing with a server, it's way easier to work with a RESTful
server than working with SOAP.

script your GET requests to acquire data from the DB. You can make your URLs
match your database design. for example, you're building a documentation
database:

  GET  /  (gets all records)
  GET  /category  (gets the categories available)
  GET /category/installing  (get records with category "installing")

The idea is to make sane URLs that are both human readable and machine
processable. If your entries have a timestamp marking the last modification,
you can create a URL such as:

  GET /recentchanges  (get the newest records)
  GET /modified/2007/10/06  (get records modified since 2007/10/06)

This will make easier to detect changes in the DB and replicate the changes
between clients. Use PUT calls to insert data onto your database, you can
put the content of the request as a XML with the fields and data for your
DB. If you're felling bold, you can use smart urls for insertion too.

  PUT /  (all content for the record is inside the request)
  PUT /category/installing  (the "category" for this request is obtained
from the URL)

The above snippet is not as useful as the GET requests, inserting data is
easy, querying data is what makes your system easy to extend and implement.
To modify a record use the POST method. Here it is a good idea to use fancy
urls such as:

  POST /id/1234 (changes record #1234)

Or you can insert all data into the request. The idea of URLs for modifying
data is to be able to query and modify batches of records with a single
request. For example suppose your documentation system has entries tagged as
"draft" or "publish", by switching this status setting you make some FAQ
available to the end user. You can have a request such as:

  POST /drafts/user/Soapdog  (will change all drafts by user "soapdog")

In this request you can simply add the XML to update the draft field to
publish. This can easily be done with SQL queries and in the end, this will
of course become a SQL query somewhere inside the system. The question you
must ask yourself is, do I want to put SQL in my HTTP Requests or should I
build my own XML/URL Dialect to make queries?

The second takes time but pays in the long run since you can tailor your
software to the specific needs of your system/workflow. This option will
make you have the better tool for doing your job since you created a DSL
(domain specific language) that is fine tunned to your job instead of using
the general purpose SQL.

Now getting back to the syncronization problem. Using the smart URLs you can
discover what's been changed in the database and fetch them easily. By
fetching just what you need, you reduce your bandwidth usage and you also
reduce the load on the RevOnRockets server which is single threaded anyway.
You can also make a little MD5 field on your records that you can use as a
locking sytem so that users don't overwrite each other. This MD5 record must
be sent with each POST request, if they don't match the one in the central
database, it means someone else altered the records in the meanwhile and you
should refetch that record and revise your changes.

does this help?
andre

>
>
>
>
_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

------ End of Forwarded Message