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

[Jos I. Boumans]

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?