Re: [phplib] [RFC] Future of phplib From: John-Mason Shackelford (john-mason <email protected>)
Date: 07/21/01

This is a long post, but I believe it will be worth the read :)

Dima Nemchenko wrote:

> Or, how many web programmers go to SourceForge and type in "PHP
library
> sessions"? How many then see no PHPLib.

Actually, this exactly what happended with me. I had read the PHPLIB
docs a year
ago or more but got pulled onto some non php projects. When I finally
came back to
doing some php work I started looking for a way to handle sessions in
php3 and
remembered PHPLib. The first place I checked was SourceForge and
freshmeat.net.
When I found the PHP site and cruised through the CVS it looked like
most files
hadn't been touched recently so I figured the project was dead. It was
not until I
joined the mail list that I realized there was still a community using
PHPLib.
While originally I hoped to contribute--the project appeared to lack
organization
and direction and I've not done much more than monitor the list.

SourceForge certainly wouldn't guarantee active development, but I think
it would
much more effectively facilitate communication and could help the
project feel more
"open" to contributors--if it is done right. Online message boards are
more readily
accessible to the general public than a list serve--even with archives
online.
Though it doesn't require much effort to subscribe to a list serve, it
is
surprising what a small change in approach can make. You wouldn't think
ICQ or IM
would be much easier than sending an e-mail, but the savings of a few
clicks
fundamentally changes the medium. Not that I am insisting on message
boards to the
exclusion of the list serve--the list has its advantages too. It's nice
not to have
to travel to a site to see what is going on. But clearly a list serve
favors those
currently involved, while message boards are more accessible to the
passerby and
casual contributor. Its worth thinking about how we can use these media
to best
advantage.

While SourceForge itself will not fundamentally change the project--the
opportunity
to clarify our objectives, put up new pages, etc. afforded by the move
would be
healthy. I do think that PHPLib is in need of re-inventing itself. Clear

objectives, active and accessible developers. and a facililty for easy
cooperation
and contribution could bring the project new life. It's been exciting to
see how
the list has really lit up in the last week or so. Perhaps it's a new
day.

The future of PHP will be in its active development and useful
innovation. Without
these there isn't a future re: of other considerations. PHPLib (or parts
of it
anyway) are some of the best examples of elegant code designI've seen
in PHP.
Unfortunately, as active developers dropped off one-by-one and it has
become more
of a hodge podge of useful routines. If PHP is going to have a future I
think it
needs to leverage its core design in the auth / perm system, but
overhaul the code
to deal with the issues that are now on the horizon--that will become
development
issues for the next generation of sites. PHPLib used to be way out front
in the
services that it provided--it still is in terms of pure design, but we
need to be
able to deliver a feature set that no one can touch now--but that
everyone will
want to use in the coming year or two.

More specifically, modern collaborative sites need:
--permissions assigned on the user and group level (instead of the 64
levels of
group permissions currently available)
--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.
--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.

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.
Furthermore, I shouldn't have to re-enroll on a second related site, for
an object
owner on that site to assign me permissions. Using SSL and XML all of
this is
within reach.

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, but I submit that PHPLib was designed some time ago. It was an
aggressive
project initially and gained acceptance because nothing else could do
what it did
as well. We are in a different era with new challenges. The spirit of
the original
PHP project was innovative and well designed for extension. By applying
some of the
foundational design ideas to new challenges will make PHPLib relevant in
its
present day context.

John-Mason Shackelford 

--
http://john-mason.shackelford.org

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