[djabberd] kane, r795: r6532@coke: josboum | 2008-08-05 16:30...

[Brad Fitzpatrick]

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
> VHost.
>
> Brad didn't diss it in the code review :-)
>
>   Mika
>
> 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
> 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, <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
> 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?
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/djabberd/attachments/20080806/d9be5203/attachment.html