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?
