> I am wondering what the current status of phplib is?

Obviously I can only speak for myself.

I do have write access to the PHPLib repository, but I have not 
had discussions with other project devs or admins about 
development plans. I haven't seen anything from the PHPLib 
project admins in about 2 years, but Richard Archer (who is a 
project dev and may be able to publish new releases) has written 
recently. It doesn't look like there's much of a future plan, 
and development is either dead or in a persistent vegitative 
state. On the other hand, the core functionality is stable and 
works, so there is not as much need for development as there was 
7 years ago when I started using/improving PHPLib.


> Who's still using it?
> If you are, why?  Legacy applications?  Do you use it in new projects?
> Is anybody interested in updating it (drop pre php4 or even pre php5
> support, add new features, etc)?
> If its not going to go anywhere further, what are the other options for
> currently supported replacements?  Pear::auth?

I currently have one major PHPLib app in production that I built 
and continue to maintain (4+ years old). There may be other 
PHPLib apps I've written still in production, but I can't be 
sure of that.

A few years ago I made several changes to my local copies of 
PHPLib - I think I committed most of them back into the PHPLib 
repository, but haven't checked recently. (One example - 
PHPLib's Oracle OCI8 DB layer was completely broken.)

For now, though, I am developing most new apps in Rails - I 
don't like Ruby's current performance, but I don't feel that the 
PHP clones of Rails have much to offer. Neither Ruby nor Rails 
are perfect or trouble-free, but they have a large active 
community and a framework that does much of what I need without 
getting in the way.

PEAR findings can be useful for some pieces of functionality, 
but when you have to configure (and/or manually bind) all of 
your core framework pieces to work together you might as well 
switch to Java where such time-wasting nonsense is deemed "enterprise".


> I've used phplib for years.  Mainly I am using the authentication features
> and I havent found anything else I like better.  But its showing its age.

I like (and use exclusively) the CRC auth variation that 1) 
keeps passwords hashed in the DB and 2) prevents eavesdroppers 
from catching the password hash in transit.


> I've never found the need for a templating system more advanced than
> phplib's (so things like smarty just seem rediculous to me) and even then
> I'm not sure I see the need for it.

I've recently used small bits of smarty functionality (I came in 
on an existing project that used it) and like it. Rather than 
trying to strictly keep PHP and HTML in separate files, I think 
the more important priority is keeping the display logic 
separate from the business and data logic.


> The database abstraction is simple and I've not needed to use anything other
> than mysql anyway.  Seems this part of phplib may be all but obsoleted by
> things like pdo, so maybe it should be changed to be just an API on top of
> pdo, just for compatiblity?

Last I checked (years ago), PHPLib's db class was faster than 
the alternatives. Merging it with pdo would probably decrease 
that speed. Of course, the database performance will usually be 
a much larger factor than the abstraction layer.


> sessions are now handled natively in php..

But for anything that needs to scale across multiple servers (or 
whenever you want to limit your slow disk I/O), you'll switch to 
storing sessions either in the DB or in memcached - might as 
well start out with them there. The difference between using a 
custom DB save handler for PHP's native sessions and using 
PHPLib's sessions is greater flexibility with PHPLib. Having the 
user sessions persisting across all of a user's logins or an 
app-wide "session" holding infrequently-updated variables is 
handy and easy to do with PHPLib.

I have no interest in using slow, insecure disk-based sessions.


> I would like to see phplib reworked and modernized around the core feature
> of authentication and advanced sessions management.

That's not a bad goal. Maybe you can convince a project admin to 
hand over the reins.

PHPLib was based on a good goal of being an integrated 
application framework. Many apps need a more extensive 
framework, but deciding what should be included is tricky. 
Having seen newer frameworks, I don't think I'll build another 
big (or critical) app in a framework that doesn't support easy, 
robust automated tests.


> I am desperately in need of cross-site authentication functionality,
> which it looks like it was discussed but never implemented, and I
> haven't seen any easy to use implementations in php.

There are different levels of cross-site authentication that 
have been discussed on this list from running multiple sites on 
the same servers to sharing logins with a site under another 
organization's control. I've implemented cross-site 
authentication for sites hosted on the same servers a couple 
times myself - it is trivial to build with auth_preauth(), 
passing authentication tokens (stored temporarily in the DB) via 
a hidden iframe or riding as parameters on a transparent gif request.

-- 

Layne Weathers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
phplib-users mailing list
phplib-users@[...].net
https://lists.sourceforge.net/lists/listinfo/phplib-users