<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 21, 2008, at 3:15 PM, Etan Reisner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Alternatively, we could add a prpl callback for privacy checking (and not<br>switch on the ability to control the privacy list in general) and then<br>have XMPP implement such a function looking for chat room buddies<br>specifically and falling back to the core version (assuming we keep the<br>core version) if it doesn't.</span></blockquote></div><br><div>I like this, and I think it's actually the reason that this is more suited to core functionality than a plugin.  A plugin <i>could</i> check the prpl id and use per-prpl logic, but that'd feel pretty dirty to me.  Implementing it as a prpl callback with a core, basic implementation to be called by the prpl if desired is quite clean.  Both options Etan proposed would implicitly change the behavior that the core's privacy filtering is only used if the prpl has *no* idea of privacy... because *some* idea of privacy may not be the same granularity or the same behavior we want to implement in a protocol-independent fashion across libpurple.</div><div><br></div><div>I think the core implementation should still check open conversations... XMPP would add chat room buddies to that list.</div><div><br></div><div>-Evan</div></body></html>