Hi,
I want to write a small system that is transaction based.
I want to split the GUI front end data entry away from the file handling and
record keeping.
Now it seems almost trivially easy using the sockets module to communicate
between machines on the same LAN, so that I want to do the record keeping on one
machine.
I want to keep the "server" machine as simple as possible - just doing record
keeping on a stimulus response basis - I would prefer it to do one thing at a
time to completion because this style of operation, though limited in
performance, keeps a lot of hassles out of life - a transaction has either
completed, or it has not - recovery scenarios are relatively easy...
Up to this point, I don't have a problem - my toy system can create a dummy
transaction, and I can echo it from the "server" machine, with more than one
"user" machine running - so I think it is feasible to have several tens of "data
entry terminal" systems running, served by one not very strong machine.
Now what I would really like to do is to differentiate between the 'User"
machines, so that some can do a full range of transactions, and others a limited
range.
And I would like to make this flexible, so that it becomes easy to introduce new
transactions, without having to run around updating the code in all the user
machines, with the concomitant version number hassles.
And I would like to do the whole thing in python - so my question is this - is
it possible to do the equivalent of dynamic linking? - i.e. if I keep a list of
what a user is allowed to do - can I somehow send him just the bits he needs to
do the job, without having to change the static code on his machine? - it seems
to me that the eval() thingy could possibly do this for me, by sending it data
that makes it do import statements followed by calls to whatever... - will this
work, or is there a better way?
Or has all this been done already? - and no I don't want a web server and php
and browsers and Java and html or xml... - I want to write something that works
simply and reliably - its just short message accounting type data...
- Hendrik
28  2585 
H J van Rooyen wrote:
Hi,
I want to write a small system that is transaction based.
I want to split the GUI front end data entry away from the file handling and
record keeping.
Now it seems almost trivially easy using the sockets module to communicate
between machines on the same LAN, so that I want to do the record keeping on one
machine.
I want to keep the "server" machine as simple as possible - just doing record
keeping on a stimulus response basis - I would prefer it to do one thing at a
time to completion because this style of operation, though limited in
performance, keeps a lot of hassles out of life - a transaction has either
completed, or it has not - recovery scenarios are relatively easy...
Up to this point, I don't have a problem - my toy system can create a dummy
transaction, and I can echo it from the "server" machine, with more than one
"user" machine running - so I think it is feasible to have several tens of "data
entry terminal" systems running, served by one not very strong machine.
Now what I would really like to do is to differentiate between the 'User"
machines, so that some can do a full range of transactions, and others a limited
range.
And I would like to make this flexible, so that it becomes easy to introduce new
transactions, without having to run around updating the code in all the user
machines, with the concomitant version number hassles.
And I would like to do the whole thing in python - so my question is this - is
it possible to do the equivalent of dynamic linking? - i.e. if I keep a list of
what a user is allowed to do - can I somehow send him just the bits he needs to
do the job, without having to change the static code on his machine? - it seems
to me that the eval() thingy could possibly do this for me, by sending it data
that makes it do import statements followed by calls to whatever... - will this
work, or is there a better way?
Or has all this been done already? - and no I don't want a web server and php
and browsers and Java and html or xml... - I want to write something that works
simply and reliably - its just short message accounting type data...
- Hendrik
Don't reinvent the wheel. Use a database...
You probably don't want to hear this, but what you just described is a
GUI client front-end with a database backend. The time it takes to
download, install, and learn to use, say, postgres will be similar to
the time you'd spend implementing what you've described above, but with
at least 10 to 100 times the payoff.
As for updating the client on the fly, one strategy would be to keep
the "dynamic" code in it's own module and have the clients reload()
that module when you upload a new version of it to the client machines.
Peace,
~Simon
HJ,
As someone already posted, the backend sounds very much like a
database, so why not use a database: transactions, specific views for
different users, limited access and so on = database!
Give PostgresSQL a try...
As far as presenting a different GUI to users, you can also do it based
on the database. In other words have a common login screen and if the
usertype from the database is returned as 'restricted' draw one
interface, if it is returned as 'full' draw the full interface. Even if
the restricted user will get the full interface up it won' t be
functional because the database would restrict writes to certain
tables/columns.
Remote update of code is also possible, but you'll have to implement
some kind of update server to which you can periodically send Python
files, those files will be installed on the machine by the update
server. You can try playing with Twisted to handle the networking. Or
just write a simple script to send stuff over scp/ssh -- that's what I
would do (start the ssh server, install public keys and then just scp
stuff over to the machines assuming they are online most of the
time...).
The problem will be if something goes wrong in the updated file or with
the update server then the whole system will be down (an off-by-one
error in the GUI db client code and all of the sudden all your users
will be writing bad data to the database... all at the same time). So
you will need to do frequent backups of the database, but you probably
know this already...
Hope this helps,
Nick Vatamaniuc
H J van Rooyen wrote:
Hi,
I want to write a small system that is transaction based.
I want to split the GUI front end data entry away from the file handling and
record keeping.
Now it seems almost trivially easy using the sockets module to communicate
between machines on the same LAN, so that I want to do the record keeping on one
machine.
I want to keep the "server" machine as simple as possible - just doing record
keeping on a stimulus response basis - I would prefer it to do one thing at a
time to completion because this style of operation, though limited in
performance, keeps a lot of hassles out of life - a transaction has either
completed, or it has not - recovery scenarios are relatively easy...
Up to this point, I don't have a problem - my toy system can create a dummy
transaction, and I can echo it from the "server" machine, with more than one
"user" machine running - so I think it is feasible to have several tens of "data
entry terminal" systems running, served by one not very strong machine.
Now what I would really like to do is to differentiate between the 'User"
machines, so that some can do a full range of transactions, and others a limited
range.
And I would like to make this flexible, so that it becomes easy to introduce new
transactions, without having to run around updating the code in all the user
machines, with the concomitant version number hassles.
And I would like to do the whole thing in python - so my question is this - is
it possible to do the equivalent of dynamic linking? - i.e. if I keep a list of
what a user is allowed to do - can I somehow send him just the bits he needs to
do the job, without having to change the static code on his machine? - it seems
to me that the eval() thingy could possibly do this for me, by sending it data
that makes it do import statements followed by calls to whatever... - will this
work, or is there a better way?
Or has all this been done already? - and no I don't want a web server and php
and browsers and Java and html or xml... - I want to write something that works
simply and reliably - its just short message accounting type data...
- Hendrik
H J van Rooyen a écrit :
Hi,
I want to write a small system that is transaction based.
I want to split the GUI front end data entry away from the file handling and
record keeping.
Now it seems almost trivially easy using the sockets module to communicate
between machines on the same LAN, so that I want to do the record keeping on one
machine.
I want to keep the "server" machine as simple as possible - just doing record
keeping on a stimulus response basis - I would prefer it to do one thing at a
time to completion because this style of operation, though limited in
performance, keeps a lot of hassles out of life - a transaction has either
completed, or it has not - recovery scenarios are relatively easy...
IOW, you want a SQL DBMS. May I recommand PostgreSQL ?
Up to this point, I don't have a problem - my toy system can create a dummy
transaction, and I can echo it from the "server" machine, with more than one
"user" machine running - so I think it is feasible to have several tens of "data
entry terminal" systems running, served by one not very strong machine.
Now what I would really like to do is to differentiate between the 'User"
machines, so that some can do a full range of transactions, and others a limited
range.
Any decent SQL DBMS is able to handle this. It's kind of builtin...
And I would like to make this flexible, so that it becomes easy to introduce new
transactions, without having to run around updating the code in all the user
machines, with the concomitant version number hassles.
Then you want a web front end.
And I would like to do the whole thing in python
You'll at least need bits of SQL (but SQLAlchemy may hide away most of
it) and HTML (but there are some python packages that knows how to build
HTML from declarative Python code).
- so my question is this - is
it possible to do the equivalent of dynamic linking? - i.e. if I keep a list of
what a user is allowed to do
In SQL : GRANT/REVOKE
- can I somehow send him just the bits he needs to
do the job, without having to change the static code on his machine?
HTTP/HTML.
- it seems
to me that the eval() thingy could possibly do this for me,
Err... I thought you wanted a reasonnably secure system, but I may have
misunderstood.
by sending it data
that makes it do import statements followed by calls to whatever... - will this
work, or is there a better way?
Or has all this been done already?
Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
Python frameworks to do this kind of things.
- and no I don't want a web server
If you don't want Apache, there are Python-based application servers.
CherryPy comes to mind.
and php
Why PHP ?
and browsers and Java
Why Java ?
and html or xml... - I want to write something that works
simply and reliably
We do write SQL-based web apps all day long, and I can tell you they are
certainly more simple and reliable than whatever eval()-based home-made
solution we could imagine !-)
"Simon Forman" <ro*********@yahoo.comwrote:
| H J van Rooyen wrote:
| Hi,
| >
| I want to write a small system that is transaction based.
| >
| I want to split the GUI front end data entry away from the file handling and
| record keeping.
| >
| Now it seems almost trivially easy using the sockets module to communicate
| between machines on the same LAN, so that I want to do the record keeping on
one
| machine.
| >
| I want to keep the "server" machine as simple as possible - just doing
record
| keeping on a stimulus response basis - I would prefer it to do one thing at
a
| time to completion because this style of operation, though limited in
| performance, keeps a lot of hassles out of life - a transaction has either
| completed, or it has not - recovery scenarios are relatively easy...
| >
| Up to this point, I don't have a problem - my toy system can create a dummy
| transaction, and I can echo it from the "server" machine, with more than one
| "user" machine running - so I think it is feasible to have several tens of
"data
| entry terminal" systems running, served by one not very strong machine.
| >
| Now what I would really like to do is to differentiate between the 'User"
| machines, so that some can do a full range of transactions, and others a
limited
| range.
| >
| And I would like to make this flexible, so that it becomes easy to introduce
new
| transactions, without having to run around updating the code in all the user
| machines, with the concomitant version number hassles.
| >
| And I would like to do the whole thing in python - so my question is this -
is
| it possible to do the equivalent of dynamic linking? - i.e. if I keep a list
of
| what a user is allowed to do - can I somehow send him just the bits he needs
to
| do the job, without having to change the static code on his machine? - it
seems
| to me that the eval() thingy could possibly do this for me, by sending it
data
| that makes it do import statements followed by calls to whatever... - will
this
| work, or is there a better way?
| >
| Or has all this been done already? - and no I don't want a web server and
php
| and browsers and Java and html or xml... - I want to write something that
works
| simply and reliably - its just short message accounting type data...
| >
| - Hendrik
|
| Don't reinvent the wheel. Use a database...
This believe it or not, is why I asked the question...
|
| You probably don't want to hear this, but what you just described is a
| GUI client front-end with a database backend. The time it takes to
| download, install, and learn to use, say, postgres will be similar to
| the time you'd spend implementing what you've described above, but with
| at least 10 to 100 times the payoff.
|
In a way you are right - having just read postgres vs mySQL wars in another
thread on this group - but on the other hand I am lazy and dont really want to
spend time writing ISAM or hashed random access file methods either - I did my
share of that in the late sixties and early seventies - and I have not yet done
any "research" into the capabilities of the various contenders in this arena...
*ducks*
| As for updating the client on the fly, one strategy would be to keep
| the "dynamic" code in it's own module and have the clients reload()
| that module when you upload a new version of it to the client machines.
|
| Peace,
| ~Simon
This will work - but it is unsatisfying to me - I would have kind of liked to
have the client machine not even have all the code available - having the "bits
that can change" in one module implies some kind of build for every client if
they are to be to different - what I would rather write is the kind of thing
that is implemented in banking transaction terminals - the terminal has only the
code for the transactions that it is authorised to have, and these different
modules along with their parameters can be downloaded into it and activated on
the fly, one at a time...
And how to do that efficiently in python is really the question that I would
like to have answered, if possible...
Thanks for the response, Simon.
- Hendrik
"Nick Vatamaniuc" <va******@gmail.comwrote:
| HJ,
|
| As someone already posted, the backend sounds very much like a
| database, so why not use a database: transactions, specific views for
| different users, limited access and so on = database!
| Give PostgresSQL a try...
*nods* - looks like I am going to have to do this....
| As far as presenting a different GUI to users, you can also do it based
| on the database. In other words have a common login screen and if the
| usertype from the database is returned as 'restricted' draw one
| interface, if it is returned as 'full' draw the full interface. Even if
| the restricted user will get the full interface up it won' t be
| functional because the database would restrict writes to certain
| tables/columns.
This is the guts of my question - if I dont know all the types now, how do I
make the front end so that I can easily update it as time reveals new
requirements - a la banking style terminals - see my reply to Simon please
| Remote update of code is also possible, but you'll have to implement
| some kind of update server to which you can periodically send Python
| files, those files will be installed on the machine by the update
| server. You can try playing with Twisted to handle the networking. Or
| just write a simple script to send stuff over scp/ssh -- that's what I
| would do (start the ssh server, install public keys and then just scp
| stuff over to the machines assuming they are online most of the
| time...).
This kind of addresses getting the stuff on to the server on the site for me - I
would like the front end to be more dynamic...
|
| The problem will be if something goes wrong in the updated file or with
| the update server then the whole system will be down (an off-by-one
| error in the GUI db client code and all of the sudden all your users
| will be writing bad data to the database... all at the same time). So
| you will need to do frequent backups of the database, but you probably
| know this already...
|
| Hope this helps,
| Nick Vatamaniuc
*grin* yes and it scares the s**t out of me - this is why I like the "do one
thing at a time to completion " approach - much easier to recover when things go
wrong...
- Hendrik
"Yu-Xi Lim" <yu**@ece.gatech.eduwrote:
| Simon Forman wrote:
| >Or has all this been done already? - and no I don't want a web server and
php
| >and browsers and Java and html or xml... - I want to write something that
works
| >simply and reliably - its just short message accounting type data...
| >>
| >- Hendrik
| >
| Don't reinvent the wheel. Use a database...
| >
| You probably don't want to hear this, but what you just described is a
| GUI client front-end with a database backend. The time it takes to
| download, install, and learn to use, say, postgres will be similar to
| the time you'd spend implementing what you've described above, but with
| at least 10 to 100 times the payoff.
| >
| >
| As for updating the client on the fly, one strategy would be to keep
| the "dynamic" code in it's own module and have the clients reload()
| that module when you upload a new version of it to the client machines.
|
| Yes, indeed, using a database with a GUI front end is the best way to
| get "something that works simply and reliably." Writing everything in
| Python isn't always the best solution. Python, however, is very good at
| interfacing with most existing applications and thus makes a great "glue."
|
| Using a proper DB system would give up transactions, multiple users, and
| access control, which you have said you required, and probably more
| features which you hadn't realized you needed but soon will when you
| scale up beyond a toy system (optimized queries, backups, load
| balancing, encrypted connections, etc).
Can I not use the ssl module for encrypting the connections? - Please also
understand that the system is aimed at small to medium companies, in house -
>From my perspective the only valid reason to use a database would be for the
ease of reporting - the files are not large - and the speed of a dict lookup in
python is hard to beat for normal transaction processing...
|
| As for updating the applications, why not just put them on the server
| for each "user"/client to retrieve? There are of course several ways of
| retrieving the centrally stored GUI program, and most likely you're
| thinking Windows file sharing (which would require restarting the client
NO! the last thing on my mind - want a dynamic process similar to banking
terminals - see my response to Simon please
| whenever updates are available). But don't rule out HTTP. Among the
I have been shying away from this - due to mental laziness - but obviously I
have to look at it - thanks
| benefits of web apps are the ability to update the application on the
| fly and deploy it quickly. And no, web apps don't necessarily mean PHP,
| Java or XML. You can easily use plain HTML and Python to create the GUI
| and interface it with the database. AJAX may be th buzzword now, but it
| isn't necessary for everything.
Thanks will *have* to look at html
"Bruno Desthuilliers" <bd*****************@free.quelquepart.frwrote:
|H J van Rooyen a écrit :
|Hi,
|>
|I want to write a small system that is transaction based.
|>
|I want to split the GUI front end data entry away from the file handling and
|record keeping.
|>
|Now it seems almost trivially easy using the sockets module to communicate
|between machines on the same LAN, so that I want to do the record keeping on
one
|machine.
|>
|I want to keep the "server" machine as simple as possible - just doing record
|keeping on a stimulus response basis - I would prefer it to do one thing at a
|time to completion because this style of operation, though limited in
|performance, keeps a lot of hassles out of life - a transaction has either
|completed, or it has not - recovery scenarios are relatively easy...
|
|IOW, you want a SQL DBMS. May I recommand PostgreSQL ?
|
Looks like the way to go - after the argy bargy here in another thread seems
mySQL has no supporters left...
|Up to this point, I don't have a problem - my toy system can create a dummy
|transaction, and I can echo it from the "server" machine, with more than one
|"user" machine running - so I think it is feasible to have several tens of
"data
|entry terminal" systems running, served by one not very strong machine.
|>
|Now what I would really like to do is to differentiate between the 'User"
|machines, so that some can do a full range of transactions, and others a
limited
|range.
|
|Any decent SQL DBMS is able to handle this. It's kind of builtin...
Yes - if you do the whole job on the server - the architecture I have mind is
more like a banking terminal scenario - please see my reply to Simon
|
|And I would like to make this flexible, so that it becomes easy to introduce
new
|transactions, without having to run around updating the code in all the user
|machines, with the concomitant version number hassles.
|
|Then you want a web front end.
This seems to me to assume that the server does all the work
|
|And I would like to do the whole thing in python
|
|You'll at least need bits of SQL (but SQLAlchemy may hide away most of
|it) and HTML (but there are some python packages that knows how to build
|HTML from declarative Python code).
|
that is good news - which packages?
|- so my question is this - is
|it possible to do the equivalent of dynamic linking? - i.e. if I keep a list
of
|what a user is allowed to do
|
|In SQL : GRANT/REVOKE
again - centric thinking - I really would like to change the bits on the client,
as I explained to Simon
|
|- can I somehow send him just the bits he needs to
|do the job, without having to change the static code on his machine?
|
|HTTP/HTML.
|
everybody says this - I am being dragged, kicking and screaming...
|- it seems
|to me that the eval() thingy could possibly do this for me,
|
|Err... I thought you wanted a reasonnably secure system, but I may have
|misunderstood.
|
this is the guts of what I want - if eval is NFG then how do I implement such a
kind of "dynamic linking" of modules on the client?
|by sending it data
|that makes it do import statements followed by calls to whatever... - will
this
|work, or is there a better way?
|>
|Or has all this been done already?
|
|Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
|Python frameworks to do this kind of things.
|
I kind of wanted to avoid the web based stuff - the application data is so small
and trivial, in a sense.
|- and no I don't want a web server
|
|If you don't want Apache, there are Python-based application servers.
|CherryPy comes to mind.
|
|and php
|
|Why PHP ?
|
seems popular
|and browsers and Java
|
|Why Java ?
|
it addresses what I want - to dynamically and securely download bits of code and
execute them on the remote machine...
|and html or xml... - I want to write something that works
|simply and reliably
|
|We do write SQL-based web apps all day long, and I can tell you they are
|certainly more simple and reliable than whatever eval()-based home-made
|solution we could imagine !-)
Aah! but I would like you to stretch that imagination - to tell me how to do
some of what Java was designed to do, but better and easier, because this is
python we are talking about...
I saw something in another thread here - they were talking about weave - can I
use that if eval is nfg?
If my original post was unclear I am sorry - the point I want answered, if
possible, is how to make the client code effectively updateable on the fly -
because the answer to this will influence the whole design of the rest of the
system...
- Hendrik
H J van Rooyen wrote:
"Bruno Desthuilliers" <bd*****************@free.quelquepart.frwrote:
|H J van Rooyen a écrit :
|Hi,
|>
|I want to write a small system that is transaction based.
|>
|I want to split the GUI front end data entry away from the file handling and
|record keeping.
|>
|Now it seems almost trivially easy using the sockets module to communicate
|between machines on the same LAN, so that I want to do the record keeping on
one
|machine.
|>
|I want to keep the "server" machine as simple as possible - just doing record
|keeping on a stimulus response basis - I would prefer it to do one thing at a
|time to completion because this style of operation, though limited in
|performance, keeps a lot of hassles out of life - a transaction has either
|completed, or it has not - recovery scenarios are relatively easy...
|
|IOW, you want a SQL DBMS. May I recommand PostgreSQL ?
|
Looks like the way to go - after the argy bargy here in another thread seems
mySQL has no supporters left...
Indeed, my choices would now be SQLite for simple things and PostgreSQL
for more serious stuff...
|Up to this point, I don't have a problem - my toy system can create a dummy
|transaction, and I can echo it from the "server" machine, with more than one
|"user" machine running - so I think it is feasible to have several tens of
"data
|entry terminal" systems running, served by one not very strong machine.
|>
|Now what I would really like to do is to differentiate between the 'User"
|machines, so that some can do a full range of transactions, and others a
limited
|range.
|
|Any decent SQL DBMS is able to handle this. It's kind of builtin...
Yes - if you do the whole job on the server -
the architecture I have mind is
more like a banking terminal scenario - please see my reply to Simon
(...)
Done. And I still think that a CherryPy/PostgreSQL based solution is the
way to go.
|
|And I would like to make this flexible, so that it becomes easy to introduce
new
|transactions, without having to run around updating the code in all the user
|machines, with the concomitant version number hassles.
|
|Then you want a web front end.
This seems to me to assume that the server does all the work
Not necessarily. Of course most computations are done on the server, but
what you describe here really feels like AJAX IMHO. Have a look at some
Turbogears AJAX addons like Catwalk and ModelDesigner...
|
|And I would like to do the whole thing in python
|
|You'll at least need bits of SQL (but SQLAlchemy may hide away most of
|it) and HTML (but there are some python packages that knows how to build
|HTML from declarative Python code).
|
that is good news - which packages?
http://divmod.org/trac/wiki/DivmodNevow http://divmod.org/trac/wiki/DivmodNevow/Athena http://starship.python.net/crew/frie...html/main.html http://aspn.activestate.com/ASPN/Coo.../Recipe/366000 http://dustman.net/andy/python/HyperText/ http://pyhtmloo.sourceforge.net/
|- so my question is this - is
|it possible to do the equivalent of dynamic linking? - i.e. if I keep a list
of
|what a user is allowed to do
|
|In SQL : GRANT/REVOKE
again - centric thinking - I really would like to change the bits on the client,
as I explained to Simon
|
|- can I somehow send him just the bits he needs to
|do the job, without having to change the static code on his machine?
|
|HTTP/HTML.
|
everybody says this
Well, there must be a reason...
- I am being dragged, kicking and screaming...
|- it seems
|to me that the eval() thingy could possibly do this for me,
|
|Err... I thought you wanted a reasonnably secure system, but I may have
|misunderstood.
|
this is the guts of what I want - if eval is NFG then how do I implement such a
kind of "dynamic linking" of modules on the client?
You may want to look at stuff like Pyro (Python remote objects).
|by sending it data
|that makes it do import statements followed by calls to whatever... - will
this
|work, or is there a better way?
|>
|Or has all this been done already?
|
|Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
|Python frameworks to do this kind of things.
|
I kind of wanted to avoid the web based stuff - the application data is so small
and trivial, in a sense.
So why even bother writing your own transaction manager, dynamic client
and protocol when the whole thing already exists - PostgreSQL,
Javascript-enabled browser and HTTP... FWIW, deploying a CherryPy
application is really trivial. I have not tested Divmod/nevow yet, but I
think you should have a look there too.
|- and no I don't want a web server
|
|If you don't want Apache, there are Python-based application servers.
|CherryPy comes to mind.
|
|and php
|
|Why PHP ?
|
seems popular
Yes, but why PHP ? Python is quite good for web apps.
|and browsers and Java
|
|Why Java ?
|
it addresses what I want - to dynamically and securely download bits of code and
execute them on the remote machine...
If you really want security, you have to keep the critical parts on the
server.
|and html or xml... - I want to write something that works
|simply and reliably
|
|We do write SQL-based web apps all day long, and I can tell you they are
|certainly more simple and reliable than whatever eval()-based home-made
|solution we could imagine !-)
Aah! but I would like you to stretch that imagination - to tell me how to do
some of what Java was designed to do,
Initially, Java - it was named Oak by the time - was designed for
embedded programming. It happened to be a failure. Then it was renamed
to Java and "redesigned" (hum) for rich web client (applets). It still
failed there. It also failed for traditional cross-platform GUI
programming (too heavy and too autistic), and finally happened to make
it on the web server side, but even there it's a really heavy-weight
solution with no obvious practical advantage wrt/ more agile solutions
(PHP, Python, Ruby, Perl etc) IMHO.
but better and easier, because this is
python we are talking about...
indeed !-)
I saw something in another thread here - they were talking about weave
???
- can I
use that if eval is nfg?
Can't tell...
If my original post was unclear I am sorry - the point I want answered, if
possible, is how to make the client code effectively updateable on the fly -
because the answer to this will influence the whole design of the rest of the
system...
This is something I have been thinking about... IMHO what you want is
not to "update client code on the fly", but to make the client mostly a
kind of interpreter for what the server sends in. That is, the client
code itself doesn't contain any application logic, it gets it from the
server and execute it. This can certainly be done with Pyro.
Now while this may be an interesting project, I'm not really sure it's
worth the effort when we already have HTTP, HTML and AJAX...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
HJ,
As far as GUI language/library goes:
Some people suggested HTML, but I think HTML is a very awkward way to
create a good looking dynamic GUI that is _both_ easy to use and fast
and easy to design (which is what you would want probably). Just to
have a nice user editable table for example, you would have to jump
through hoops (using Javascript, DOM, CSS etc), while you could do it
much easier with PyGTK and wxPython, especially if you use a gui
designer like Glade or wxGlade. Even Tkinter beats HTML as far as
building GUIs in Python goes. I believe this might change in the future
with the adaption of SVG but that will take a while... That said, if
your interface can "get by" with just buttons, text boxes, and text
areas HTML will be the best choice.
As far as "updating-on-the-fly" goes:
For the client to get the code on the fly you will have to implement
some sort of a downloader in the first place that when the user logs
in, it downloads the GUI code from the server and runs it. So if you
update the code the day before the next day they will get a different
interface, or if a new user/machine type is created you just have the
new code ready on the server and it will automatically be downloaded
and run, is that right?
Here is then how I see your use case:
1) You would define your business rules in your database, you will have
usernames, user types, access rights, data tables, columns types,
relations, views, etc...
2) Then each user type will have a specific interface GUI code kept on
the server (perhaps as a zipped binary GUI.zip in a database column
called ClientSpecificGUI).
3) The client starts your Application.py which is the same across all
clients. They will enter their username/password. The Application.py
then sends those to the server to log into the DB.
4) After successful login, the Application.py performs a SELECT query
to download the zipped GUI.py file.
5) GUI.py is unzipped and executed to start the GUI. The Application.py
code will pass the DB connection object to the GUI.py, so the GUI can
continue to talk with the database. GUI.py runs and does its magic, in
the meantime Application.py waits for GUI.py to finished and then both
exit.
Is that what you had in mind?
NOTE: This means that the client will need to have all the required
libraries at just the right versions. Imagine that your user decides to
upgrade to Python 3000 because it sounds cooler than plain old Python
2.4 ;) , but then they won't realize that it will break your code and
they might not be able to run your application anymore. So you would
have to know at least roughly how much control over the whole client
machine you will have. Will they all be regular desktops that users
will use day to day and then once in a while launch your application
then close it, or will these all be dedicated terminals like an ATM?
The two are very different. You can assume complete control of all the
OS environment in a dedicated terminal but not in the case of a user
desktop.
Hope this helps,
Nick Vatamaniuc
H J van Rooyen wrote:
"Bruno Desthuilliers" <bd*****************@free.quelquepart.frwrote:
|H J van Rooyen a écrit :
|Hi,
|>
|I want to write a small system that is transaction based.
|>
|I want to split the GUI front end data entry away from the file handling and
|record keeping.
|>
|Now it seems almost trivially easy using the sockets module to communicate
|between machines on the same LAN, so that I want to do the record keeping on
one
|machine.
|>
|I want to keep the "server" machine as simple as possible - just doingrecord
|keeping on a stimulus response basis - I would prefer it to do one thing at a
|time to completion because this style of operation, though limited in
|performance, keeps a lot of hassles out of life - a transaction has either
|completed, or it has not - recovery scenarios are relatively easy...
|
|IOW, you want a SQL DBMS. May I recommand PostgreSQL ?
|
Looks like the way to go - after the argy bargy here in another thread seems
mySQL has no supporters left...
|Up to this point, I don't have a problem - my toy system can create a dummy
|transaction, and I can echo it from the "server" machine, with more than one
|"user" machine running - so I think it is feasible to have several tens of
"data
|entry terminal" systems running, served by one not very strong machine.
|>
|Now what I would really like to do is to differentiate between the 'User"
|machines, so that some can do a full range of transactions, and othersa
limited
|range.
|
|Any decent SQL DBMS is able to handle this. It's kind of builtin...
Yes - if you do the whole job on the server - the architecture I have mind is
more like a banking terminal scenario - please see my reply to Simon
|
|And I would like to make this flexible, so that it becomes easy to introduce
new
|transactions, without having to run around updating the code in all the user
|machines, with the concomitant version number hassles.
|
|Then you want a web front end.
This seems to me to assume that the server does all the work
|
|And I would like to do the whole thing in python
|
|You'll at least need bits of SQL (but SQLAlchemy may hide away most of
|it) and HTML (but there are some python packages that knows how to build
|HTML from declarative Python code).
|
that is good news - which packages?
|- so my question is this - is
|it possible to do the equivalent of dynamic linking? - i.e. if I keep a list
of
|what a user is allowed to do
|
|In SQL : GRANT/REVOKE
again - centric thinking - I really would like to change the bits on the client,
as I explained to Simon
|
|- can I somehow send him just the bits he needs to
|do the job, without having to change the static code on his machine?
|
|HTTP/HTML.
|
everybody says this - I am being dragged, kicking and screaming...
|- it seems
|to me that the eval() thingy could possibly do this for me,
|
|Err... I thought you wanted a reasonnably secure system, but I may have
|misunderstood.
|
this is the guts of what I want - if eval is NFG then how do I implement such a
kind of "dynamic linking" of modules on the client?
|by sending it data
|that makes it do import statements followed by calls to whatever... - will
this
|work, or is there a better way?
|>
|Or has all this been done already?
|
|Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
|Python frameworks to do this kind of things.
|
I kind of wanted to avoid the web based stuff - the application data is so small
and trivial, in a sense.
|- and no I don't want a web server
|
|If you don't want Apache, there are Python-based application servers.
|CherryPy comes to mind.
|
|and php
|
|Why PHP ?
|
seems popular
|and browsers and Java
|
|Why Java ?
|
it addresses what I want - to dynamically and securely download bits of code and
execute them on the remote machine...
|and html or xml... - I want to write something that works
|simply and reliably
|
|We do write SQL-based web apps all day long, and I can tell you they are
|certainly more simple and reliable than whatever eval()-based home-made
|solution we could imagine !-)
Aah! but I would like you to stretch that imagination - to tell me how todo
some of what Java was designed to do, but better and easier, because thisis
python we are talking about...
I saw something in another thread here - they were talking about weave - can I
use that if eval is nfg?
If my original post was unclear I am sorry - the point I want answered, if
possible, is how to make the client code effectively updateable on the fly -
because the answer to this will influence the whole design of the rest ofthe
system...
- Hendrik
"Yu-Xi Lim" <yu**@ece.gatech.eduwrote:
| H J van Rooyen wrote:
| |
| |And I would like to make this flexible, so that it becomes easy to
introduce
| new
| |transactions, without having to run around updating the code in all the
user
| |machines, with the concomitant version number hassles.
| |
| |Then you want a web front end.
| >
| This seems to me to assume that the server does all the work
|
| Depends on what you mean by "all the work."
What I mean by this is that the server does stuff that I think belongs on the
client -
like getting involved in the nitty gritty of what the client should display -
I want the client to be smart enough to do the assembly of the elements of a
transaction
by itself, going back to the server for data only when its needed - remember
this is essentially an
accounting type data entry package - most of the stuff is typed in as text, when
processing documents from the outside, while the locally produced docs like
invoices would be generated by the system, to a large extent by making choices
amongst alternatives known to the server -
so I see the client interacting with the server quite a lot, eventually to be
able do things like auto completion of things like stock codes and descriptions,
customer details, etc. - but I don't want every keystroke flying over the LAN
and
being handled by the server...
In a sense I want to build an architecture that assembles a record from a mix of
user input and user choices out of alternatives (which unfortunately would have
to be kept on the server) and that then ships this to the server to process, and
to keep track of - such a record would be either accepted or rejected by the
server, and it would be the responsibility of the client to ensure that the
transaction is completed - like in a banking system, I envisage ways for the
client to 'poll' the server to get the state of the last transaction, to make
this possible.
|
| Operations such as filtering results are best done at the server unless
| your have extremely high-bandwidth connections so that each client can
| examine the entire data set and perform the operations themselves (with
| minimal time of course, since your other clients may be waiting on that
| transaction).
|
| Transactions, too, will have to be supported by the server, or else you
| may be left with partial transactions if a client gets disconnected
| somehow as well as the need to implement complex locking systems yourself.
|
| As for the other conditions, such as privilege and access control, I
| think you'd find that centrally managed is the most manageable in the
| long run.
|
| You won't regret making it server-centric. The experts have already done
| the optimisations and have ways of getting around the possible
| bottleneck of having a single server perform most of the operations.
|
| |Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
| |Python frameworks to do this kind of things.
| |
| >
| I kind of wanted to avoid the web based stuff - the application data is so
small
| and trivial, in a sense.
|
| You'd find that the python frameworks, especially those modeled after
| Ruby on Rails, make creating trivial applications, such as the front-end
| you describe, trivial. Go take a look at Django and TurboGears and the
| others. Some have videos demonstrating stuff like how to make a
| blog/wiki/other-database-app in 5 minutes. Most come with a built-in
| webserver, though generally those aren't tested or guaranteed for
| high-load environments.
I get the feeling I am drinking out of a fire hose... I will look.
|
| All you need to add is a DB. Most recommend postgresql, and I'd
| recommend that too, to provide the features you are looking for. Avoid
| the lightweight DB systems such as Gadfly, sqlite, MS Jet/Access since
| those don't have the necessary features.
postgres seems the way to go - if there is anything that is coming across clear,
it is this.
Have you any ideas about the "code change on the fly" requirement? or is it a
complete no no?
thanks - Hendrik
"Bruno Desthuilliers" <on***@xiludom.growrote:
|H J van Rooyen wrote:
|"Bruno Desthuilliers" <bd*****************@free.quelquepart.frwrote:
|>
|>
8<-----------------------------------------------
||You'll at least need bits of SQL (but SQLAlchemy may hide away most of
||it) and HTML (but there are some python packages that knows how to build
||HTML from declarative Python code).
||
|>
|that is good news - which packages? http://divmod.org/trac/wiki/DivmodNevow http://divmod.org/trac/wiki/DivmodNevow/Athena http://starship.python.net/crew/frie...html/main.html http://aspn.activestate.com/ASPN/Coo.../Recipe/366000 http://dustman.net/andy/python/HyperText/ http://pyhtmloo.sourceforge.net/
Thanks for the references I will try to check them all out
8<--------------------------------------------------
|If my original post was unclear I am sorry - the point I want answered, if
|possible, is how to make the client code effectively updateable on the fly -
|because the answer to this will influence the whole design of the rest of the
|system...
|
|This is something I have been thinking about... IMHO what you want is
|not to "update client code on the fly", but to make the client mostly a
|kind of interpreter for what the server sends in. That is, the client
|code itself doesn't contain any application logic, it gets it from the
|server and execute it. This can certainly be done with Pyro.
|
|Now while this may be an interesting project, I'm not really sure it's
|worth the effort when we already have HTTP, HTML and AJAX...
You may be right and it might not be worth the trouble - but what you mention
above is closer to the sort of thing I have in mind - it is essentially using
python to create a script language, and moving scripts around - but hey - python
is already a script language...
so if Pyro is for 'moving the scripts around' - Then that is what I must look at
very hard...
- thanks - Hendrik
H J van Rooyen wrote:
"Bruno Desthuilliers" <on***@xiludom.growrote:
(snip)
|If my original post was unclear I am sorry - the point I want answered, if
|possible, is how to make the client code effectively updateable on the fly -
|because the answer to this will influence the whole design of the rest of the
|system...
|
|This is something I have been thinking about... IMHO what you want is
|not to "update client code on the fly", but to make the client mostly a
|kind of interpreter for what the server sends in. That is, the client
|code itself doesn't contain any application logic, it gets it from the
|server and execute it. This can certainly be done with Pyro.
|
|Now while this may be an interesting project, I'm not really sure it's
|worth the effort when we already have HTTP, HTML and AJAX...
You may be right and it might not be worth the trouble - but what you mention
above is closer to the sort of thing I have in mind - it is essentially using
python to create a script language, and moving scripts around - but hey - python
is already a script language...
Yes, but it's not (alas) supported by browsers...
so if Pyro is for 'moving the scripts around' - Then that is what I must look at
very hard...
It's not for "moving the scripts around", it's for remote objects - kind
of like Java's RMI, but, well, much more pythonic !-). Now the point is
that Python being very powerful when it comes to dynamism and
introspection, it should be possible to have a common client that
basically just knows how to connect to the application server (using
pyro). Once connected, the client asks the server for a set of objects
(forms, menus etc) and the corresponding data. These objects then use
the same mechanism to interact with the server. It's basically similar
to the interaction between a browser and a web app - in that the client
is potentially able to run any application sent by the server -, but
with much more specialized client and app server and another protocol -
and no other language than Python.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
"Nick Vatamaniuc" <va******@gmail.comwrote:
|HJ,
|
|As far as GUI language/library goes:
|
|Some people suggested HTML, but I think HTML is a very awkward way to
|create a good looking dynamic GUI that is _both_ easy to use and fast
|and easy to design (which is what you would want probably). Just to
|have a nice user editable table for example, you would have to jump
|through hoops (using Javascript, DOM, CSS etc), while you could do it
|much easier with PyGTK and wxPython, especially if you use a gui
|designer like Glade or wxGlade. Even Tkinter beats HTML as far as
|building GUIs in Python goes. I believe this might change in the future
|with the adaption of SVG but that will take a while... That said, if
|your interface can "get by" with just buttons, text boxes, and text
|areas HTML will be the best choice.
|
At the moment my toy system just uses Tkinter- Buttons, Labels, Entry boxes and
Listboxes (which I populate from a dict) - and it has logic in it to do only one
dummy transaction, which I just ship to the server machine where nothing
happens - it is just echoed back to the client which prints it on stdout - If I
stay with this it will be a most uninteresting GUI - but that is not the point
at issue now...
|
|As far as "updating-on-the-fly" goes:
|
|For the client to get the code on the fly you will have to implement
|some sort of a downloader in the first place that when the user logs
|in, it downloads the GUI code from the server and runs it. So if you
|update the code the day before the next day they will get a different
|interface, or if a new user/machine type is created you just have the
|new code ready on the server and it will automatically be downloaded
|and run, is that right?
|
This is broadly what I had in mind, yes - but sort of down to a transaction
level - this user does invoicing, this one enters cheques, this one does credit
notes, and their supervisor can do all three, and in a different department its
different because the jobs are different, but the invoicing GUI module is the
same for wherever its used...
|Here is then how I see your use case:
|1) You would define your business rules in your database, you will have
|usernames, user types, access rights, data tables, columns types,
|relations, views, etc...
Yes no matter how you do it, you need to keep a per user or per machine set of
what can be done. - in banking terms - a sort of Terminal Management System...
My thinking is simpler than this, because you are already thinking in "data base
speak" - now dont get me wrong - I realise that I will have to use a database -
but for me to start thinking in terms of views and stuff is kind of premature
when I dont even have a clear picture in my head of the kind of data the said
management system should keep, as I am not sure of what can, and cannot be done.
|2) Then each user type will have a specific interface GUI code kept on
|the server (perhaps as a zipped binary GUI.zip in a database column
|called ClientSpecificGUI).
I would like to split this down further - see above - so for each user there is
a sort of *pointer* to each of the kinds of transactions she can do, and these
are shipped separately and *linked* at the client side...
|3) The client starts your Application.py which is the same across all
|clients. They will enter their username/password. The Application.py
|then sends those to the server to log into the DB.
*nods*
|4) After successful login, the Application.py performs a SELECT query
|to download the zipped GUI.py file.
|5) GUI.py is unzipped and executed to start the GUI. The Application.py
|code will pass the DB connection object to the GUI.py, so the GUI can
|continue to talk with the database. GUI.py runs and does its magic, in
|the meantime Application.py waits for GUI.py to finished and then both
|exit.
|Is that what you had in mind?
Very close - I have not even thought this far - I did not think of building a
GUI for each user, I thought of building it for each transaction - kind of a
series of things like my toy - and then I got stuck on the "linking the separate
transaction guis into an app on the fly" bit, which is why I started the
thread - I really want to know if it is possible to do this sort of thing in
Python, and so far Bruno has come up with Pyro, while everybody else (including
Bruno) is beating me over the head with HTML
Now part of the reason I would like to go the transaction type route instead of
the "per user" route is robustness and maintainability, and the ability it
would give me to introduce new transaction types easily - as I see it if say an
invoice's GUI code is stable I would never have to touch it again even if I
combine it with anything else, as it would have been designed from the start to
combine with others of it's own ilk, under a kind of communications controller
that is standard...
|NOTE: This means that the client will need to have all the required
|libraries at just the right versions. Imagine that your user decides to
|upgrade to Python 3000 because it sounds cooler than plain old Python
|2.4 ;) , but then they won't realize that it will break your code and
|they might not be able to run your application anymore. So you would
|have to know at least roughly how much control over the whole client
|machine you will have. Will they all be regular desktops that users
|will use day to day and then once in a while launch your application
|then close it, or will these all be dedicated terminals like an ATM?
|The two are very different. You can assume complete control of all the
|OS environment in a dedicated terminal but not in the case of a user
|desktop.
True - have not even considered this - this would, I imagine, vary from site to
site, and depend more on local IT policy - this is probably the strongest
argument to date against going this route, as these machines would not be as
tightly controlled as an ATM...
but then - If I want to use Python in the client at all, I would have to somehow
come to terms with this - its more the normal sort of version control that would
have to be done - after all if a user's machine is an XT running DOS - then its
going to have to be upgraded before it can be used as a terminal...
So this is more an argument against the use of Python on the client and I don't
like that...
|Hope this helps,
|Nick Vatamaniuc
8<----------------------------------------------------
Yes it does, Thanks. I feel we are getting closer to the point where I can
decide if what I am thinking of is practical or a pipe dream - it sounded so
simple - make a series of guis for a series of transactions, ship them to the
client, where there is a simple top level thingy that swallows them and ties
them all together and handles the comms to the server... I mean the language is
called Python... :-)
- Hendrik
H J van Rooyen wrote:
(snip)
I would like to split this down further - see above - so for each user there is
a sort of *pointer* to each of the kinds of transactions she can do, and these
are shipped separately and *linked* at the client side...
(snip)
>
Now part of the reason I would like to go the transaction type route instead of
the "per user" route is robustness and maintainability,
Nothing prevents you from managing rights with a user -allowed
transactions mapping...
BTW, note that "transaction" has a very definite meaning in DBMS jargon,
which is somewhat different from what you use this term for. This may
become a source of confusion...
>
|NOTE: This means that the client will need to have all the required
|libraries at just the right versions. Imagine that your user decides to
|upgrade to Python 3000 because it sounds cooler than plain old Python
|2.4 ;) , but then they won't realize that it will break your code and
|they might not be able to run your application anymore. So you would
|have to know at least roughly how much control over the whole client
|machine you will have. Will they all be regular desktops that users
|will use day to day and then once in a while launch your application
|then close it, or will these all be dedicated terminals like an ATM?
|The two are very different. You can assume complete control of all the
|OS environment in a dedicated terminal but not in the case of a user
|desktop.
True - have not even considered this - this would, I imagine, vary from site to
site, and depend more on local IT policy - this is probably the strongest
argument to date against going this route, as these machines would not be as
tightly controlled as an ATM...
but then - If I want to use Python in the client at all, I would have to somehow
come to terms with this - its more the normal sort of version control that would
have to be done - after all if a user's machine is an XT running DOS - then its
going to have to be upgraded before it can be used as a terminal...
So this is more an argument against the use of Python on the client and I don't
like that...
Well, this is an argument against any kind of fat client whatever the
language, and one of the key reason for the growing demand for web
applications - reducing deployment problems to the minimum...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
H J van Rooyen wrote:
[...]
This is broadly what I had in mind, yes - but sort of down to
a transaction
level - this user does invoicing, this one enters cheques,
this one does credit
notes, and their supervisor can do all three, and in a
different department its
different because the jobs are different, but the invoicing
GUI module is the
same for wherever its used...
Pretty much any business has to deal with those things. You are
right about the need for transactions and authorization, and
that you don't want to have to manually update all the clients
whenever your modify the applications. Everyone has those
problems, and consequently there's a large body of experience
and conventional best practice. The highly redundant advice
you've been getting is recommending that you to do those things
that way most successful modern systems do them.
No question what you describe calls for a DBMS. Further, this
sounds like a job for a "three tier" architecture, what Dennis
L. Bieber explained as [db-server] <-[app-server] <-[client].
In the old days a three-tier system called for a large
data-processing staff; today one guy can set up a simple one in
an afternoon.
In a three-tier system, either the database, the server
application can enforce authorization policy. In order for the
database to enforce authorization, the application creates one
database connection for each client user, and logs in as the
user. That works well for most accounting-type systems, where
all the users are known in advance. In systems such as web
shopping carts, the application typically has its own user ID,
and creates all database connections as itself. The app, not the
database, is then responsible for keeping users from reading and
altering each other's data.
Trying to enforce authorization at the client is generally a
mistake. The user has too much control over his local machine.
He is not limited to running just the code you provide.
Don't get too hung up on choice of DBMS, but stick with portable
standard SQL. I bet you'll find your potential customers want it
to run against the database they already have. The particular
tables your system needs will become part of their larger
schema.
--
--Bryan
Hendrik,
---snip---
Now part of the reason I would like to go the transaction type route
instead of the "per user" route is robustness and maintainability, and
the ability it would give me to introduce new transaction types easily
- as I see it if say an invoice's GUI code is stable I would never have
to touch it again even if I combine it with anything else, as it would
have been designed from the start to combine with others of it's own
ilk, under a kind of communications controller that is standard...
---snip---
It could be possible to separate your GUI into various modules. So you
could have for example:
BillingGUI.py
InvoicingGUI.py
QueryGUI.py
and so on.
Then your central control application (Application.py) would get the
set of module names allowed for that client to run during login. So
after the user logs in, the next thing would be to "SELECT ..." all
the GUI modules from the database to be downloaded. The client won't
know which ones are there, only the server.
So the set of possible GUIs will be sent over to the client (preferable
in a zipped form). They are unzipped in some temporary folder (here you
can do some caching to only download if the set changed).
Then it would be imporant for you to create some nameing rule or some
interface so the Application.py will know what GUI modules look like.
For example you could have the pattern [Capitalizedname]GUI.py be a
GUI module. The Application.py will then inspect the folder, and create
a button and label for each possible GUI module and present that to the
user. When the user clicks on the Button, the Application.py window
gets hidden and the [Modulename]GUI.py module is executed. When done,
the Application.py will be shown again and the user can either continue
with another module they are allowed to use or quit.
How does that sound?
Also, you mentioned that you won't have more than a couple of simple
fill-in forms and with drop-down options and so on. HTML then might be
the way to go. If that's all there will ever be just try to do HTML
(see Cherrypy, Turbogears and others....). If your GUI will be more
complicated in the future, just stick with what you know (Tkinter for
example).
Good luck,
Nick Vatamaniuc
H J van Rooyen wrote:
"Nick Vatamaniuc" <va******@gmail.comwrote:
|HJ,
|
|As far as GUI language/library goes:
|
|Some people suggested HTML, but I think HTML is a very awkward way to
|create a good looking dynamic GUI that is _both_ easy to use and fast
|and easy to design (which is what you would want probably). Just to
|have a nice user editable table for example, you would have to jump
|through hoops (using Javascript, DOM, CSS etc), while you could do it
|much easier with PyGTK and wxPython, especially if you use a gui
|designer like Glade or wxGlade. Even Tkinter beats HTML as far as
|building GUIs in Python goes. I believe this might change in the future
|with the adaption of SVG but that will take a while... That said, if
|your interface can "get by" with just buttons, text boxes, and text
|areas HTML will be the best choice.
|
At the moment my toy system just uses Tkinter- Buttons, Labels, Entry boxes and
Listboxes (which I populate from a dict) - and it has logic in it to do only one
dummy transaction, which I just ship to the server machine where nothing
happens - it is just echoed back to the client which prints it on stdout - If I
stay with this it will be a most uninteresting GUI - but that is not the point
at issue now...
|
|As far as "updating-on-the-fly" goes:
|
|For the client to get the code on the fly you will have to implement
|some sort of a downloader in the first place that when the user logs
|in, it downloads the GUI code from the server and runs it. So if you
|update the code the day before the next day they will get a different
|interface, or if a new user/machine type is created you just have the
|new code ready on the server and it will automatically be downloaded
|and run, is that right?
|
This is broadly what I had in mind, yes - but sort of down to a transaction
level - this user does invoicing, this one enters cheques, this one does credit
notes, and their supervisor can do all three, and in a different department its
different because the jobs are different, but the invoicing GUI module is the
same for wherever its used...
|Here is then how I see your use case:
|1) You would define your business rules in your database, you will have
|usernames, user types, access rights, data tables, columns types,
|relations, views, etc...
Yes no matter how you do it, you need to keep a per user or per machine set of
what can be done. - in banking terms - a sort of Terminal Management System...
My thinking is simpler than this, because you are already thinking in "data base
speak" - now dont get me wrong - I realise that I will have to use a database -
but for me to start thinking in terms of views and stuff is kind of premature
when I dont even have a clear picture in my head of the kind of data the said
management system should keep, as I am not sure of what can, and cannot be done.
|2) Then each user type will have a specific interface GUI code kept on
|the server (perhaps as a zipped binary GUI.zip in a database column
|called ClientSpecificGUI).
I would like to split this down further - see above - so for each user there is
a sort of *pointer* to each of the kinds of transactions she can do, and these
are shipped separately and *linked* at the client side...
|3) The client starts your Application.py which is the same across all
|clients. They will enter their username/password. The Application.py
|then sends those to the server to log into the DB.
*nods*
|4) After successful login, the Application.py performs a SELECT query
|to download the zipped GUI.py file.
|5) GUI.py is unzipped and executed to start the GUI. The Application.py
|code will pass the DB connection object to the GUI.py, so the GUI can
|continue to talk with the database. GUI.py runs and does its magic, in
|the meantime Application.py waits for GUI.py to finished and then both
|exit.
|Is that what you had in mind?
Very close - I have not even thought this far - I did not think of building a
GUI for each user, I thought of building it for each transaction - kind of a
series of things like my toy - and then I got stuck on the "linking the separate
transaction guis into an app on the fly" bit, which is why I started the
thread - I really want to know if it is possible to do this sort of thing in
Python, and so far Bruno has come up with Pyro, while everybody else (including
Bruno) is beating me over the head with HTML
Now part of the reason I would like to go the transaction type route instead of
the "per user" route is robustness and maintainability, and the ability it
would give me to introduce new transaction types easily - as I see it if say an
invoice's GUI code is stable I would never have to touch it again even if I
combine it with anything else, as it would have been designed from the start to
combine with others of it's own ilk, under a kind of communications controller
that is standard...
|NOTE: This means that the client will need to have all the required
|libraries at just the right versions. Imagine that your user decides to
|upgrade to Python 3000 because it sounds cooler than plain old Python
|2.4 ;) , but then they won't realize that it will break your code and
|they might not be able to run your application anymore. So you would
|have to know at least roughly how much control over the whole client
|machine you will have. Will they all be regular desktops that users
|will use day to day and then once in a while launch your application
|then close it, or will these all be dedicated terminals like an ATM?
|The two are very different. You can assume complete control of all the
|OS environment in a dedicated terminal but not in the case of a user
|desktop.
True - have not even considered this - this would, I imagine, vary from site to
site, and depend more on local IT policy - this is probably the strongest
argument to date against going this route, as these machines would not be as
tightly controlled as an ATM...
but then - If I want to use Python in the client at all, I would have to somehow
come to terms with this - its more the normal sort of version control that would
have to be done - after all if a user's machine is an XT running DOS - then its
going to have to be upgraded before it can be used as a terminal...
So this is more an argument against the use of Python on the client and I don't
like that...
|Hope this helps,
|Nick Vatamaniuc
8<----------------------------------------------------
Yes it does, Thanks. I feel we are getting closer to the point where I can
decide if what I am thinking of is practical or a pipe dream - it sounded so
simple - make a series of guis for a series of transactions, ship them to the
client, where there is a simple top level thingy that swallows them and ties
them all together and handles the comms to the server... I mean the language is
called Python... :-)
- Hendrik
"Bruno Desthuilliers" <on***@xiludom.gro>wrote:
| H J van Rooyen wrote:
| "Bruno Desthuilliers" <on***@xiludom.growrote:
| (snip)
| |If my original post was unclear I am sorry - the point I want answered,
if
| |possible, is how to make the client code effectively updateable on the
fly -
| |because the answer to this will influence the whole design of the rest of
the
| |system...
| |
| |This is something I have been thinking about... IMHO what you want is
| |not to "update client code on the fly", but to make the client mostly a
| |kind of interpreter for what the server sends in. That is, the client
| |code itself doesn't contain any application logic, it gets it from the
| |server and execute it. This can certainly be done with Pyro.
| |
| |Now while this may be an interesting project, I'm not really sure it's
| |worth the effort when we already have HTTP, HTML and AJAX...
| >
| You may be right and it might not be worth the trouble - but what you
mention
| above is closer to the sort of thing I have in mind - it is essentially
using
| python to create a script language, and moving scripts around - but hey -
python
| is already a script language...
|
| Yes, but it's not (alas) supported by browsers...
|
| so if Pyro is for 'moving the scripts around' - Then that is what I must
look at
| very hard...
|
| It's not for "moving the scripts around", it's for remote objects - kind
| of like Java's RMI, but, well, much more pythonic !-). Now the point is
| that Python being very powerful when it comes to dynamism and
| introspection, it should be possible to have a common client that
| basically just knows how to connect to the application server (using
| pyro). Once connected, the client asks the server for a set of objects
| (forms, menus etc) and the corresponding data. These objects then use
| the same mechanism to interact with the server. It's basically similar
| to the interaction between a browser and a web app - in that the client
| is potentially able to run any application sent by the server -, but
| with much more specialized client and app server and another protocol -
| and no other language than Python.
|
This is getting more and more interesting - its not the simple minded mechanism
I had in mind, but it will achieve the same thing, and it exists already - and I
can imagine it to be a very powerful mechanism, if I understand you correctly -
I am going to have to cry "time out!" to go and do some reading...
Thank you. - Hendrik
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
| On Thu, 3 Aug 2006 09:17:41 +0200, "H J van Rooyen"
| <ma**@microcorp.co.zadeclaimed the following in comp.lang.python:
|
| Can I not use the ssl module for encrypting the connections? - Please also
| understand that the system is aimed at small to medium companies, in
ouse -
| From my perspective the only valid reason to use a database would be for
the
| ease of reporting - the files are not large - and the speed of a dict lookup
in
| python is hard to beat for normal transaction processing...
| >
| You might want to read the "Kode Vicious" column in a recent issue
| of Queue (probably last months issue -- it's been in my carry-bag for a
| few weeks).
|
| For an "in house" effort, encrypting the LAN traffic is probably not
| the most meaningful focus. Securing the data /storage/ is more important
| -- why secure the LAN traffic if someone can walk off with a backup of
| unsecured database. And who'd want to even spend time with a LAN sniffer
| on unencrypted traffic if that same backup is available for filching.
| >
This makes sense - message is - lock your server room...
| NO! the last thing on my mind - want a dynamic process similar to banking
| terminals - see my response to Simon please
| >
| ? ATMs? Or internal clerk consoles?
Semantics - sorry - neither - thinking of credit card terminals - in which area
I have dabbled in a bit...
These things have horrendously complex terminal management systems and elaborate
mechanisms to download all manner of parameters to change their behaviour... -
most have their internal state controlled by the server, sometimes formally,
sometimes just via param download...
| Pretty much everything is already in the terminal software -- what
| the operator has access to, and sees, is dependent upon the privileges
| defined for their "account". No "dynamic" loading of code (for security,
| I'd not even permit remote updates -- I'd require a floppy or CD from
| inside the secure box to change operating software; as soon as you
| permit updates to be pushed from outside you expose the risk of a
| cracker pushing a customized code set).
|
I was not aiming for this paranoid level of security - when I said "secure" or
"reliable" I was just looking for something that would work and that I could
trust not to fall over all the time...
On the small boxes, the loading of software mechanism varies from manufacturer
to manufacturer - some allow, others disallow the download and activation of new
apps - likewise for the update of existing ones - but most banks don't use these
mechanisms, even if they are available - they all tend to bring the device in to
a trusted facility. I don't know one of them that actually use the mechanism on
a per transaction basis, because it would be, amongst other things, too slow -
but most of the systems can force the terminal into a reload of at least its set
of parameters the next time it logs in - and this mechanism is used by for
instance AMEX to vary the messages displayed on their terminals - not quite
"code" update - but the user can't tell the difference.
I used the example because this sort of facility is the kind of thing I want to
find out if Python could do, in a more dynamic way than what the terminals that
can use it, actually use it - little thinking that I was sowing confusion -
sorry...
If you are familiar with the sort of Terminal Management Systems I am talking
about, that control the behaviour of the remote box via parameter download -
then what I want find out is how to do that in Python, but with the added
proviso that I must also be able to download "pieces" of the application - where
"download" in this sense is just to a PC in the next office on the local LAN -
So far the Pyro package that Bruno has steered me towards sounds the most
promising way of doing this - but I still haven't been able to "research" it ...
Thanks for the input and sorry about the confusion.
- Hendrik
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
| On Thu, 3 Aug 2006 14:05:19 +0200, "H J van Rooyen"
| <ma**@microcorp.co.zadeclaimed the following in comp.lang.python:
|
| What I mean by this is that the server does stuff that I think belongs on
the
| client -
| like getting involved in the nitty gritty of what the client should
display -
| I want the client to be smart enough to do the assembly of the elements of a
| transaction
| by itself, going back to the server for data only when its needed - remember
|
| One thing to consider: Where is the separation between the database
| and the client. I believe most textbooks these days tend recommend:
|
| [db-server] <-[app-server] <-[client]
|
| (db-server and app-server can be the same hardware; the idea is that
| clients do not have direct access to the database system, and hence the
| back-end can be changed out without affecting any client... also,
| clients don't need to handle database errors, etc.)
Agreed - I would also need this application server to do the server end of my
"terminal management system"
|
| so I see the client interacting with the server quite a lot, eventually to
be
| able do things like auto completion of things like stock codes and
descriptions,
| customer details, etc. - but I don't want every keystroke flying over the
LAN
| and
| being handled by the server...
| >
| And where did you see the client obtaining the "completion data" --
| direct access to some other database tables or did you intend to
| download /all/ possible data.
no just a framework of more or less static stuff like document types, name and
address data, and account names and codes that is not subject to continous
change... *grin* I would have to apply *some* skull sweat to the problem...
|
| Typical web-based applications may have a minimal bit of data
| validation running on the client (JavaScript ... things like making sure
| /something/ has been entered into required fields, but not verifying
| that it makes sense), and only when the user clicks on a submit is
| everything sent to the application server, which then generates the
| needed SQL from the data fields for submittal to the database server.
|
| transaction is completed - like in a banking system, I envisage ways for the
| client to 'poll' the server to get the state of the last transaction, to
make
| this possible.
| >
| Bad choice... Upon submittal to the server, there should be a
| mandatory "good/bad" return code...
Here I take umbrage - not bad, good choice - let me elucidate - the return code
you are talking about is the normal thing, and it is the dead wrong way to
operate if that is all you do - what I am talking about is the failure
scenario - the way to make any transactionally based system robust is to have a
"GetTranResult" transaction that is routinely used before starting a new
transaction, to see if the previous one has completed properly - that way, the
client can either - continue with the new transaction, or - resubmit the old one
to try to get it to work or fail, or thirdly - advise the user that the previous
transaction has failed - it is, when you have thought about the flows and all
the possible ways in which they can fail - truly the only way to operate
reliably.
The above is the simple minded way to use such a facility -
You could also argue that the time to use this "polling" transaction is after
submitting the transaction, but if your return code is to be trusted, its not
needed - if the flows complete normally, its not needed - it is just needed for
built in recovery, and it works like a charm if both the server and the client
try to keep state over power failures and other disastrous events like losing
comms halfway through - especially for multi flow transactions that must update
different things on the server...
And it does no harm to ask the server the result of your last transaction when
you come up after power failure - you can then set the screens and stuff up to
the point where the server knows about them and have the user just curse a bit,
instead of a lot...
And most importantly, the data is safe (unless the database is corrupted, in
which case the likelyhood is high that yer screwed in any case) - and on this
note - if you have the reversed transaction too - i.e. a kind of
"GetPreviousLoggedTransactionResult" from the server to the client, you can make
recovery less painful, even in the case of database corruption...
Bad choice indeed! *snorts*
;-)
- Hendrik
H J van Rooyen wrote:
"Bruno Desthuilliers" <on***@xiludom.gro>wrote:
| H J van Rooyen wrote:
(snip)
| so if Pyro is for 'moving the scripts around' - Then that is what I must
look at
| very hard...
|
| It's not for "moving the scripts around", it's for remote objects - kind
| of like Java's RMI, but, well, much more pythonic !-). Now the point is
| that Python being very powerful when it comes to dynamism and
| introspection, it should be possible to have a common client that
| basically just knows how to connect to the application server (using
| pyro). Once connected, the client asks the server for a set of objects
| (forms, menus etc) and the corresponding data. These objects then use
| the same mechanism to interact with the server. It's basically similar
| to the interaction between a browser and a web app - in that the client
| is potentially able to run any application sent by the server -, but
| with much more specialized client and app server and another protocol -
| and no other language than Python.
|
This is getting more and more interesting - its not the simple minded mechanism
I had in mind, but it will achieve the same thing, and it exists already
WARNING : Actually, the only thing that "exists already" is Pyro (and of
course Python...) - all the rest is just me thinking out loud, and I by
no mean garantee that what I describe above is viable or sensible or
even reasonably implementable.
and I
can imagine it to be a very powerful mechanism, if I understand you correctly -
I am going to have to cry "time out!" to go and do some reading...
Indeed. And please don't hold it against me if it ends up being some
kind of Frankenstein's monster !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on***@xiludom.gro'.split('@')])"
From: "Bryan Olson" <fa*********@nowhere.org>
| H J van Rooyen wrote:
| [...]
| This is broadly what I had in mind, yes - but sort of down to
| a transaction
| level - this user does invoicing, this one enters cheques,
| this one does credit
| notes, and their supervisor can do all three, and in a
| different department its
| different because the jobs are different, but the invoicing
| GUI module is the
| same for wherever its used...
|
| Pretty much any business has to deal with those things. You are
| right about the need for transactions and authorization, and
| that you don't want to have to manually update all the clients
| whenever your modify the applications. Everyone has those
| problems, and consequently there's a large body of experience
| and conventional best practice. The highly redundant advice
| you've been getting is recommending that you to do those things
| that way most successful modern systems do them.
|
| No question what you describe calls for a DBMS. Further, this
| sounds like a job for a "three tier" architecture, what Dennis
| L. Bieber explained as [db-server] <-[app-server] <-[client].
| In the old days a three-tier system called for a large
| data-processing staff; today one guy can set up a simple one in
| an afternoon.
|
| In a three-tier system, either the database, the server
| application can enforce authorization policy. In order for the
| database to enforce authorization, the application creates one
| database connection for each client user, and logs in as the
| user. That works well for most accounting-type systems, where
| all the users are known in advance. In systems such as web
| shopping carts, the application typically has its own user ID,
| and creates all database connections as itself. The app, not the
| database, is then responsible for keeping users from reading and
| altering each other's data.
|
| Trying to enforce authorization at the client is generally a
| mistake. The user has too much control over his local machine.
| He is not limited to running just the code you provide.
|
|
| Don't get too hung up on choice of DBMS, but stick with portable
| standard SQL. I bet you'll find your potential customers want it
| to run against the database they already have. The particular
| tables your system needs will become part of their larger
| schema.
|
|
| --
| --Bryan
Thank you - this is a sane summary of the general business case, and I
particularly like the bit about keeping the SQL portable - its something I did
not even consider...
The conventional best practice advice is swamping my original query of how to do
something in Python...
Just a note:
If conventional best practice is followed all the time, without question - how
is it ever made better?
but that is probably a question for a separate thread - please ignore it
here... - it has nothing to do with the Python language.
- Hendrik
"Nick Vatamaniuc" <va******@gmail.comwrote:
| Hendrik,
|
| ---snip---
| Now part of the reason I would like to go the transaction type route
| instead of the "per user" route is robustness and maintainability, and
| the ability it would give me to introduce new transaction types easily
| - as I see it if say an invoice's GUI code is stable I would never have
| to touch it again even if I combine it with anything else, as it would
| have been designed from the start to combine with others of it's own
| ilk, under a kind of communications controller that is standard...
| ---snip---
|
| It could be possible to separate your GUI into various modules. So you
| could have for example:
| BillingGUI.py
| InvoicingGUI.py
| QueryGUI.py
| and so on.
| Then your central control application (Application.py) would get the
| set of module names allowed for that client to run during login. So
| after the user logs in, the next thing would be to "SELECT ..." all
| the GUI modules from the database to be downloaded. The client won't
| know which ones are there, only the server.
|
| So the set of possible GUIs will be sent over to the client (preferable
| in a zipped form). They are unzipped in some temporary folder (here you
| can do some caching to only download if the set changed).
|
| Then it would be imporant for you to create some nameing rule or some
| interface so the Application.py will know what GUI modules look like.
| For example you could have the pattern [Capitalizedname]GUI.py be a
| GUI module. The Application.py will then inspect the folder, and create
| a button and label for each possible GUI module and present that to the
| user. When the user clicks on the Button, the Application.py window
| gets hidden and the [Modulename]GUI.py module is executed. When done,
| the Application.py will be shown again and the user can either continue
| with another module they are allowed to use or quit.
|
| How does that sound?
This is the sort of thing I am looking for, thanks - its a bit rough as it
depends on magic gui names, but hey - I think it would be easy to implement,
even not using magic names - the server could tell the core app the names of the
files explicitly during the logon type dialog... *grin* that will move the magic
out of the client and on to the server...
| Also, you mentioned that you won't have more than a couple of simple
| fill-in forms and with drop-down options and so on. HTML then might be
| the way to go. If that's all there will ever be just try to do HTML
| (see Cherrypy, Turbogears and others....). If your GUI will be more
| complicated in the future, just stick with what you know (Tkinter for
| example).
|
| Good luck,
| Nick Vatamaniuc
|
Thank you for the support - now I would like to call "Time out" - I have a lot
of reading to do...
- Hendrik
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen"
| <ma**@microcorp.co.zadeclaimed the following in comp.lang.python:
| Now part of the reason I would like to go the transaction type route instead
of
| the "per user" route is robustness and maintainability, and the ability it
| would give me to introduce new transaction types easily - as I see it if say
an
| invoice's GUI code is stable I would never have to touch it again even if I
| combine it with anything else, as it would have been designed from the start
to
| combine with others of it's own ilk, under a kind of communications
controller
| that is standard...
| >
| Uhm... You've just described the "raison d'etre" of Object Oriented
| design/programming.
Oh No! - curses! It has slipped in under the radar! - I have always thought that
the reason for going the OO route is to obfuscate the code so that mere mortals
could never understand it...
|
| Each of your "transactions" (tasks/jobs/functions) would be a single
| "class" (this does not mean they may not incorporate other classes as
| part of them). Ideally, each class should be independent of the others
| except for a defined API. The "invoice" would be one "class" (actually,
| you may have a class for "invoice data" -- this being the information
| passing between the client and the server; and a class for "invoice
| presentation" -- the GUI. Plugging in another task should only involve
| the main client (new menu entry) with maybe an "import new_task" so
| picking the menu entry instantiates new_task.
| --
Yes got it, thanks- Hendrik
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen"
| <ma**@microcorp.co.zadeclaimed the following in comp.lang.python:
|
| >
| This is broadly what I had in mind, yes - but sort of down to a transaction
| level - this user does invoicing, this one enters cheques, this one does
credit
| notes, and their supervisor can do all three, and in a different department
its
| different because the jobs are different, but the invoicing GUI module is
the
| same for wherever its used...
| >
| Confusing use of "transaction"... Many are probably looking at
| "transaction" in terms of DBMS -- eg: a sequence of SQL operations
| (inserts/updates/deletes) that ALL must be successful (and committed)
| or, if any operation fails, ALL operations will be undone (rolled back)
| as if none had been performed.
|
| What you describe is something I'd refer to as different operator
| "tasks".
Sorry - I have spent too long in an environment where a transaction is something
you built, shipped, and got an answer for...
|
| For this control, and presuming you do NOT want to use a web
| interface, I'd still build all capability (ie, all menu and form
| definitions) into the client that is installed on all user stations.
| THEN I'd use the application server (since I still feel you want to
| control access to the database to one central point, not have to create
| a user account in the DBMS for each employee using the clients) to
| handle a login from the client -- the login would be used to access a
| privilege table from the DBMS. This privilege table is essential a long
| record of booleans -- one for each menu/form/task in the client. The
| privilege record is sent to the client; the client uses the record to
| enable and disable the relevant menu/form/task so that the user can only
| activate the functions valid for them.
|
*grin* this is the easy - cop out route - there is of course nothing
intrinsically wrong with it - I was just trying to find out how to do the harder
bits in Python - namely to dynamically present different things...
| Otherwise you have a situation where, say a lowly data-entry clerk
| has been using the application, maybe makes a mistake that requires
| supervisor override, and the supervisor then has to wait for "their"
| modules to be downloaded and started to correct the mistake. (Note: one
| menu entry that should be on the "all-in-one" client is an ability to
| change login without having to shut down the client -- basically the
| client does a log-off of the application server, then a fresh log-in
| with new parameters and gets a new privilege record with which to
| reconfigure all the menu/form/task GUI).
|
This is a disadvantage that I had not thought about - I was not yet this far
down the track
| If you go the web application route, each "login" would use a cookie
| to control session, so the application server can determine what
| functions to present to the user. You might even be able to use
| something like Plone to build the application server; it already has
| capability to present different views based upon login.
Know squat about Plone - another thing to add to my list of reading *sigh*
|
| My thinking is simpler than this, because you are already thinking in "data
base
| speak" - now dont get me wrong - I realise that I will have to use a
database -
| but for me to start thinking in terms of views and stuff is kind of
premature
| when I dont even have a clear picture in my head of the kind of data the
said
| management system should keep, as I am not sure of what can, and cannot be
done.
| >
| We're talking computer software -- enough money and time and you
| could have the sun, moon, and stars (granted, a decade ago I /was/
| involved with swapping out one satellite ephemeris package for another,
| so it was literally sun, moon, and stars <G>)
|
sounds like it was fun...
| You need to determine
|
| 1) architecture partitioning (DBMS <-thick client; DBMS <->
| application server <-thick client, DBMS <-application/web server <->
| thin client) [Thick client: Python program that handles GUI and talks to
| application server or DBMS; Thin client: web browser forms with some
| Javascript/AJAX].
I am kind of egregious - despite all the sound advice I am getting - I am still
thinking (from the back end) of:
dbms <app server <thick client (python)
|
| 2) Database schema (done without care of the final DBMS); take into
| account things you may not think of as the main data of the application
| -- things like the above privilege control (in the case of the
| DBMS<->thick client, it means using the grant tables and managing client
| accounts per user, in the application server model you only have one
| DBMS user that is the application server, but still have client user
| accounts to manage as application data). If the DBMS has stored
| procedures, you may need some of those... Heck, in the DBMS<->thick
| client model, you could let any client access ANY form/operation/task...
| What you'd do is run stored procedures for any DBMS transaction -- the
| first thing that would happen is that the user privileges are checked
| and the stored procedure either proceeds or rejects with "no privilege
| for operation" (and this could be either programmed in as part of the
| stored procedure, or be part of the DBMS internal privilege control).
| --
Yes this is the tricky part - it is so easy to overlook something, or to use an
awkward definition that comes back later to byte you in the butt (yes I know
bite is not spellt like that)
And it is not easy to do all this so that you can maintain it - when you get
back to it six months (or years) later, you are no longer the same person... the
"Who wrote this crap? " syndrome - and the answer - "Oh it was I"
;-)
So one has to follow some kind of discipline that you feel comfortable with...
Thanks for the input - I want to call "time out" now so that I can go and do the
reading I have been pointed to...
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
8<------------------------------
| There may be something in-between. IFF this is to be used strictly
| on an internal LAN with uniform architecture (all Linux or all WinXP)
| for the client machines. You'd have to set up something so a reboot
no such luck - reality will probably be Linux for server, and a horrible mix of
windoze machines on the client side - from 95 through 98 and 2000 to XP... will
have to get SAMBA running at least - and it could be tricky with some of the
older hardware/software around - but that is another fight, that I would have to
solve anyway.
| remounts correctly but... (In WinXP terms) Create a read-only "share" on
| a file server. The file server will contain the Python modules that make
| up the client. The client start-up still uses a login to obtain a
| privilege map, which controls the menu/form access. However, rather than
| having to push the modules to each client, you delay the module import
| until the form it controls is invoked. The start-up module would have to
This is more the kind of thing I had in mind - but I was not thinking in terms
of having the redirecting done by the OS and network file sharing - stupid I
suppose...
| add the "share" to the pythonpath (hence you want a uniform system
| configuration so each machine mounts the share on the same name).
|
I will have to think of a solution to this *shudders* - config files, maybe...
| It's still an all-in-one client, but you don't have to install
| anything on the user machines (except the "share" and a shortcut to the
| start-up module).
|
| For Linux, this would be an NFS mount.
*nods* Thanks Dennis - I am busy drinking out of the Pyro fire hose at the
moment - and the stuff I have seen so far looks bloody awesome - you do some
little bit of magic setup - and hey - you have a name server that you can query
and then you can remotely execute a method on a remote object just as if its
here in your machine, and you get the returns just like you would if the object
were local to the machine your Python script is running in...
And they have made a sort of mirror of the name server thingy so that you can
fall back to a non broken one and resync when things go wrong go wrong go
wrong...
As a low level johnny this sort of functionality impresses the hell out of me -
when I think of the time I have spent struggling to get a few small tightly
coupled machines to work together in a primitive way - my mind boggles at this -
you could create awesome capability by having multiple copies of objects hanging
around in different machines - and simply keep track of how much they are loaded
by monitoring their input queues - and make more instances as you need them as
loading gets higher... The only bottleneck is the LAN's capacity to move the
data around - but in most WAN type applications, that is not where the
bottleneck is...
and its not inconceivable to add an additional "Python Execution Gigabit
Backbone" to a cluster of machines, dedicated to this remote calling task...
Its almost too good for my simple little local job, but I am still reading...
I have to remember to thank Bruno for the pointer...
- Hendrik
H J van Rooyen a écrit :
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
(snip)
| If you go the web application route, each "login" would use a cookie
| to control session, so the application server can determine what
| functions to present to the user. You might even be able to use
| something like Plone to build the application server; it already has
| capability to present different views based upon login.
Know squat about Plone - another thing to add to my list of reading *sigh*
Well, actually, I would not bother too much reading about Plone here -
Plone is (fairly complex and somewhat slow) CMS built on top of Zope,
which is itself a web application server that's not easy to get started
with and is (IMHO) definitively much more suited to CMS than to
accounting apps.
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
| On Sat, 5 Aug 2006 11:20:59 +0200, "H J van Rooyen"
| <ma**@microcorp.co.zadeclaimed the following in comp.lang.python:
|
| >
| no such luck - reality will probably be Linux for server, and a horrible mix
of
| windoze machines on the client side - from 95 through 98 and 2000 to XP...
will
| have to get SAMBA running at least - and it could be tricky with some of the
| older hardware/software around - but that is another fight, that I would
have to
| solve anyway.
| >
| Well, other than the security differences -- which may not apply
| when the clients are mounting a share, only when the define a shareable
| partition -- I think the Windows side may be similar all the way
| through.
|
| This is more the kind of thing I had in mind - but I was not thinking in
terms
| of having the redirecting done by the OS and network file sharing - stupid I
| suppose...
| >
|
| Not really -- if one first is thinking in terms of "internet", which
| means unsecured global operations, instead of an internal-only, behind
| firewall, system.
*grin* you are being too kind - I was at no stage thinking internet...
|
| | add the "share" to the pythonpath (hence you want a uniform system
| | configuration so each machine mounts the share on the same name).
| |
| >
| I will have to think of a solution to this *shudders* - config files,
maybe...
| >
| I think Windows can be set to "reconnect on start-up", but it may be
| better just to add a BAT file to the client machines' system start-up
| directory containing the command line that mounts such a share.
|
|
This is a good idea - thanks
- Hendrik
"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr>
H J van Rooyen a écrit :
"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:
(snip)
| If you go the web application route, each "login" would use a cookie
| to control session, so the application server can determine what
| functions to present to the user. You might even be able to use
| something like Plone to build the application server; it already has
| capability to present different views based upon login.
Know squat about Plone - another thing to add to my list of reading *sigh*
Well, actually, I would not bother too much reading about Plone here -
Plone is (fairly complex and somewhat slow) CMS built on top of Zope,
which is itself a web application server that's not easy to get started
with and is (IMHO) definitively much more suited to CMS than to
accounting apps.
*deletes the reference to Plone from the little text file*
- Thanks This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mr.Tickle |
last post by:
// Run this code and look for his obvious error by the compiler
namespace FlagCheck
{
using System;
enum SomeFlags
{
|
by: Steven D'Aprano |
last post by:
When using the timeit module, you pass the code you
want to time as strings:
import timeit
t = timeit.Timer("foo(x, y)", \
"""from module import foo
x = 27
y = 45
""")
elapsed_time =...
|
by: lawrence k |
last post by:
Okay, I just backed up my database, just in case.
The whole schema for the database is here:
http://www.accumulist.com/index.php?whatPage=db.php
You can run any SELECT query against this...
|
by: Xah Lee |
last post by:
Python, Lambda, and Guido van Rossum
Xah Lee, 2006-05-05
In this post, i'd like to deconstruct one of Guido's recent blog about
lambda in Python.
In Guido's blog written in 2006-02-10 at...
|
by: Nagarajan |
last post by:
Hi group,
I am confused with "super" usage..It seems to be complicated and less
obvious.
Here is what I need to achieve..
class A :
def __init__( self ):
self.x = 0
class B ( A ):
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
