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. -- mb
On Thu, Mar 13, 2014 at 8:35 PM, Diva Canto <[email protected]> wrote: > 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... > > > On 3/13/2014 8:30 PM, Oren Hurvitz wrote: > >> Yes, this would be stateless. If the user's client can't be found then the >> message would be dropped. >> >> The logic to find the user's client, especially in the presence of HG, is >> very complicated. I wouldn't want to replicate it, and of course we >> wouldn't >> want duplicate code. There are only two choices that don't involve code >> duplication: use IM as the transport for this message, or a big rewrite >> that >> would create a generic locate+transport communications system, and then >> run >> both IM and the new API over that communications system. Option #2 is an >> order of magnitude more complex than Option #1, and tbh I don't have the >> time to implement it. I can do Option #1 in such a way that it would be >> almost like a generic mechanism; so this change would only need to be done >> once, not over and over for each future message we may want to pass. >> >> >> >> -- >> View this message in context: http://opensim-dev.2196679.n2. >> nabble.com/Proposal-notify-clients-when-Robust-changes-a- >> user-s-inventory-tp7579018p7579027.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
