[cgiapp] Re: Yet another callback system proposal

[Mark Stosberg <suppressed>]

> Well, I was pretty conservative (read: timid) in my numbering.  We could
> obviously change it to:
>
>     FIRST         => 1
>     MIDDLE        => 50
>     DONTCARE      => 50
>     LAST          => 100
>
> Then the names don't lie, and people can use the numbers if they
> really need precise control.

I don't think numbers really help with precise control, because the
control desired is to have an affect on loading position relative to
other plugins which we are out of your control.

So, requesting position "1" doesn't stop another author from doing the
same and causing a conflict. Requesting position "1" also doesn't
communicate anything about /why/ the first position is desired, which is   
probably because it needs to load first relative to something else.
Which brings us to the next topic...

>> If the plugin loading becomes complex, it probably won't be numeric
>> slots that will be most helpful, but being able to express something in
>> terms a human could actually understand, like "this needs to be loaded
>> after the database handle is available".
>
> I was thinking about exactly this sort of thing!  If this approach is
> not considered to be too complex, I'm willing to take a stab at it.
>
> I guess the question is how to express the dependencies?  

How are the OSes handling this for advanced init script systems? It
seems like the same issue. (And not one I'll claim to be familiar with). 

> For instance,
> how does a plugin request a callback "after the configuration module has
> loaded"?
>
> We could do:
>
>    $caller->add_callback('init', 'my_setup', {
>        'DEPENDS_ON' => 'CGI::Application::Plugin::ConfigMumble',
>    });
>
> But the obvious problem here is that there are at least three CAP config
> modules out there, so how does the plugin say "after whatever
> configuration plugin the user happens to prefer"?
>
> Or does each plugin indicate its "provides" and "requires" properties
> when it requests the callback?  Something like:
>
>    $caller->add_callback('init', 'my_setup', {
>        'POSITION' => 'FIRST',
>        'PROVIDES' => [ 'log' ],
>        'REQUIRES' => [ 'config', 'database' ],
>    });
>
> That could work.  We could even make it so that a module automatically
> 'provides' its own package name, so that plugins can explicitly require
> a specific plugin by name if they need to do that.

Parts of this is good. I don't see a benefit to adding "Depends on
Module name..." logic. That seems like re-inventing "use Module::Name".

What's interesting here is having abstract services that are provided,
like logging or a database handle. 

What would it mean to require require a database service, though? It
would seem that the plugin would expect a 'dbh()' method to be available
with particular properties. This case is only different than 'use
Module::Name', if there happen to be more than other plugins that
provide exactly the same API for this service.

Right now we don't have many with this case. With the config modules, it
seems like we have several different interfaces, while there is just one
database handle plugin that seems popular.


Let me backup and express a more general philosophy. As software
releases evolve, it's easy to make them more complex and be backwards
compatible. It's hard to make them simpler without breaking something.

While I think there is more interesting discussion to be had about the
"provides" and "requires" ideas, as well as numeric positions, in terms
of releasing something soon, I'm most interested in the simplest
possible working solution. Assuming it's a good foundation, we can build
on it later to make it more complex if deemed necessary.

Would I would find most useful now is specific evaluation of the
proposed basic position system. Is it a good enough foundation to start
with? If not, let's discuss the fundamental flaws and let that flavor
proposals to adjust it.

Supporting numerics and positions relative to other services seems like
concepts that could be safely added later.

If the difference between LAST and REALLY_LAST is confusing, that will
be harder to get rid of.

    Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   suppressed     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .


---------------------------------------------------------------------
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