[djabberd] kane, r795: r6532@coke: josboum | 2008-08-05 16:30...
mikie at iki.fi
Wed Aug 6 11:21:33 UTC 2008
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 clustering.
>> 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
>>> 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
> 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
> 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
> 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
> in a more sane way.
> Jos Boumans
> How do I prove I'm not crazy to people who are?
More information about the Djabberd