| 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.
|