Yeah, that works, or some general accessor on vhost. Perhaps during configuration parsing, we keep a map from classname to instantiated object, and then clients can say $vhost->by_class("DJabberd::RosterStorage") and then the vhost iterates over all its instantiated objects looking for something that UNIVERSAL::isa("DJabberd::RosterStorage"), finding first, say, "DJabberd::RosterStorage::SQLite" and caching that in some vhost member hashref to make lookup faster later.
On Wed, Aug 6, 2008 at 4:21 AM, Mika Raento <[EMAIL PROTECTED]> wrote: > For Jaiku I'm keeping a hash of my instances by vhost name and adding > a Jaiku->get($vhost) (paraphrased) instead of adding things to the > VHost. > > Brad didn't diss it in the code review :-) > > Mika > > 2008/8/6 Jos I. Boumans <[EMAIL PROTECTED]>: > > On 06 Aug 2008, at 02:22, Artur Bergman wrote: > > > >> In fact, it should only be accessible through closures (Unless you store > >> it somewhere) since we don't want any global state to mess with > clustering. > >> > >> Cheers > >> Artur > >> > >> On Aug 5, 2008, at 4:24 PM, Brad Fitzpatrick wrote: > >> > >>> I don't think this is a good change... RosterStorage is not a > singleton. > >>> You can run multiple vhosts within a process, all with different > >>> RosterStorage mechanisms. > >>> > >>> > >>> On Tue, Aug 5, 2008 at 7:30 AM, <[EMAIL PROTECTED]> wrote: > >>> [EMAIL PROTECTED]: josboum | 2008-08-05 16:30:19 +0200 > >>> * for several plugins it's not possible to access their object after > the > >>> ->register() > >>> phase is over; the object is then only referenced in closures. > >>> This patch adds a method, ->singleton, to retrieve the object for > later > >>> use. This is > >>> particularly useful for setting up applications a la > >>> DJabberd::Plugin::MyApp > > > > > > Good point. The goal here is to be able to manipulate the roster from > your > > App class. > > > > Would it be acceptable to make the relevant plugin objects available > through > > their > > vhost object, along the lines of: > > > > $plugin = $vhost->some_method(....): > > > > This would allow the vhost object to encapsulate all the plugins, and not > > expose them > > through any other way. > > > > The implementation needs a bit of more thought, as the $vhost method call > is > > ideally > > as dumb as possible, but the MyApp class shouldn't need to knwo much > about > > the internals. > > > > Let me know if this the right way to proceed, and I'll happily add the > > functionality > > in a more sane way. > > > > Cheers, > > > > -- > > > > Jos Boumans > > http://www.linkedin.com/in/josboumans > > > > How do I prove I'm not crazy to people who are? > > > > > > > > >