[djabberd] kane, r795: r6532@coke: josboum | 2008-08-05 16:30...
brad at danga.com
Wed Aug 6 16:20:43 UTC 2008
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 <mikie at iki.fi> 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
> Brad didn't diss it in the code review :-)
> 2008/8/6 Jos I. Boumans <jos at dwim.org>:
> > 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
> >> 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
> >>> You can run multiple vhosts within a process, all with different
> >>> RosterStorage mechanisms.
> >>> On Tue, Aug 5, 2008 at 7:30 AM, <commits at code.sixapart.com> wrote:
> >>> r6532 at coke: josboum | 2008-08-05 16:30:19 +0200
> >>> * for several plugins it's not possible to access their object after
> >>> ->register()
> >>> phase is over; the object is then only referenced in closures.
> >>> This patch adds a method, ->singleton, to retrieve the object for
> >>> 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
> > App class.
> > Would it be acceptable to make the relevant plugin objects available
> > 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
> > ideally
> > as dumb as possible, but the MyApp class shouldn't need to knwo much
> > 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Djabberd