Yeah, I think for any really large scale installation you would want to leverage existing pub/sub tech (I used to work
on bits of IBM Websphere MQ in another life).
But I also think you should always be able to set up a 'reasonably' sized installation just with core OpenSimulator,
which means striking an appropriate balance between simplicity and functionality (e.g. creating components which work
well but are still in C# and don't have every conceivable complexity magnifying bell and whistle).
The problem I have with extending the use of IM structures in this case is that whilst it is relatively easy, I also
feel it might push more Second Life-isms into places where they don't need to be present and really don't make sense.
The result could be a very ad hoc and unintuitive interface with fields which are often inapplicable (e.g. 'fromGroup'
and 'imSessionID') and a temptation to abuse the format by serializing parameters into the binaryBucket.
Maybe it can be made to look very generic and I'm unnecessarily concerned. It would make me very happy if this was done
in a separate branch first (if you do decide to continue with this at this time and not implement the other short-term
solution for your particular task) so that we could review the effects. Changes like this tend to calcify very quickly
even when present just in master.
On 14/03/14 03:52, Mister Blue wrote:
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 <d...@metaverseink.com
<mailto:d...@metaverseink.com>> 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
<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
Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_________________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
