Newbie questions about Pliant
One database, many clients
How can I use the pliant's native db mechanism to have several computers running a copy of my application use the same database ?
|
Message posted by maybe Boris Reitman on 2004/11/17 21:35:09 |
Hello,
I am working on a Point-of-Sale GUI program in pliant and wxWindows. Each computer terminal in my retail store needs to run a copy of the interface. What would be the simplest way to arrange that ? The program uses pliant's native db support (the .pdb file). If several different computers run the program, I suppose that I could configure to place the .pdb file on a shared filesystem. But, if one client program will update the .pdb file, how will the rest of the programs know that they need to sync up ? I would like to have the client programs to do minimal work while updating. For example, the interface has a realtime search result window that lists records that match certain criteria. When the database is updated, I would like the search result to be also updated, in each running client.
Alternatively to sharing the .pdb file, I am thinking of having a client server model, where the server will know how to load and save data from the database, and clients will send the data over TCP/IP with something like XML or RPC.
What approach is the fastest to implement ? Thanks, Boris |
Message posted by hubert.tonneau on 2004/11/17 23:03:39 |
Ok, let's start from the beginning, assuming that you want to devellop a modern (reliable, good looking) database centric application.
First of all, file sharing is a bad idea because it's the old eightees technologie that we got at the beginning of microcomputers, and anybody having used it a bit intensively soon discovers it's limit: unacceptable poor reliability since any problem on one of the clients (slow, crash) or on the network will impact all others.
So, next step is client server model for the database (SQL server) and it basically solves the huge reliability problem, but then you discover the more subtil problems: . fat client (needs an up to date application) . poor security (serious access rights cannot be defined at table records or cell level)
If you need serious security, you will end with object oriented client server model, called stored queries in SQL world, but simply RPC (remote procedure call) in facts. What is strange about it is that when you switch to RPC, you don't need the client server database model anymore, but many people seem more confident with sticking to it anyway.
For the fat client problem, it's a bit harder: you need to run the application on the server side, so you need a way to exchange the user interface datas between the client and the server instead of the application datas. The straight forward way to do that is X11. Now, X11 as a remote display system carries a set of problems of it's own: . potencially huge flow of datas . positioning computations must be performed on server side
As a result, people are slowly switching to HTTP/HTML/Javascript as an X11 replacement, mainly because the browser is computing positioning so the server does not have to deal with low level details, but then the next problem raises: Good looking is hard to achieve.
So, you end with discovering the need for the Pliant browser. The only serious problem for you is ... that it's not usable yet.
PS: If you think of wxWindows, that it's only part of the solution: you need to design (assuming wxWindows is not running under X11) your own drawing instructions and events transport between the client and the server, and it's highly likely that at the end, you will get something more complicated than the Pliant browser.
|
Message posted by maybe Boris Reitman on 2004/11/18 06:58:09 |
My program runs currently on X11; in order to get it to run on MS Windows I need to put more work into it.
(More precisely, I need to make sure that my pliant-perl binding runs on windows. In fact I am using wxPerl which is a perl wrapper onto wxWindows. This allows me not to worry about wrapping C++ functions -- the perl people are already working on it. wxWindows by itself works on all platforms, by design. Its actually a wrapper onto different toolkits, giving them a uniform interface.)
So given that all my clients/terminals have an X server, and this is a LAN, so that the connection is fast, how would I use the X11 protocol to my advantage ? Should I send different window instances to different= X servers ? All from the same running application ? If yes, would the core of the application run in some kind of daemon mode, and create window instances on request ? Is there a spec for the pliant browser? Can I run it ? I realize that its not ready for this project, but I am just curious. |
Message posted by hubert.tonneau on 2004/11/19 23:18:21 |
You could try the Pliant browser though starting the server: pliant module /pliant/graphic/browser/test.pli
Then starting the client: pliant module /pliant/graphic/browser/client.pli command 'browser ""'
The main problem is that some key parts of the browser are still missing: . the events handling sucks . some browser tags are still missing . the server side high level API (.page equivalent) is missing . the fonts providing mechanism is missing . the unknown tags automatic resolution protocol is missing . the shared datas mechanism needs to be polished . the instructions set between the client and server is not frozen
As a result, the Pliant browser is not good yet, even as a proof of concept.
|
Message posted by hubert.tonneau on 2004/11/19 23:35:08 |
Here is a gentle introduction to the Pliant browser concepts.
The server is providing to the client 'what should be displayed' as a tree (think about XML, it's basically the same).
Also instead of sending the all thing at once (HTTP), there is a language between the client and the server that enables to send the tree through a set of simple instruction (such as create a new node, then attach attributes to the node, then connect the node to another one, etc) You could think of it as DOM implemented in the transport protocol rather than as a client side language.
The browser is doing positioning, then drawing. Each node contains the tag (same as HTML), and the browser has some rules to do positioning and drawing for the basic tags.
Now, when the server wants to do more complex data presentation, I mean would need new tags, then it declares the new tags to the client through saying what server knows how to handle these. So the browser does not need to be upgraded to render the more complex presentation correctly: it will simply connects to the specified server, provides it the requested informations about the subtree it cannot render on it's own, and the server will send it back how to render the subtree through more basic tags.
Since in the basic tags, we have very prowerfull low level drawing primitives (think as PostScript or SVG), plus high resoluton bitmaps (no equivalent, VNC would be the closest), it is always possible to turn the complex presentation to the existing low level instructions set (already frozen and defined in /pliant/graphic/draw/prototype.pli).
As a result, you see that, on the client side we get to a situation where upgrading the browser is just a way to save bandwidth, so improve responsiveness, and on the server side, the application does not have to deal with any low level presentation related issue: it can basically send XML equivalent and let the browser reliability handle it.
|