Gunther Birznieks <[EMAIL PROTECTED]> wrote:
>At 02:31 AM 5/25/01 -0400, Chip Turner wrote:
>>Gunther Birznieks <[EMAIL PROTECTED]> writes:
>>
>> > However, I think it is reasonable to make the interface to support a
>> > data source for the widgets flexible and object based to make it easy
>> > for someone to write a DBI source, a DBM source, an LDAP source, an
>> > Apache::Session source or whatever anyone wants really. I happen to
>> > think DBI and Session sources are cool.
>>
>>I agree; unfortunately writing classes to interface to all of these
>>would be difficult, and it would be difficult to be futureproof. When
>>you hit LDAP and DBI you must then worry about databases, tables,
>>servers, usernames, passwords, etc. It can become cumbersome to do
>>the simple things.
>
>I disagree. I've written interfaces like this before to LDAP and DBI. The
>constructor (or config method) on a data source is stuff like usernames/
>passwords, and in the case of LDAP, schema mappings.
Hmm... Something I'd like to see is a set of classes in Perl for managing
LDAP. These classes would need to be generic (configurable) enough to work
with any LDAP schema. They would need to provide an audit trail, transaction
log, etc., that could be used to replay changes made to LDAP. They would need
to be able to enforce data consistancy across branches and data integrity. If
noone gets to it before I do, I'll port my PHP code to Perl :)
Oh, and locking mechanisms used must be transferable between machines -- I
lock resource A on machine X and then hand off the lock to machine Y -- this
code must be useful in a distributed environment (web farm) and robust enough
for use in a PKI.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
