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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
