On Sun, 19 Oct 2003, Mark Stosberg wrote: > On 2003-10-19, Christopher Hicks <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
