--- Cees Hek <[EMAIL PROTECTED]> wrote:
> Quoting Bill Catlan <[EMAIL PROTECTED]>:
>
> > Should C::A::Plugin perhaps put the plugin methods
> > into C::A space, and not the C::A app module?
> After
> > all, the plugin is a /C::A/ plugin, not a 'MyApp'
> > plugin.
>
> Hi Bill,
>
> That is how the C::A::Session module currently does
> it. But there are some
> concerns with this approach, especially when working
> in a shared environment
> like mod_perl. There could be multiple application
> running on the webserver
> that all use CGI::Application. Once one of them
> loads a plugin, those methods
> would be visible to all applications. Some would
> consider that a benefit, but
> it has the potential to cause problems.
>
Hi Cees,
Thank you for the thorough response. I thought of the
problem you mention, but not so much from the "rug
being pulled out from under you in mod_perl" angle.
Still, the issue is the same - namespace collision.
I'm not sure I can propose the best solution without
some more thought. However, you can still have
namespace collisions between plugins brought into an
app module, which is not desirable and which I propose
should be solved now. Thus, if we need to solve the
namespace problem, we should solve it and use the
approach that brings the plugin into C::A, since it is
a C::A plugin.
In addition, the sys admin will decide the "base
install" and plugins can be added or removed from any
instantiation of the C::A object, by, for example,
register_plugin and unregister_plugin object methods.
Probably less of an issue, however, after we resolve
namespace issues satisfactorily.
As an intial thought, how about putting plugin methods
onto a cgiapp hashref:
$cgiapp->{plugin_token}->plugin_method;
We could always do both!!! TMTOWTDI!
Bill
> As a quick example of a problem that could arise.
> Lets say I have an AUTOLOAD
> method in my app, and I am looking to capture calls
> to a method called
> 'session'. My app runs fine, until someone installs
> another application that
> uses C::A::Session. This now adds a 'session'
> method to CGI::Application, and
> now all the sudden my app is broken, as my AUTOLOAD
> no longer traps the call to
> 'session', since there is now a real 'session'
> method in CGI::Application.
>
> Or to change the example slightly, say I wrote my
> own session module, and stuck
> a use base qw(CGI::Application My::Session::Module)
> in my app. Everything works
> fine until someone else uses C::A::Session and
> things start to break in my app.
>
> Those examples may be a little contrived, but the
> possibilities are real.
>
> This isn't an issue when working with a plain CGI
> script, or commandline script,
> but can cause problems in persistent environments
> like mod_perl and SpeedyCGI
> where you have multiple applications loaded at the
> same time that could be doing
> wildly different things.
>
> Cheers,
>
> Cees
>
>
---------------------------------------------------------------------
> 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]
>
>
---------------------------------------------------------------------
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]
