RE: netWindow - PHP data transfer model

Hi,

Thanks for your comments, they are very helpful.

> I think that the XML-RPC sections might be redundant with the 
> new version of 
> the __data__ object that I'm working on [...]

Alex, when do you expect this data object will be working? We are so early
in our planning that we could still work it in. 

> > - I'm not sure xmlrpc buys you anything. It requires the javascript 
> > side to encode requests into xml, and decode responses from 
> xml. Also 
> > (and this is important), it undermines the ability to test 
> your data 
> > server with a browser by typing things into the address bar.

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. 

> > Whatever your server layer is that does xml-rpc, could just 
> as well do
> > REST: decode a url to make a request, and then send a 
> response in an 
> > appropriate format. In this architecture, a more efficient response 
> > format than XML would be javascript text that could be directly 
> > eval'd. (That is, you'd have a nested array [] and hash {} data 
> > structure).

But then, how do you send a javascript array from the browser to the server
via the command line?

> > - that particular xml rpc javascript library is GPL.  A 
> more loosely 
> > licensed one is http://scottandrew.com/xml-rpc/
> This is an important point, as there is some debate as to 
> whether the AFL is 
> GPL compatible. Larry Rosen says "yes", RMS says "no". Thar 
> be dragons thataway.

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. 

> > - just because PEAR::Tree gives you storage abstraction 
> does not mean  you want to try to take advantage of all the alternatives 
> at once. I  would not try to have a system that relied both on persistent
xml 
> > files and on a sql database> unless for some reason it is 
> absolutely necessary. Because of the need for query-style reports and 
> > understandable indexing behavior, a real sql database is probably 
> > preferable. You might in some cases want to store free-form xml as 
> > opaque strings in the sql database, if they cannot be 
> subjected to a  strict schema. Not knowing anything about your needs, I'd 
> consider not using persistent xml files nor mysql, but use postgres.

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 know that all these ideas go against speed and efficiency of the data
processing, and might seem counterintuitive to experienced developers. I am
thinking about academics who want to install such a bibliographic
applications with the smallest and cheapest hosting requirements as
possible.  Postgres is, as far as I can tell, not very widespread among the
low-level hosting environments, and we do not want to rely on a commercial
database for the same reason. I personnally also want to be able to connect
to a ODBC database where my personal bibliographic data is stored, with the
exact same interface. PEAR::Tree seems such a incredibly flexible tool, even
if it might have a large overhead and might be suboptimal in terms of speed.


> - don't forget about UI design! if users can't make sense 
> of it, all  the work is for nothing.
> Let the list know if you need help in finding someone who can 
> help you out in this respect or if you need help with a particular UI
design 
> choice. NW  doesn't have a "style guide" the way many other UI toolkits 
> do, but that  doesn't mean we're not interested in it or can't help
improve 
> NW GUIs. That is the point of NW after all: to make web GUIs more useable.

That's very nice of you and maybe we can make our app one of the showcases
for netWindows this way (and the other way round). We will certainly need
some guidance on the Syntax (waiting eagerly for Alex'es HOW-TO ;-) ) As I
said, get a sample Webapplication - even the most simple one - going on the
Website, and people like use can look at the code, cut & paste, and learn
this way...

Christian 


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