Re: [Phplib-users] What is the 'standard phplib install'?

[Giancarlo P. <gia...@na...>]

First of all I am very happy we starded discussing on this.

I think that providing a setup script doesn't diminishes the
underlaying
power of phplib, it just gives a tool to those a lot of users who
just want an infallible setup. Of course it has to be infallible,
otherwise... If he then needs something more specialized, the usual
way
is always available.
I don't want to confuse application programmers' with 'phplib
programmers'. We can be considered 'phplib programmers', but not
everyone does.  Of corse me or any phplib-core developer would not
need 
that.

Having the possibility to rely on a set of 'standard setups, can be
useful for those who provide general-use packages based on phplib too,
because they can say: if you have installed a 'standare phplib setup'
then my application works as-is, otherwise do this and do that... If
this only covers 30% of cases it is already a great result..

I am in no way saying that phplib itself has to be simplified. And in
fact I am working on a redesign of the user/auth/perm classes, which
in
my opinion should be further expanded to encompass things as
'different
schemes for groups' or the concept of 'application users', 
and some mechanism as  'stackable' User classes.
You cannot deny that 31 total levels of permissions, atomic or
inclusive, are not much, and can be a limit, for example if you
provide access to different 'companies', or if you install a few
applications based on phplib

My idea, that of 'stackable' User classes (but you may want to call
them
'Group classes' or 'Application User classes' then), came from these
constatation:

if you install multiple phplib applications, each wants to have its
admin, authors, and whatever, and not to clash with preexisting ones.
there are two solutions to this: kk groups/perms, or multiple User
classes, loaded by a supervising 'Master User class' 

The first solution is more structural, clean, scalable, etc. and there
is not much more to say about this than that 'groups' can be intended
as 'application users groups', users that belong to a paricular
application.

The second solution is achieved by coding instead of defining
relations among tables,
but for it to work you need to have a 'Master User class'  capale of
instantiating 
other User classes, each one, possibly, accompaigned by its Auth and
Perms, and
even its auth_user tables if needed. 

And these 'Application User' classes can further be configurated to
either:
a)be merged  into an unique, persistent User storage
b)have their data sored in a separate, persistent record
c) be reloaded everytime, that is not be made persistent


You see that is not 'simplifying Phplib' at all, but making it really
a
framework.

Of the above two methods, one doesn't exclude the other. So you could
have KK groups/perms on top, I'd say for 'static' definition of 
groups/perms, 
'and each application have it's own User/auth/perms loaded/unloaded, 
for more 'dynamic' groups/perms 
It's always the same dualism: structured data against code.

I think it is importantt to give a programmer the possibility  to
'defer'
the implementation of an Auth to someone else, at a later time,
without
obliging the implementor to modify his code. 
The KK groups/perm scheme givesa good chance to simplify the
integration of an application Auth scheme byy someone different than
the author, reducing it to the creation of the necessary gruops/perms
names in the various groups/perms tables.

Anyway there was an interesting post on this list, that focused the
main
needs to accomplish this 'non-clashing' between application
Auths/perms
ad site 'Auths/Perms'. It listed the main 'checkpoints' to be passed
in
order to achieve independance. Cannot find it anymore. You know,  the
archiving of phplib-users doesn't work on sourceforge.


- Gian


nathan r. hruby wrote:
> 
> On Mon, 10 Sep 2001, Richard Archer wrote:
> >
> > While these packages may offer a simple "just add one line" alternative
> > to PHPLIB, they certainly don't have the power or extensibility of this
> > library.
> >
> 
> Agreed.  Dumbing down phplib isn't what's called for.  Power and
> flexibility mean a bit more complexity in the system (I think we all know
> that) it's a small price to pay and modifity a few config files and maybe
> learning a little php syntax is really not that hard, espically if you'll
> be trying to make money off your phplib based site -- I assume youd want
> to know how it works!.
> 
> OTOH, making phplib easier to integrate with multiple apps is something we
> should strive for; however a lage part of that relies on the application
> authors to address those issues.  It's not something that phlib can
> easily or elegently deal with.  A spec is needed and app writers should be
> given several methods for publicizing their phplib specfic info or simply
> not sharing with anyone.
> 
> The current local.inc is a bit loaded, but as all app writers know, we
> don't care about local.inc becasue we can use our own custom subclasses :)
> I think that, if anything, local.inc should be killed in favor of site and
> app specfic config files defining what's needed.
> 
> -n