I myself wrote:
 
>  Phplib, technically, has all the hooks, and more, 

First, we should clarify which features  are 'reversible', which are
'transparent', which are 'no-way-back'.

With 'reversible' I mean that you can undo it all, and it won't hurt or
disrupt anything
With 'transparent' (but maybe you find a better word) I mean you can
adopt one or the other, and that wouldn't affect anything
With 'no-way-back' I mean that, once you set up your phplib like that,
you may not change it unless you loose something important

Of course, features are not one of these three kinds 'per se'. They
become one of these kind in a particular situation, combined with ather
features.

An example:
Your site uses phplib for plain session handling only. No user, no perm,
no authentication, no login.
In this situation you can, without any worry, drop all your tables to
change storage method, adopt split tables, change encoding and
serialization.

This is most true when your cookie lifetime is set to 0.
Whent its set longer you'll have some loss of session stuff, but that
may be not gravious because it's all 'anonymous information'.

Up to now everything is 'reversible'.

The problem, we know, comes at the moment we start to adopt user, perm
and auth, and that particular derivation of these that is the
default_auth.
At this point your implementation af phplib becomes 'not disposable'.
You cannot scratch everything and restart anymore. 
It's not 'reversible' anymore.

But still it can be 'transparent' and continue to be for quite a lot.
This means that you can twickle the settings of a new package you're
installig,  to make it adapt  the configuration you already have in
place in a 'transparent' way.
This job nowadays is quite hard, and you must hope that the package has
not been delivered with a modified core function and look for settings
that it has and that belong to the 'no-way-back' cathegory.

What is nice and powerful of phplib is that I can't see any
'no-way-back' features 'per se'. Everything can be extended, and this is
great design. But particular settings of your implementation can get you
to a 'no-way-back' situation.

I have some doubt about this on the 'permission checking scheme', but
here maybe I am wrong, because you can extend the class with a different
scheme. But they are based on the same table... (I need some enlightment
here) 

What about 'preauth'??
Here too you can have an extended  auth class that uses 'preauth'
somwhere, and nd use another extended class that uses the normal auth
mechanism, but here you can really get in a cul-de-sac. 
You 'can', but is not always true. Here you have to know what you are
doing I think.

Anyway, as this is great design, it's a pity that using it to it's full
power is so difficult.

In the end the hooks for a 'respectant package-development' are all
there, there's no one I can think of that is missing.
Of course, to accomplish that, you have to resort to some 'registry' (I
hate this word) or '.ini' or the already existing _PHPLIB_[....]
defines, and provide methods for developers to smoothly integrate into
an existing implementation.

Giancarlo Pinerolo




More precisely, there is some feature that is 're


>  
>  Phplib, technically, has all the hooks, and more, 



 to bear a lot of
>  applications. it is a framework.
>  But once you start to give a shape to your particular implementation,
>  these hooks become less and less.
>  That is normal.
>  What I think of, is a sort of 'self discovery' mechanism for
>  applications, so that they kindof 'configure', or 'auto-configure' if
>  you prefer, themselves on an existing phplib implementation.
>  It's there already, we know.
>  
>  package-developer side:
>  
>  provided these 'configuring' methods, the application should be written
>  to extend compliantly its own usage of the framework. Now php4 has all
>  you need to inspect objects and methods.
>  
>  Lets' make a practical example: preauth.
>  
>  Is the existing phplib implementation adopting a 'preauth' mechanism?
>  This question can be easily answered with PHP4.
>  But the same goes for many others, like passord encryption,
>  challenge/response, $nobody (default auth) etc.
>  
>  Can the application run interchangeably with any of these? Most do.
>  So the app looks for the 'hooks', th eones it knows it can hold to, and
>  uses them instead of its proper ones.
>  
>  Would it be difficult to give 'packagage app designers some method to
>  inspect this? Probably, but not impossible.
>  
>  user-side:
>  
>  People get to phplib for essentially two reasons:
>  
>  1.they have to develop someting and find phplib has the capabilities to
>  help them
>  2. they install  phplib  beacuse it's delivered with a package
>  
>  Normally, if they like it for both ways, the'll like to eithr install
>  more packages that use it, or attach to their home-made work some
>  package that uses it.
>  
>  The idea is: 'oh!, this stuff uses phplib, and I've already got it on,
>  so I'll be fine'
>  
>  That's not true. They must be aware that, the more and more block they
>  put o it, the more it will be difficult to get the correct 'hooks' out
>  to attach what they want there.
>  They need to be advised on the consequencies of basic choices as
>  'default authetication', password encription, container and
>  serializazion issues.
>  And all of his is already well explained in the docu, but people read on
>  fast when, at the moment, it looks like stuff that doesn't matter...
>  
>  Hope this doesn't sound too extravagant. And surely I'd appreciate some
>  proofreading, as you see my english is quite 'maqueronic'
>  
>  Ciao
>  Giancarlo
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe@[...].de
For additional commands, e-mail: phplib-help@lists.netuse.de