Re: [cgiapp] Re: Comments requested

[Christopher Hicks <suppressed>]

On Sun, 19 Oct 2003, Mark Stosberg wrote:
> On 2003-10-19, Christopher Hicks <suppressed> wrote:
> > On Sun, 19 Oct 2003, Mark Stosberg wrote:
> >> I think I find the "mix-in" method the most intuitive way to handle
> >> plug-in methods generically.
> >
> > The DBI/DBD model for plug-ins is much more intuitive from the module user
> > perspective, but it does take a lot of work to pull off something that
> > elegant.  Any volunteers?  :)
> 
> You mean how there are lots of "DBD::*" modules which talk to different
> backends? That seems like a different case to me, since the the DBD::*
> modules are mostly trying to implement the same interface. With
> CGI::App plug-ins, I would imagine that each one would mostly be
> defining it's own interface for unique functionality.
> 
> If you are referring to something else, could you elaborate?

Sure.

The DBI::DBD model I was referring to was the fact that DBI.pm can
discover all of the DBD's installed by the way they have things setup.  
It's painless to use - one "use DBI" line and everything else it finds for
itself.  One of the nice things about cgiapp (or your own personal
inheritance of it) is that you don't have to "use" tons of different
modules.  Since the plugin architecture described was based on adding 
"use" lines for every plugin my gut reaction was that in some sense it was 
going backwards.

Back to your first point:
> the DBD::* modules are mostly trying to implement the same interface.
> With CGI::App plug-ins, I would imagine that each one would mostly be
> defining it's own interface for unique functionality.

Bah.  There really aren't that many different kinds of plugins that should 
be required.  Wouldn't 90% of these plug-ins amount to various content 
generators and authorization schemes?  If so, there should be some 
defined interface so we don't have one interface for checking a file for 
passwords and a different interface for checking LDAP for passwords.

The content generator plug-ins make an even more compelling case for
utilizing a DBD-style for plugins.  We're all using some templating system
right?  So I'm sure that we've all experienced being able to fix bugs
without going into our cgiapp's Perl code.  I'd be happy if more bugs were
that easy.  So, why make extra reasons to go into the code?  If I say I
want a counter plugin utilized from a template, my script will crash if I
forgot to add the use line for that plugin to that script?  Bah.  Why 
should the programmer have to keep up with that sort of housekeeping?

To solve these problems in Perl and to continue to strive for making
things as data driven as possible you have two choices.  (A) Have every
possible plugin "use"d in every cgiapp which would lead to horrendous
script start times while in CGI mode or more wasted memory in mod_perl.  
Or (B) move to an architecture where you don't have to do an explicit use
to discover and take advantage of the functionality of the component.

There are lots of other examples of this sort of technique in other
languages.  JavaBeans provide a common API to components that are able to
explain and negotiate their capabilities with the component user or
automatic tools.  Many languages have some method of "reflection" or
"introspection".  
http://216.239.37.104/search?q=cache:vScLawy7BKgJ:www.algorithm.com.au/files/reflection/reflection.pdf+object+reflection+component&hl=en&ie=UTF-8#7

These examples show there are several things worth keeping in mind:

- your audience may be a programmer writing code or it may be a dip
clicking and dragging and drooling in some visual tool.  We don't have a
"CGIAPP designer" yet, but we definitely never will if we don't have a
plug-in system that allows it.

- a common interface can be built regardless of the disparate purposes of
the little black box components.  Most JavaBeans have a visual component
that the user interacts with in some way, but not all.  There are plenty
of completely nonvisual components to perform everything imaginable.  
Regardless there's still varying degrees of common interface that can be 
shared and we should encourage that.

- within these defined common interfaces functionality can be negotiated.  
Maybe I want my counter to show roman numerals, but the counter I'm using 
doesn't support that.  Oh well, but there should be some way to express "I 
must have roman numerals or I'll die" and "I want roman numerals, but I 
want a counter more" so these interfaces can be built resiliently.

Back to trying spark an effort to utilize the DBD idea in cgiapp, the
sticking point is that DBD has a reputation for being tough to deal deal
with for the driver writers.  The effort is considered to be saved by the
users, but the DBD driver writers pull their hair out supposedly.  
Obviously we don't want that problem either, but I think the idea of
having these self-registering modules is a popular enough idea that
somebody could take concept behind the DBD/DBI method and write a module
that would allow any project to have self-registeration if so desired.  
This would be a significant project, but one that's very clearly defined.
Once that nut was cracked using it within a plug-in architecture for
cgiapp would be a relative breeze.  Any voluneers?  :)

-- 
</chris>

No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed