<div><div>First let me say that an IRC gateway and a "Jabber" gateway would be two nice things. I don't know if they should be part of the core though, unless we decided to use one or the other as the core messaging protocol.
<br><br>Besides the issues mentioned already mentioned, I'd like to point out that XMPP is not that common and well known on the internet compared to HTTP, which I believe speaks in favor of HTTP and REST. Both in terms of getting delvelopers on this project, but also in a future adoption of our implementation.
<br><br>Having said that, I think XMPP offers some very interesting possiblities for handling scalability via message re routing.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
it<br>is very hard to get the performance you want out of most of the<br>implementations. the handshake protocols required to set up message<br>dialogs can be pretty heavy. (but i'm VERY happy that we would consider<br>
XMPP for instant messaging)</blockquote><div><br>Currently I see a lot of connects/disconnects being done, which really doesn't have to happen. E.g. currently connections between gridserver and regions are established for each transition between region. We could do away with a lot of the connection costs. So in a welldesigned app, the question is how hard this will impact us.
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">having said that... could we also open the discussion about what set of<br>functions is inherently part of the architecture & what are peripheral?
<br><br>> * User Services [grouped together]<br>> ** Profile Retrieval<br>> ** Instant Messaging                  --> Move to client?<br>> ** Inventory Handling                 --> Move to client?<br>>       * List Inventory                --> Move to client?
<br>>       * Rez Inventory Item            --> Move to client?<br><br>Can you define move to client? in this context?<br><br></blockquote></div><br>I think having clientside code, would be a boon to this project, doing that we could arrange for personal assets, profile and inventory which would persist between grids.
<br><br>We could go even further than that, and use SLProxy to switch protocols, eg. viewer communicates with SLProxy, SLProxy translates to XMPP and all OSGrid is XMPP or what ever we like. I have heard that SLProxy introduces lag, but the question is, how much of that is due to the implementation, and how much is due to the additional layer?.
<br><br>/tleiades<br>