Re: DXS REST Proposal

[Jon Wood <jon instance-design co uk>]

On Mon, 2005-09-12 at 16:08 +0200, <::... SchAmane ...::> wrote:
> У Ндл, 2005-09-11 у 16:21 +0100, Jon Wood пише:
> 
> > I was told that the current proposal is to use SOAP for this, however
> > SOAP tends to be have a lot more bloat than neccesary for the
> > requirements.
> 
> To use SOAP was my idea, so i should write a little bit about why i was
> proposing it.
> This XML (REST) Idea is not bad. After all discussion i am thinking that
> it dont have much matter what technology would be used. We have
> something what work, and what it is - no matter. So if somebody start do
> implementation - its already good enough.
> 
> Why i still prefer SOAP - there is no need for writing libs. At this
> moment many languages understand SOAP natively (php,perl,mono,java,c/c
> ++).
> 
> Second is, you define whole stuctures of data on server side. And it can
> be fast updated with WSDL for programmer.
> There are Namespaces to place all on their places.
> Its easier for client to handle SOAP, than to parse XML.
> 
Updating the WSDL definitions doesn't take effect in most languages
until the web service stubs are regenerated, and code merged back in to
handle any new or changed methods. Programmer interaction is still very
much needed to handle things efficently.

Using plain XML in the method I'm suggesting can also be done easily -
in the case of PHP I'm aware of SimpleXML which can convert XML
documents into a data structure which can be used like any other object.
I'm sure equivalents are available for other dynamic languages.

I'd also be interested to know the target audience for DXS - are there
actually any people out there intending to use DXS with C or C++
applications for example. It seems at this point that gnome-art is the
only consumer, and I'm not sure what would change that if gnome-art does
the job well.

> > I have written a proposal on using a simpler system based on HTTP
> > GET/POST requests, which return the data in a much smaller, more
> > readable, format. This makes it a lot easier to debug, and reduces the
> > ammount of bandwidth required.
> 
> SOAP is POST request too. But client or server side do not care about
> communication.
> How much bandwidth would SOAP need vs. REST? Not much. Request would be
> definitively bigger, but result would not relatively much bigger. SOAP
> is about some bytes more per Request/Answer than REST.
> 
A comparison of the same data packet encoded as SOAP and REST shows a
253 byte increase in size for the SOAP packet - this is for a 3 record
category listing, and would increase as the ammount of data being
returned does, due to having to define and use namespaces.

That's 1/4 of a kb for a trivial example - when we're looking at
transferring large numbers of thumbnails at the same time any size
consideration is important.

> Debug.
> Its very easy to debug SOAP, there is already Error Handling build in.
> Server can send client some error( or even) debug data. You can handle
> it on client side.
> On server side there is "php-log" class, which can save error messages
> to DB, file, or Syslog. So there is no really troubles with it.
> I already done initial work for backgrounds. It was very easy.
> Unfortunately it don't work at this time properly, because i think DB
> layout is little bit different to latest i was used.
> 
Ok, development level debugging I'll concede on then :)

One of the benefits of using REST is the ability to check what is
happening easily by simply reading the output of the request you're
making.

> > While it will require writing libraries to process the information, I
> > believe this will take less time in the long term than using SOAP.
> 
> I wouldn't so sure. First - nobody will have new library.
>
I'm assuming that the library would be released at some point! Evolution
transitioned to requiring e-d-s, and as far as I'm aware they had no
problems with people not having it.

Library dependencies are handled at distribution level in almost all
cases, I'm not sure why it would be any different here.

> Second, its not as long to take SOAP work as here is described. You can 
> build simple SOAP service with client in 5 min.
>
> > You can find the proposal at http://wiki.jellybob.co.uk/dxs 
> 
> Here is how SOAP code looks on server side:
> http://dxs-project.org/moin.cgi/ServerExample
> 
> For every class we need must be one Class (Backgrounds, Icons, GTK,
> GamesStuff, etc).
> This is example how Backgrounds Class should look. There is constructor,
> wich deskribes which methods are on the service usable and which complex
> types we have. There are also two methods:
> 	function getItem($id)
> and
> 	function getItems($xpath,$startpos,$count,$temp)
> 
> whey connect DB server and ask for needed data, than transmit it as
> array, or one object to the client. So client side just make new
> instance of the items, and allready can use it.
> 
The same can be done with a well designed REST service - I think I need
to clarify things here...

I'm not suggesting that the XML output be hand written for every
instance! I'd create a class (or possibly even just a function) capable
of converting whatever type of data is chosen, I'm thinking of arrays at
this point, into a REST packet which fits the standard.

Something like (excuse the formatting):
  
  <?php
  require_once('adodb_lite/adodb.inc.php');
  
  $items = array();
  $db = NewADOConnection('mysql');
  $db->Connect('localhost', 'xxx', 'xxx', 'xxx');
  $rs = $db->Execute("SELECT backgroundId, background_name, version,
thumbnail_filename, FROM background LIMIT 10;");
  while (!$rs->EOF) {
    $items[] = array('id' => $rs->fields['backgroundID'],
                     'name' => $rs->fields['background_name'],
                     'version' => $rs->fields['version'],
                     'thumbnail' => $rs->fields['thumbnail_filename']);
    $rs->MoveNext();
  }
  $db->close();
  
  array_to_rest($items);
  ?>

> There are any other things to do:
> 1. Design whole server/client communication to reduce count on requests.
> We need ideas about caching, what client should ask and how.
>
I'd suggest you save the cache design until there is an idea of what
*needs* caching - until there is some real world experience of using
this service all that can be done is educated guesses as to what will
happen.

An educated guess is still just a guess ;)

> 2. Make Service more bunle to web-page, so if somebody change DB layout
> it would be no need to rewrite something in web-service.
> 
This sounds more like an overall design issue to me - from the example
code you showed it appears that there is minimal code reuse going on,
which is going to cause problems with multiple access methods.

While it will take some time, I'd suggest going for a more object
oriented approach to things - much how is being suggested here, but all
the way down to database level. This will also give you the benefit of
being able to better seperate display and business logic.

Jon Wood