Ivan Ristic wrote:
>>bool psv_register(string var_name, array values, string access_key);
>>where var_name is variable name, values are array to regieter,
>>key is access key for the variable.
> 
> 
>   access key is unique id of an application? If so, I would still
>   prefer the approach with the configuration variable as I if
>   I know your access_key (no matter how complex it may be) I
>   can always access your data. With the configuration variable
>   you would need access to either php.ini or httpd.conf, which
>   typically requires root access.
> 
>   There is one more option, it is more of a hack really,
>   we can use the value of the session.save_path, which should
>   be set on the per application basis anyway.


access_key is like a password to access the array.
I know it's minimum security for shared environment.
But I think it's mostly enough.

I expect this kind of usage.
-------
// This line should kept in secret like database password.
define('MYKEY', 'relatively_long_random_string_here');

psv_get('VAR', MYKEY);
-------

Access key should be kept in secret just like password
if one needs security.

>>bool psv_is_registered(string var_name, string access_key);
>>Return TRUE is var_name is registered with the access_key.
> 
> 
>   Are these PHP userland functions? I believe that the approach
>   with _PERSISTENT or _APPLICATION is better as it is
>   more transparent for the programmer.


Hmm. I think you are expecting general purpose variable...
I just need "very large lookup table, which is read only array, that
has exteremly low overhead to use". It's not useful for many purposes,
but it's very cool for many applications, I think.
(I'm not aiming to this module to be a SRM for single server)

Please refer to SRM, msession or session_pgsql. I think you will
find what you need.

PS: I've already added $_APP to session_pgsql that can be used
as application variable. If msession and SRM supports it, it
would be great. (I know SRM has other way to do the same :)

--
Yasuo Ohgaki











-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to