Re: [phplib-users] current status of phplib

[Layne W. <la...@dr...>]

>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=20
had discussions with other project devs or admins about=20
development plans. I haven't seen anything from the PHPLib=20
project admins in about 2 years, but Richard Archer (who is a=20
project dev and may be able to publish new releases) has written=20
recently. It doesn't look like there's much of a future plan,=20
and development is either dead or in a persistent vegitative=20
state. On the other hand, the core functionality is stable and=20
works, so there is not as much need for development as there was=20
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=20
and continue to maintain (4+ years old). There may be other=20
PHPLib apps I've written still in production, but I can't be=20
sure of that.

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

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

PEAR findings can be useful for some pieces of functionality,=20
but when you have to configure (and/or manually bind) all of=20
your core framework pieces to work together you might as well=20
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)=20
keeps passwords hashed in the DB and 2) prevents eavesdroppers=20
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=20
on an existing project that used it) and like it. Rather than=20
trying to strictly keep PHP and HTML in separate files, I think=20
the more important priority is keeping the display logic=20
separate from the business and data logic.


>The database abstraction is simple and I've not needed to use anything oth=
er
>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=20
the alternatives. Merging it with pdo would probably decrease=20
that speed. Of course, the database performance will usually be=20
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=20
whenever you want to limit your slow disk I/O), you'll switch to=20
storing sessions either in the DB or in memcached - might as=20
well start out with them there. The difference between using a=20
custom DB save handler for PHP's native sessions and using=20
PHPLib's sessions is greater flexibility with PHPLib. Having the=20
user sessions persisting across all of a user's logins or an=20
app-wide "session" holding infrequently-updated variables is=20
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=20
hand over the reins.

PHPLib was based on a good goal of being an integrated=20
application framework. Many apps need a more extensive=20
framework, but deciding what should be included is tricky.=20
Having seen newer frameworks, I don't think I'll build another=20
big (or critical) app in a framework that doesn't support easy,=20
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=20
have been discussed on this list from running multiple sites on=20
the same servers to sharing logins with a site under another=20
organization's control. I've implemented cross-site=20
authentication for sites hosted on the same servers a couple=20
times myself - it is trivial to build with auth_preauth(),=20
passing authentication tokens (stored temporarily in the DB) via=20
a hidden iframe or riding as parameters on a transparent gif request.

--=20

Layne Weathers