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