XML-PRC

Hi everybody,

As Mark has correctly predicted, I have given up on XML-PRC after a weekend
of trying. The theory is great, and I still *theoretically* prefer it over
the messy construction of HTML by php. But I have wasted many hours by
trying to get it to work, with no avail. The biggest problem is, as Mark
pointed out, the missing debugging possibilities. One is just not able to
see what client and browser are sending, and this drives you up the wall
since you never know at which level the error occured.

So I repent and go back to GET requests and loading windows into netWindows
instead of programmatically constructing them from data.

Christian

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Mark Anderson
> Sent: Saturday, August 09, 2003 1:50 PM
> To: netWindows development discussion list
> Cc: 'Peter West'; [email protected]
> Subject: Re: [NW-Devel] netWindow - PHP data transfer model
> 
> 
> 
> >The debugging argument is a good point. The reasons why I 
> was thinking 
> >of XMLRPC are the following: First of all, servers and clients are 
> >already there, all we need to do  is to include the code. 
> Second, the 
> >data format is such that I would be able to write, for 
> example, a PyQt 
> >desktop application which taps into the datasource or 
> replace the PHP 
> >backend with a Python one. Not that I am thinking of doing 
> that at the 
> >moment, I just thought it would be a good idea to keept the data 
> >abstracted.
> >
> you may want to support several different response formats. 
> i've built systems where the query url has a "format" 
> parameter that can 
> cause the
> response to be in presentable html, an xml vocabulary, csv text, or a 
> javascript expression.
> 
> this is not an argument for xml-rpc.
> any platform is capable of fetching a URL with arbitrary parameters; 
> this is in fact easier
> and simpler than formatting an xml-rpc request.
> 
> as for the response, yes, you could choose to format it in 
> the xml-rpc 
> fashion, but
> then your tags are in the xml-rpc vocabulary, not your 
> application-specific vocabulary.
> 
> >But then, how do you send a javascript array from the browser to the 
> >server via the command line?
> >
> I was only proposing javascript expressions as the response 
> format, not 
> the request format.
> 
> >You need to explain that to me. I thought that I could use 
> any GPL'ed 
> >code in my application as long as I make the source code available - 
> >and how does the AFL tie in here? Our project is to be 100% 
> open source 
> >and we would like to use as much of OS code as possible, not only 
> >because it saves us time but also out of principle --- why 
> reinvent the 
> >wheel each time one writes an application? But tell us about the 
> >pitfalls.
> >
> GPL in principle requires that every other component of your 
> "program", 
> and the "program"
> itself, must have a license that the FSF deems to be 
> GPL-compatible. (Not just "open source").
> 
> But who knows what GPL really means in the case of a 
> javascript library. 
> It would be
> hard to believe it would have any consequences for 
> server-side code such 
> as PHP.
> Since people debate what the GPL implies for java (because of 
> its VM and 
> dynamic
> class loading), it is also debatable what it means even for other 
> javascript code.
> 
> >The idea is that end users should have the largest choice 
> possible as 
> >to the backend and also that the final application should be able to 
> >run in the most minimal environment. It should also run on a 
> PHP server 
> >that does not provide an SQL database at all. So the idea is 
> that when 
> >the app cannot detect a database, it will use an XML backend. Of 
> >course, many functions then will not work.
> >
> 
> I can tell you from painful personal experience that you are in for a 
> world of hurt
> if you are going to attempt any updates to these xml files as part of 
> your app, unless
> you are willing to serialize all data operations.
> Furthermore, i predict you'll find there is no right level to 
> break the 
> "virtual" xml tree
> into individual files.
> 
> Also, even if you have a query library like PEAR that 
> mitigates xml and 
> rdbms differences
> at the DML level I'm sure it does nothing about schema or 
> DDL. And all the many different xml schema approaches extant 
> today are a 
> PITA, IMHO.
> Plus, while schema evolution has been an understood problem 
> for decades 
> in the rdbms
> world, it is still a research problem in the xml world.
> 
> You might instead consider using a sql library that can be 
> linked into 
> php (not client server).
> That would allow you to support environments with the 
> inability to run a 
> server of choice.
> An example would be SQLite or CQL++.
> I've also had good luck using a "text csv" odbc driver (that is, ODBC 
> layered on top of csv files),
> as long as you are careful with locking.
> 
> Btw, I assume you've looked at existing bibliographic systems such as 
> citeseer.
> 
> -mda
> 
> 
> _______________________________________________
> The netWindows developers list: [email protected] 
> http://netwindows.org/mailman/listinfo/devel_netwindows.org
> 
> 


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org