Re: [phplib] [RFC] Future of phplib From: giancarlo pinerolo (ping <email protected>)
Date: 07/21/01

John-Mason Shackelford wrote:

> More specifically, modern collaborative sites need:
> --permissions assigned on the user and group level (instead of the 64
> levels of
> group permissions currently available)

because you use atomic permission scheme, and make every 'level' work as
a group.
But you may have different auth classes using different auth_user tables
at the
same time. Not very dynamically at te moment, but...
Think of each 'auth_user' table as a group, and it's already there,
although the
table in the auth object name has to be 'variabilized' at runtime

> --web users need to be able to create permissions on objects and assign
> them
> accordingly and build their own groups (teams), the whole system needs
> to be
> dynamic rather than created at dev time or managed by a sysadmin.

Yes, as I said

> --permissioned objects provide hooks for workflow, etc.
>
> These two items alone will require a significant amount of work but we
> have good
> guides available. ACS, which appears to be one of the most
> sophisticated web
> development frameworks available for collaborative websites, is a well
> documented
> open source project with a well-designed object model. Their code is
> written in Tcl
> and is now being rewritten in Java. See
> http://developer.arsdigita.com/acs-java/doc/kernel/index.html. With a
> few committed
> developers, and several months work we could have a very sophisticated,
> yet easy to
> use permission system.
>

I think a lot less, using the above approach.

> What even ACS doesn't provide in the permissions area (and what will
> become
> important in the next few years) is the ability for sites to share
> permissions and
> authentication services with other sites. If I am a user on one site, I
> shouldn't
> have to re-authenticate to be gain access to materials on another site.

XML-RPC? I am interested, and have some acquaintance in that.

> I know what I am proposing is aggressive, but I don't know how you will
> attract new
> developers without a project that also holds a great deal of promise.
>
> One might think that this is not really in keeping with the original
> goals of
> PHPLib,

It was so flexible then, that still holds a good position.

Giancarlo 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>