<div dir="ltr">Yeah, that works, or some general accessor on vhost.<br><br>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.<br>
<br><br><div class="gmail_quote">On Wed, Aug 6, 2008 at 4:21 AM, Mika Raento <span dir="ltr"><<a href="mailto:mikie@iki.fi">mikie@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For Jaiku I'm keeping a hash of my instances by vhost name and adding<br>
a Jaiku->get($vhost) (paraphrased) instead of adding things to the<br>
VHost.<br>
<br>
Brad didn't diss it in the code review :-)<br>
<br>
Mika<br>
<br>
2008/8/6 Jos I. Boumans <<a href="mailto:jos@dwim.org">jos@dwim.org</a>>:<br>
<div><div></div><div class="Wj3C7c">> On 06 Aug 2008, at 02:22, Artur Bergman wrote:<br>
><br>
>> In fact, it should only be accessible through closures (Unless you store<br>
>> it somewhere) since we don't want any global state to mess with clustering.<br>
>><br>
>> Cheers<br>
>> Artur<br>
>><br>
>> On Aug 5, 2008, at 4:24 PM, Brad Fitzpatrick wrote:<br>
>><br>
>>> I don't think this is a good change... RosterStorage is not a singleton.<br>
>>> You can run multiple vhosts within a process, all with different<br>
>>> RosterStorage mechanisms.<br>
>>><br>
>>><br>
>>> On Tue, Aug 5, 2008 at 7:30 AM, <<a href="mailto:commits@code.sixapart.com">commits@code.sixapart.com</a>> wrote:<br>
>>> r6532@coke: josboum | 2008-08-05 16:30:19 +0200<br>
>>> * for several plugins it's not possible to access their object after the<br>
>>> ->register()<br>
>>> phase is over; the object is then only referenced in closures.<br>
>>> This patch adds a method, ->singleton, to retrieve the object for later<br>
>>> use. This is<br>
>>> particularly useful for setting up applications a la<br>
>>> DJabberd::Plugin::MyApp<br>
><br>
><br>
> Good point. The goal here is to be able to manipulate the roster from your<br>
> App class.<br>
><br>
> Would it be acceptable to make the relevant plugin objects available through<br>
> their<br>
> vhost object, along the lines of:<br>
><br>
> $plugin = $vhost->some_method(....):<br>
><br>
> This would allow the vhost object to encapsulate all the plugins, and not<br>
> expose them<br>
> through any other way.<br>
><br>
> The implementation needs a bit of more thought, as the $vhost method call is<br>
> ideally<br>
> as dumb as possible, but the MyApp class shouldn't need to knwo much about<br>
> the internals.<br>
><br>
> Let me know if this the right way to proceed, and I'll happily add the<br>
> functionality<br>
> in a more sane way.<br>
><br>
> Cheers,<br>
><br>
> --<br>
><br>
> Jos Boumans<br>
> <a href="http://www.linkedin.com/in/josboumans" target="_blank">http://www.linkedin.com/in/josboumans</a><br>
><br>
> How do I prove I'm not crazy to people who are?<br>
><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>