Date: 07/21/01
- Next message: Dima Nemchenko: "Re: [phplib] [RFC] Future of phplib"
- Previous message: Tarique Sani
email protected>>: "Re: [phplib] [RFC] Future of phplib" - In reply to: nathan r. hruby: "[phplib] [RFC] Future of phplib"
- Next in thread: Björn Schotte: "Re: [phplib] [RFC] Future of phplib"
- Reply: Björn Schotte: "Re: [phplib] [RFC] Future of phplib"
- Reply: Richard Archer: "Re: [phplib] [RFC] Future of phplib"
- Reply: nathan r. hruby: "Re: [phplib] [RFC] Future of phplib"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
nathan r. hruby wrote:
> In an attempt to let PHPLib down slowly Kris and Ulf tried to get
> PHPLib ported into PEAR. As we all know (or at least should know)
> PHPLib won't be ported to PEAR in any form that will be usable with
> the current body of code that exists for it. Some of the HTML bits
> might make it in if someone makes them PEAR-ified. Session, Auth,
> Perm, DB_Sql, Template and such will die.
I completely missed that discussion. Where did it happen?
BTW I missed to stay up-to-date with the evolution of PEAR too, of which
I know little.
I'd like to read what happened, and why and how, it sounds as an
important point in the course of PHPLIB
> > Max has done some work on PHPLib-ifying PHP4 native sessions and
The port to PHP4 is very very interesting, and I can imagine it would be
interesting for a lot of people, was it only for the fact that a custom
savehandler is implemented...
The code is a lot lighter, and nicer and more easy to maintain too. And
faster.
And we got rid of those php statements made persistent.
I think the values of phplib now moved from the generic capability of
handling a session to the availability of more sofisticate features of
default_auth and permission schemes. These features are still unpaired.
Now phplib is more addressed to developers than to web designers, and as
I said, some self-configuring methods are much needed for packaages to
integrate smoothly with each-other.
XML, which means analyzable, recoverable persistent data, would be a
step forward too.
I am optimist, and can see a future for PHPLib
Of course I am interested.
And I happen to have quite a lot of time at times, and a bunch of code
extensions (which I myself can hardly track) that I'd be happy to give.
> I personally have a lot of time invested into PHPLib and would like
> to see it continue. Not just for phpSlash, but for my other projects
> and as an alternative to PEAR.
I really need the story about PHPLib-PEAR.
> So I propose we move PHPLib to SourceForge.
Nothing against that.
>
> Part of this proposal is a call for help.
I am available, but I am afraid have some quite oustanding limits
Giancarlo
-- Abbestellen mit Mail an: phplib-unsubscribe <email protected> Kommandoliste mit Mail an: phplib-help <email protected>
- Next message: Dima Nemchenko: "Re: [phplib] [RFC] Future of phplib"
- Previous message: Tarique Sani
email protected>>: "Re: [phplib] [RFC] Future of phplib" - In reply to: nathan r. hruby: "[phplib] [RFC] Future of phplib"
- Next in thread: Björn Schotte: "Re: [phplib] [RFC] Future of phplib"
- Reply: Björn Schotte: "Re: [phplib] [RFC] Future of phplib"
- Reply: Richard Archer: "Re: [phplib] [RFC] Future of phplib"
- Reply: nathan r. hruby: "Re: [phplib] [RFC] Future of phplib"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

