Well there are quite a few points that can help integration.

One must understand that, as a developer, he is not only adopting phplib
because it's easy for him.

It also has to be, if not easy, practicable for an administrator to
integrate it.
Only this way phplib can be an useful framework, people are interested
to adopt. 
It cannot be a framework for a single brick/application.

here we have to look at the problem from  three sides: package-developer
side, phplib side, user side

phplib-side

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

Kirk Ismay wrote:
> 
> Giancarlo Pinerolo wrote:
> 
> > I've recently come back to phplib et al.
> >
> > There are quite  alot of phplib-based packages out there. But each one
> > seems to suppose that you're installing phplib for the first time. In
> > that case that's (almost) straight-forward most of the times.
> >
> > The problem comes when you want to integrate one of these into a site
> > that already has its implementation of phplib, not disposable of
> > course.
> 
> I second that!!
> 
> I've encountered the problem as well.  Often, not only are the extending the
> base phplib classes, but are also modifying the base classes as well.
> 
> Guideliness for integration would be great. Perhaps adding a chapter or two on
> that to the docs would be good.
> 
> I'd be happy to proofread & contribute ideas on that.
> --
> Sincerely, Kirk Ismay
> ________________________________________________________________________
> The Net Idea Telecommunications Inc            Support: [EMAIL PROTECTED]
> 101-625 Front Street,                          Sales:  [EMAIL PROTECTED]
> Nelson BC, V1L 4B6
> Phone: 352-3512 Fax: 352-9780            Open Monday to Friday 9:30-5:30
> Toll Free: 1-888-246-4222                   10:00 - 4:00 on Saturdays
> ________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to