Re: Real Widgets and Template Languages

[James G Smith <JG...@TAMU.Edu>]

Gunther Birznieks <gu...@extropia.com> wrote:
>At 02:31 AM 5/25/01 -0400, Chip Turner wrote:
>>Gunther Birznieks <gu...@extropia.com> 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 <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

LDAP utilities (was: the widgets thread)

[Gunther Birznieks <gu...@extropia.com>]

At 10:49 AM 5/28/01 -0500, James G Smith wrote:
>Gunther Birznieks <gu...@extropia.com> wrote:
> >At 02:31 AM 5/25/01 -0400, Chip Turner wrote:
> >>Gunther Birznieks <gu...@extropia.com> 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 :)

I guess it depends on what you store in LDAP. I find that LDAP is useful 
for simple data structures but it can be much nicer to also have the data 
in a relational database for most applications to access things in one query.

I think I would like to see a public domain LDAP management console. This 
is really what you are talking about right? One of my coworkers wrote one 
in Perl back at Barclays Capital several years ago but he never bothered to 
open source it. I suspect there are a ton of places like that which custom 
design something like this and then never open source it due to laziness.

>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.

I guess I don't understand. The locking bit sounds slightly odd to me. 
Wouldn't it be easier to administrate a master LDAP server and have a push 
model of replication?

I am not sure what you mean by robust being a prerequisite for 
PKI?  Passwords are passwords -- just that certificates are larger and the 
SSL protocol has already decoded it for you.

In fact, certificates can be easier depending on how you deal with it. If 
you just look up a Cert Revocation List then you can take the SSL decoded 
cert to be whom the user says she is without doing an LDAP lookup. Then 
LDAP is only used for user attributes and it has less to do with PKI.

You only need to really store the certs in LDAP if you are talking about a 
certificate management system. And then that system should be protected 
anyway (the PKI management system) and probably won't need to be clustered 
as an app.

Of course, perhaps you use it differently than I am thinking of LDAP and PKI.