<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Aug 6, 2008 at 11:02 AM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</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;">
<div class="Ih2E3d">Brad Fitzpatrick wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
</blockquote>
<br></div>
Did you mean this to be specifically for RosterStorage?<br>
<br>
I ask because for other types it's not uncommon for the same class to be instantiated several times in the same VHost. Consider DJabberd::Component::External, for example.<br>
<br>
Since the roster-related hooks have a decline method on $cb I assume that it's intended to be possible for there to be several RosterStorage plugins loaded simultaneously too. I guess you could imagine overlaying a writable sqlite rosterstorage with a read-only LDAP one that declines all writes to allow them to pass through.<br>
</blockquote><div><br>I haven't thought about it much. I just don't want globals.<br><br>- Brad<br><br></div></div><br></div>