[DGD] Re: My idea for the DGD driver - validate

Robert Forshaw iouswuoibev at hotmail.com
Fri Feb 13 02:07:30 CET 2004


>From: Michael McKiel <crashnbrn71 at yahoo.ca>
>Not going to quote anything specific here...
>But couldn't this functionality be done by a mapping of a given object and
>certain security conscious functions within that object ...
>ie the mapping would be on the object_file_name and the function in 
>question,
>and contain what is allowed to call it.
>
>and the function itself would just start with:
>
>if (!validate(previous_object()) return [0|nil];
>or optionally do some logging/warnings:
>if (!validate(previous_object()) { alert(previous_object()); return 
>[0|nil];

Can you index nil on an array..? Anyway, the idea seems workable, but the 
feature I had in mind would be at a more fundamental level, to be implented 
by whoever is coding the lib itself. The idea you are suggesting uses 
variables to determine security, and the only reason to have it in variables 
would be to allow other people to come along and set the security with some 
abstract function (like one sets the daemons in the kernel lib). Its akin to 
the idea of not exposing people to the complicated 'innards' of the driver, 
and instead have them only required to know a simpler set of functions that 
modify a simpler set of variables (although I find the issue of security to 
be anything but simple, and if you're targetting mediocre coders who just 
want to be able to set variables via a function, the security should already 
be implented in the lib to avoid such a feature being necessary).
Therefore, while I don't find anything particularly wrong with your idea, 
its a totally different thing to what I had in mind as its at a higher 
level.

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list