"Dennis Lee Bieber" <[EMAIL PROTECTED]> wrote:
| On Thu, 3 Aug 2006 09:17:41 +0200, "H J van Rooyen" | <[EMAIL PROTECTED]> declaimed 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 -- http://mail.python.org/mailman/listinfo/python-list