On Wednesday 05 July 2006 11:03 pm, Elliot Lee wrote:
On Jul 5, 2006, at 23:38, Dennis Gilmore wrote:
>> - In particular, there is a lot of concern that getting a GPG key
>> is too complicated for a lot of people such as translators, who are
>> not technical types. We need to make that process as clear and simple
>> and documented as possible
>
> can we provide a script for nontechnical types?
One good possible solution...
>> - Allow groups to be members of other groups (i.e. you are
a member
>> in group B because you are a member in group A, and A is a member of
>> B). Can't do this nicely with the current SQL schema. I did it nicely
>> with the old Red Hat build system, but it requires using text fields
>> instead of numeric IDs to specify the names of the group members...
>
> with the right interface it shouldn't matter if GID's/UID's are
> numerical or
> text
This was where I diverged into an implementation detail rather than
stating a problem. At the SQL schema level, it does matter. All this
should be totally transparent to the user...
that was what i was trying to get to
the user should have no clue of the
implementation. I could be wrong but i think it could be done either way
>> - On a related note, we need to add proper support for the
corporate
>> CLA. If we had 'groups being members of other groups' implemented, it
>> would be fairly easy to create a group for each corporation that
>> signed the CCLA, have each of those groups be a member of the
>> cla_done group, and having access to the corporate CLA groups
>> administered by a designated contact...
>
> Sounds good. is there many corporate CLA's?
I believe Dell and IBM are the only ones (I know Dell, not sure about
IBM).
So not huge but with it being easy for the corporate type to participate
It
could encourage others to sign up
>> - Figure out the whole LDAP vs SQL thing
>
> Why not use both? some thing will be just easier in ldap, some in
> SQL, use
> SQL as a backend to ldap Its a little more work but would provide
> greatest
> flexibility.
Can you explain more of what you're thinking in this area? In my
thinking you have to have one authoritative place to store the data,
and while you can do things like offer other interfaces as desired,
it's not really a matter of using two solutions where one will do...
What i was
thinking was to keep the authoritative data in a SQL server with
ldap server as a client
http://www.flatmtn.com/computer/Linux-LDAP.html provides one way to implent.
I personally have not done it. But i think it could be an option.
(BTW, how hard would it be to implement an LDAP server whose tables
were the direct results of SQL queries, with no gatewaying done? Is
there a python module to make it easy to implement an LDAP server?)
Best,
-- Elliot
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
--
Dennis Gilmore, RHCE
Proud Australian