<div dir="ltr">The modern code pattern for this sort of thing is for there to be an underlying notification service (like MQTT, AWS/SNS, ...) and to build IM and server-to-server comms on top of that. A serious refactoring would be to rip out the existing push directed IM system and replace it with a pub/sub notification system that inventory change notifications, HGIMs, etc can be built on.<div>
-- mb</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 8:35 PM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can see the justification for using IM server-side when what needs to be communicated is intended to reach specific users who may be online.For generic communications, we should not use IM. But for those specific cases, locating the user is the hardest task of the process; IM already does that. So I'm ok with doing it. As Oren says, refactoring this at some point would be nice...<div class="HOEnZb">
<div class="h5"><br>
<br>
On 3/13/2014 8:30 PM, Oren Hurvitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, this would be stateless. If the user's client can't be found then the<br>
message would be dropped.<br>
<br>
The logic to find the user's client, especially in the presence of HG, is<br>
very complicated. I wouldn't want to replicate it, and of course we wouldn't<br>
want duplicate code. There are only two choices that don't involve code<br>
duplication: use IM as the transport for this message, or a big rewrite that<br>
would create a generic locate+transport communications system, and then run<br>
both IM and the new API over that communications system. Option #2 is an<br>
order of magnitude more complex than Option #1, and tbh I don't have the<br>
time to implement it. I can do Option #1 in such a way that it would be<br>
almost like a generic mechanism; so this change would only need to be done<br>
once, not over and over for each future message we may want to pass.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018p7579027.html" target="_blank">http://opensim-dev.2196679.n2.<u></u>nabble.com/Proposal-notify-<u></u>clients-when-Robust-changes-a-<u></u>user-s-inventory-<u></u>tp7579018p7579027.html</a><br>

Sent from the opensim-dev mailing list archive at Nabble.com.<br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>