Re: 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