AW Groupies/Chat Logs/AWGroupies-2009-01-13

• [9:50] Zha Ewry: OK
• [9:50] Zha Ewry: We're on the record
• [9:50] Morgaine Dinova: "Measured" simply means that we can ask questions like "What state is it in?" :-)
• [9:51] Zha Ewry: And.. I don't see any pre-prepped material.. so.. We're open (and yes, I owe us all some)
• [9:51] Morgaine Dinova: Well, IBM can, but I'm assuming Zha lets us too :-)
• [9:51] Saijanai Kuhn: wakes up completely
• [9:51] Dahlia Trimble: ya I'm familiar with the term :/
• [9:51] Saijanai Kuhn: hey rex
• [9:51] Zha Ewry: So.. Group IM
• [9:51] Rex Cronon: hi sai
• [9:51] Morgaine Dinova: Hola Rex
• [9:52] Rex Cronon: hi morgaine, hi everybody
• [9:52] Zha Ewry: I'm intersted, as long as we have a plan to:
• [9:52] Zha Ewry: both design and code
• [9:52] Object: Touched.:
• [9:52] [[User:Object: <-0.85822,|Object: <-0.85822,]]: -0.10431, 0.50256>
• [9:52] Dahlia Trimble: Hi Rex :)
• [9:52] Zha Ewry: Not just a paper story
• [9:52] Alchemist Redgrave: hi
• [9:52] Rex Cronon: hiii:)
• [9:52] Morgaine Dinova: defers re-requesting "state of AD" info until after IM topic
• [9:53] Saijanai Kuhn: Well, as far as I can tell, we can shoehorn any other messaging system into the IIM packet, so the only real issues are concerning that conection point
• [9:53] Dahlia Trimble: I've looked at XMPP a bit but I can't seem to find an ecample where it's in use and serving more than 50-60 clients at a time for any one "room"
• [9:54] Dahlia Trimble: *example
• [9:54] Zha Ewry: Can we assume we'll replace that mess with a set of caps?
• [9:54] Morgaine Dinova: Dahlia: the company backing ejabberd development tested XMPP with 1 million users.
• [9:54] Saijanai Kuhn: oh yes. Infinity wanted to just go with UDP as an interum solution at one point and I'm like noooooo
• [9:54] Dahlia Trimble: 1 milliion users, but hoe many n a single room?
• [9:55] Morgaine Dinova: A mix, I'll try to find you the reference
• [9:55] Dahlia Trimble: ejabberd seems to be the fastest implementation as far as I can see
• [9:55] Morgaine Dinova: But any discussion about XMPP for IM currently founders on Zero's phrase "XMPP is a bad semantic fit for SL".
• [9:56] Saijanai Kuhn: but again, as morgaine has said, the back-end is separate fromt eh front end. I can see various group IM servers getting merged at some point but all looking the same to the SL client
• [9:56] Dahlia Trimble: I wasnt attempting to suggest that LL™ adopt xmpp
• [9:57] Dahlia Trimble: rather I was investigating how it may fit with opensim
• [9:57] Morgaine Dinova: Since Zero's statement hasn't been explained too well technically (to my liking), I'm not even sure if XMPP is actually non-viable or if it was just an excuse.
• [9:57] Saijanai Kuhn: Dahlia, seems to me you'll hit the same issues as for SL
• [9:57] Saijanai Kuhn: whatever they are... ;-)
• [9:58] Dahlia Trimble: which is why I was looking to find a high volume "room"
• [9:58] Zha Ewry: peforms a small linden summoning ritual
• [9:58] Saijanai Kuhn: the highest volume rooms I know of are the WoW forums they have 100K users online. Not sure how many in a given room however
• [9:58] BlueWall Slade: hmm, group IM is mostly listeners?
• [9:59] Rex Cronon: is there such a room that supports on million users?
• [9:59] Zha Ewry: The usage pattern IM has is messy
• [9:59] Goldie Katsu: clicks on the summoning ritual after selecting the correct linden.
• [9:59] Rex Cronon: one*
• [9:59] Morgaine Dinova: That's why I'd quite like to talk to any Opensim devs that may have examined highly scalable IM. It's not a case of "just hack something in" --- LL did that, and it's not good.
• [9:59] Saijanai Kuhn: checks his crystal ball to see who is actually on...
• [9:59] Zha Ewry: Nobody has done it in OpenSim, Morgaine
• [9:59] Lim Catteneo: Zha, group IM or agent-agent IM?
• [9:59] Zha Ewry: Group IM
• [9:59] Zha Ewry: Agent-agent is pretty simple in comparison
• [10:00] Dahlia Trimble: the highest volume conversation I've found is #ubuntu on freenode, and it's typically over 1000 clients at one time, but it's IRC
• [10:00] Morgaine Dinova: Zha: yesterday we had a discussion about it, and some suggested that some Opensim devs are at least *thinking* about it.
• [10:00] Xugu Madison: Can we try finding a Jabber Eliza bot or something, put a few thousand in a "room" and tell them our day was terrible?
• [10:00] Xugu Madison: ...see if it works, basically
• [10:00] Rex Cronon: agent-agent would be even easier if it was p2p:)
• [10:00] Saijanai Kuhn: A 1 million avatar room is a real world issue. Metanomics has been talking to Ira Flatow on how to implement it for Science Friday
• [10:01] Lim Catteneo: Rex, firewalls wreck havoc on p2p
• [10:01] Zha Ewry: Presence and keepign track of who is on inside a group, is the scale mess
• [10:01] Zha Ewry: You end up with a lot of activity in the form of "John's now on at endopint x" if you don't watch it
• [10:01] Saijanai Kuhn: Lim, reverse http-ptth can handle firewalls in theory
• [10:01] Goldie Katsu: replicate presentations across multiple "shards" of islands with a relay system and bots for the copies of the original presenter.
• [10:02] Zha Ewry: IRC, in the face of serious load partitions furiously
• [10:02] Morgaine Dinova: Given the numbers we're working too, I think we may be going beyond current XMPP implementations. But my first concern is whether the MODEL of XMPP suits, because if it doesn't then it's pointless continuing down that road. And Zero has said it doesn't suit.
• [10:03] Rex Cronon: what goldie says migh have a high chance of sucess at least for rooms of 100k, could even work for 1mill:)
• [10:03] Zha Ewry: Well, I'd start with a basic question of what the model of a group IM session is, and nail down the scale points
• [10:03] Morgaine Dinova: Yeah
• [10:03] Dahlia Trimble: you mean as implemented in SL?
• [10:04] Rex Cronon: might
• [10:04] Lim Catteneo: thinks of group IM as an equivalent to IRC channel.
• [10:04] Saijanai Kuhn: Lim, yeah, but... ;-)
• [10:04] Morgaine Dinova: I have a second but equally important worry: that people are going to hack this into existing grid code, and hence end up with license non-interoperability. It should be an independent project, with LL and Opensim as no more than fully committed clients.
• [10:05] Saijanai Kuhn: Morgaine, with OpenSIm being bsd and pyogp being apache v2 I think we will have at least 2 open references to the code
• [10:06] Morgaine Dinova: But others will be GPL, so it's no-go.
• [10:06] Morgaine Dinova: Whereas an independent project avoids that.
• [10:06] Goldie Katsu: (looks like wow shards are about 8k active players - and that is across many separate regions)
• [10:06] Xugu Madison: Could we use Jabber for avatar-avatar, and an IRC transport gateway (which I'm fairly certain Openfire has, for example) for group chat?
• [10:07] Saijanai Kuhn: Xugu, I don't think its just messaging that is the holdup with SL group IM
• [10:07] Saijanai Kuhn: its tracking presence
• [10:07] Lim Catteneo: Zha, if you think of group IM as an equivalent to IRC channel, the presence bit can then be handlend client side. On login, the client "joins" needed "channels" and displays in UI appropriatly when messages arrive
• [10:07] Xugu Madison: Doesn't Jabber have enough presence support, or does it get too complex?
• [10:07] Morgaine Dinova: Presence can be tracked as just the control part of group IM. It's essentially IM without data transport.
• [10:08] Lim Catteneo: Morgaine, you neet to track presence somewhere
• [10:08] Saijanai Kuhn: yeah, but there's a LOT of precence traffic for a single SL group
• [10:08] Zha Ewry: watches as the puff os blue and pink smoke twirls encouraglinly
• [10:08] Morgaine Dinova: Lim: can be done as part of IM.
• [10:08] Dahlia Trimble: I think the current SL™ client assumes all IM comes from the current simulator, and it uses a custom LL protocol
• [10:08] Zha Ewry: Me completes the Linden Summoning ritual and smiles
• [10:08] Saijanai Kuhn: ImprovedInstantMessage packet
• [10:09] Infinity Linden: yay! we're talking about IM
• [10:09] Saijanai Kuhn: Hey Ms Everything Linden
• [10:09] Infinity Linden: and the hopeful death of the IIM packet
• [10:09] Zha Ewry: Assume that twe'll replace that with Caps?
• [10:09] Zha Ewry: Please
• [10:09] Zha Ewry: please
• [10:09] Lim Catteneo: with IRC paradigm, you can decople presence problem from central services to client side
• [10:09] Zha Ewry: please?
• [10:09] Zha Ewry: and yes Lim, you clearly want to do that
• [10:09] Morgaine Dinova: Tackling presence in IM is unavoidable: every presence change alters the coresponding messaging exploders. It's so strongly tied that it makes no sense handling presence separately.
• [10:09] Saijanai Kuhn: Zha IIM packet is kinda a given for the near term just because of hte client interface coding issue (IMHO)
• [10:09] Infinity Linden: YES. IIM will be replaced with LLSD/LLIDL via a Cap
• [10:10] Saijanai Kuhn: right, but still that massive multi-purpose thingie, at least for a while...
• [10:10] Infinity Linden: sure. IIM will be with us... probably for at least a year or so
• [10:10] Dahlia Trimble: will it still be required to go through the current simulator?
• [10:10] Saijanai Kuhn: Dahlia hoping we can get the connection points defined between AD and client instead
• [10:10] Morgaine Dinova: Hiya Infi :-)
• [10:11] Infinity Linden: that is... i can't imagine we would be able to agree on a design, implement it, test it, fix performance problems, give up and redesign, then retest and redeploy in less than a year
• [10:11] Lim Catteneo: Dahlia, very good question, asked it many times, but there is still no one big overview of the OGP archicecture
• [10:11] Saijanai Kuhn: Testing will take care of itself once pyogp matures a little bit. Enus has vissions of cloud computing pyogp with 10K avatars for testing
• [10:11] Infinity Linden: right. there was some wrestling internally about the question "does the Agent Domain _really_ handle GroupIM?"
• [10:11] Infinity Linden: not much... but a little bit
• [10:11] Zha Ewry: as an endpoint at least I hoep its in the loop
• [10:11] Infinity Linden: and we eventually realized that if we did it right
• [10:12] Zha Ewry: The bursting is seperable
• [10:12] Morgaine Dinova: A scalable IM can't possibly go through the current simulator. Not a chance :-)
• [10:12] Zha Ewry: but.. gettign the endpoint stable (and off the regainos) would be a hueg win
• [10:12] Saijanai Kuhn: Infinity, I don't think it matters past the authorization bit
• [10:12] Dahlia Trimble: or could the Agent Domain hand group IM off to another provider?
• [10:12] Infinity Linden: it wouldn't matter... you would create a group IM cap as a URI
• [10:12] Zha Ewry: Where the burster runs is basicalyl less interesting
• [10:12] Zha Ewry: just hand it off as a cap
• [10:12] Infinity Linden: and if that URI happened to point to a third party
• [10:12] Infinity Linden: well
• [10:12] Infinity Linden: there you go
• [10:12] Morgaine Dinova: In effect, IM will be a new Domain block --- IMD
• [10:13] Zha Ewry: but th endpoint you use to deliver to. you want to be seperate from where you are in the grid
• [10:13] Dahlia Trimble: well if for example it hands it off as a set of credentials to connect to a jabber serer
• [10:13] Lim Catteneo: well we should be able to IM wihtout being rezzed :)
• [10:13] Infinity Linden: Morgaine... it has the ability to become it's own domain, but the current plan of record is still to deploy it as part of the Agent Domain
• [10:13] Dahlia Trimble: *server
• [10:13] Infinity Linden: in the near term
• [10:13] Zha Ewry: Which seperating endopint from region does
• [10:13] Infinity Linden: oh oh. yes
• [10:13] Infinity Linden: that's one of the reasons why authentication is distinct from the inital rez
• [10:14] Infinity Linden: you can authenticate yourself, get the seed cap (which should contain a reference to your group IM cap) and just chat away without placing yourself anywhere
• [10:14] Saijanai Kuhn: Infinity, seems to me that with multiple ADs that's really an implementation detail
• [10:14] Infinity Linden: and one of my great hopes is to be able to implement this in JavaScript
• [10:14] Infinity Linden: so
• [10:14] Infinity Linden: i'm looking forward to the day where this works without UDP/IIM
• [10:14] Morgaine Dinova: Infi: it would be a bad move to put it in AD, because the AD will then not use service calls to it but take shortcuts, and hence won't be using the same service as Opensim.
• [10:15] Saijanai Kuhn: tried to implement AD in ActionScript but too many issues with server authorization list
• [10:15] Infinity Linden: implementaton is distinct from interface, Morgaine
• [10:15] Rex Cronon: group IM in javascript, client side?
• [10:15] Zha Ewry: to my mind, the AD is just providing the IM message delivery point for the burters
• [10:15] Infinity Linden: right... i really want to be able to have a Google or Apple Dashboard widget that can do group IM
• [10:15] Infinity Linden: on the client side
• [10:15] Saijanai Kuhn: and possibly keeping them uptodate about who is online...
• [10:16] Zha Ewry: Within trason sure
• [10:16] Zha Ewry: *reason
• [10:16] Morgaine Dinova: Actually, if Infinity says it's going into AD, then it's a disaster project-wide, because it'll be impossible to implement it as a separate service to which LL and Opensim are just clients.
• [10:16] Morgaine Dinova: project-wise*
• [10:16] Infinity Linden: and while i would be happy to see more Server Side JavaScript, it's just not ready for prime time
• [10:16] Rex Cronon: u might be able to do that in combination with either flash or java
• [10:16] Saijanai Kuhn: Infinity, my original python client almost could, sorta. It was sending one message at login and dying after that
• [10:16] Infinity Linden: okay... add it to the list of disasters
• [10:16] Saijanai Kuhn: then DOnovan fixed a bug and it never worked again :-(
• [10:17] Infinity Linden: there's clearly no requirement to implement OGP Group IM in OpenSim
• [10:17] Infinity Linden: but
• [10:17] Infinity Linden: as it is today... it is the plan of record at LL
• [10:17] Saijanai Kuhn: Morgaine, I think the conection poit will be in the AD, just to send/receive the IIM packet or LLSD-XML equivalent
• [10:17] Saijanai Kuhn: so hypergrid could take the place of the AD, for a wild west metaverse
• [10:17] Morgaine Dinova: Infinity: why do you want IM system code that Opensim can't use? Why force them to reinvent it, and double the bugs?
• [10:17] Infinity Linden: sure
• [10:17] Infinity Linden: go for it
• [10:18] Infinity Linden: i'm fairly certian we'll be implementing OGP before we implement HyperGrid
• [10:18] Saijanai Kuhn: Moergaine, IIM is just for convenience' sake because its so damned hard to mod the client GUI at that level
• [10:18] Morgaine Dinova: I'm talking about IM only.
• [10:18] Saijanai Kuhn: group IM?
• [10:18] Morgaine Dinova: Yeah, not Hypergrid, which is a lot more.
• [10:18] Infinity Linden: gets rather embarassed about the "ease of extensibility" relating to the SL viewer
• [10:19] Goldie Katsu: thinks about reinventing the wheel.
• [10:19] Saijanai Kuhn: the GPL client needs a specialized GUI thing which means we need to leverage the interface that exists for IIM (for now)
• [10:19] Goldie Katsu: Rather than creating new rims
• [10:19] Saijanai Kuhn: Infinty, sorry. Still obsessed with that after trying to reuse folders for my keyword tree thingie...
• [10:20] Infinity Linden: no seriously... if the OpenSim community wants to implement HyperGrid, they should implement HyperGrid. I'm just thinking there will be some people who want to operate an OpenSim instance thats interoperable with SL
• [10:20] Saijanai Kuhn: Dale Glass knows how to do it, but I bounced off the class hierarchy
• [10:20] Morgaine Dinova: So, Infinity, your answer means that you don't expect Opensim to create a scalable IM system and hence you're writing your own closed one, is that right?
• [10:20] Infinity Linden: in which way is our interface closed?
• [10:20] Goldie Katsu: Why are we having an IM that is separate from existing IM platforms?
• [10:20] Morgaine Dinova: I did not say INTERFACE
• [10:20] Saijanai Kuhn: Moregaine, scalability is seaparate from the IIM issue. That's just a GUI interface thing for the GPL
• [10:21] Goldie Katsu: should virtual worlds be a separate thing from the rest of social networks/web?
• [10:21] Infinity Linden: for $DIETY's sake, we leaked our interface design to get comment from the community
• [10:21] Zha Ewry: looks for her firehose
• [10:21] Saijanai Kuhn: the existing packet is really part of the GUI in a sense
• [10:21] Morgaine Dinova: I did not say INTERFACE
• [10:21] Morgaine Dinova: I did not say INTERFACE
• [10:21] Zha Ewry: Can we cool down a touch
• [10:21] Morgaine Dinova: I did not say INTERFACE
• [10:21] Infinity Linden: sure
• [10:21] Goldie Katsu: or do we ned to add additional functionality to existing protocols to start to build cross functionality with the rest of the web.
• [10:21] Lim Catteneo: sai, stop confusing things with gpl viewer interface talk :)
• [10:21] Morgaine Dinova: OK, so let's ignore interface. I am talking about system code for a scalable IM.
• [10:22] Saijanai Kuhn: thinks that is the point. Its confused, so we have to spearate things out in a workable way
• [10:22] Morgaine Dinova: You propose to make a closed implementation of scalable IM, which Opensim cannot use
• [10:22] Saijanai Kuhn: Morgaine, here is what I see us doing...
• [10:22] Infinity Linden: for the record, there was a proposal floated that included an XMPP interface into the agent domain for external chat clients
• [10:22] Morgaine Dinova: I did not say INTERFACE
• [10:22] Infinity Linden: it appeared to get NO traction
• [10:22] Morgaine Dinova: Christ
• [10:22] Infinity Linden: yes
• [10:23] Infinity Linden: we have evaluated a number of open source implementations (she says, repeating Zero's commentary)
• [10:23] Saijanai Kuhn: new IM stuff <=> AD connection point <= IIM packet for convenience sake => client
• [10:23] Infinity Linden: none of which appear to have the scaling features we would like to see
• [10:23] Morgaine Dinova: Agreed
• [10:23] Infinity Linden: and yes. we evaluated jabberd
• [10:23] Dahlia Trimble: so could a standalone opensim instance connect to this proposed XMPP interface?
• [10:23] Saijanai Kuhn: OR new IM stuff <=> hpergrid connectivity < = IIM packet for convenience sake => client
• [10:23] Morgaine Dinova: So you want a scalable one ... which should be an open project, otherwise you;re forcing Opensim to reinvent it.
• [10:23] Infinity Linden: so the point is... we're going to implement a Group IM service.. and we need it to be scalable
• [10:24] Infinity Linden: yes. OpenSim. PLEASE Implement a new IM system
• [10:24] Morgaine Dinova: Exactly. So my point stands.
• [10:24] Xugu Madison: Good to know you looked at jabberd, thanks for clarifying there Infinity
• [10:24] Infinity Linden: we all benefit from 1000 flowers blooming
• [10:24] Dahlia Trimble: or could a future client maintain group IM while interacting with a standalone opensim region?
• [10:24] Morgaine Dinova: You propose to make a closed implementation of scalable IM, which Opensim cannot use, instead they has to implement yet another one. Why?
• [10:24] Saijanai Kuhn: Morgaine the only SL-relevant bit is the IIM packet part, to let the GPL client have a GUI without serious mods
• [10:25] Morgaine Dinova: Sai: that's thje interface
• [10:25] blotto Epsilon: it would be interesting to hear how existing XMPP implementations failed to meet scalability requirements
• [10:25] Infinity Linden: i didn't say we were making a closed implementation
• [10:25] Infinity Linden: but
• [10:25] Infinity Linden: i suspect
• [10:25] Infinity Linden: it will be so tightly dependent upon our architecture as to be virtually useless to anyone else
• [10:25] Saijanai Kuhn: libsl or pyogp or anything else can be modded to use an entirely new interface, so this is really just a client <=connection=> issue, not a scalability one
• [10:25] Infinity Linden: right sai
• [10:26] Zha Ewry: Long term, I am not unhappy, as long as we do it so that we can plug together multipe
• [10:26] Zha Ewry: versions of code which meats the spec
• [10:26] Infinity Linden: the fact of the matter is... the discussion about "just adopting XMPP" is over and done with
• [10:26] Morgaine Dinova: Infinity: there is no need for it to be dependent on your architecture at all. Group IP and presence can be done portably.
• [10:26] Zha Ewry: and get a web of IM which works properly
• [10:26] Infinity Linden: we cannot (we believe) implement XMPP without some serious under the hood work
• [10:26] Lim Catteneo: The way I imagine this working (using IRC terminology, not implying use of irc backend): You authenticate against AD which hands you a CAP for joining in "channels". Its up to the client at this point to "join", connect to these "channles" for which it got URLs. The act of "joining" a channel should allow group IM service to handle presence without needing to talk to central services, beyond initial authenitcation token validation.
• [10:26] Infinity Linden: which makes us wonder... why are we doing this?
• [10:27] Morgaine Dinova: We're doing it so that VW's IM isn't dead as a dodo.
• [10:27] Saijanai Kuhn: Morgaine, can we agree, that for now, in order to keep SL in the loop, we have a SL viewer compatible connection protocol? anything else is up for discussion, but in ofrder to use the only viable fully functioning client right now, we need to keep an IIM connection poitn
• [10:27] Infinity Linden: yup. and in an ideal world, the IM protocol endpoints could represent IRC, XMPP, SIMPLE, IIM or OGP IM
• [10:27] Zha Ewry: /afk a moiment
• [10:28] Infinity Linden: but... in the near term... we're thinking our plan is to wrap a LLSD/LLIDL wrapper around our systems that currently implement IM
• [10:28] Saijanai Kuhn: or all of the above or something entirely new
• [10:28] Morgaine Dinova: Sai: OF COURSE we want SL compatibility. :-) The problem is that LL wants to hold tight onto IM instead of going for open IM + compatibility layer.
• [10:28] Saijanai Kuhn: Morgaine I don't hink they are saying that
• [10:29] Infinity Linden: Morgain... it's an open world... if you don't like our interface, just code another one
• [10:29] Morgaine Dinova: By keeping the code proprietary within their AD, they are saying exactly that.
• [10:29] Infinity Linden: nothing we're doing will prevent you from doing that
• [10:29] Infinity Linden: nd
• [10:29] Infinity Linden: and
• [10:29] Saijanai Kuhn: I think the "compatibilty layer" is the IMM XML-LLSD protocol between client and Ad
• [10:29] Infinity Linden: i would actually like it if you did
• [10:29] Infinity Linden: because the more ideas that can be demonstrated, the better
• [10:30] Saijanai Kuhn: and once that connection poitn is defined for the AD, we can always test NEW protocols for connection, but just not (easily) with the GPL client
• [10:30] Rex Cronon: how hard would it be to code an interface to whatever IM system ll decides to use?
• [10:30] Morgaine Dinova: Infinity: but by keeping it closed, others can't use the same scalable IM back end, and the only eyeballs finding bugs in yours are LL eyeballs ---- which is a tragically short resource.
• [10:30] Dahlia Trimble: could care less what LL™ uses *internally* for group IM, as long as it *works* :)
• [10:30] Infinity Linden: and were I not logged in as Infinity Linden, i would point out the fact that it's much easier to prototype ideas using an open code base than to try to poke us to test things out on one of our dev grids
• [10:30] Infinity Linden: but
• [10:31] Saijanai Kuhn: Morgaine, as far as I can tell, we're not talking about a closed backend except the ported CURRENT system
• [10:31] Infinity Linden: i am logged in as Infinity Linden, so i won't make that observation
• [10:31] Morgaine Dinova: The problem could be solved once and for all, benefitting everybody ... if people weren't so proprietary-minded.
• [10:31] Morgaine Dinova: Hehe
• [10:31] Saijanai Kuhn: Morgaine, Infinity is talking about porting the current IM system as a starting point, not as the real project for scalable IM
• [10:31] Infinity Linden: Morgaine... we have around 80k users peak concurrency at the current time
• [10:32] Infinity Linden: we need to plan for the day when there's 160k
• [10:32] Infinity Linden: (or more)
• [10:32] Lim Catteneo: the only problem with keeping currentback end, is that... its broken :P
• [10:32] Infinity Linden: if you produce an open implementation and present it to the community that can handle that load
• [10:32] Lim Catteneo: group im simply does not work for some groups
• [10:32] Saijanai Kuhn: Science Friday use case is 1 million viewers participating in SF group chat
• [10:32] Infinity Linden: i will personally guarantee you it will be seriously evaluated
• [10:32] Morgaine Dinova: Yes, we hit 80,582, and TPs and logins died so in 2 mins we were back down at 75k
• [10:32] Dahlia Trimble: infinity, any idea what the number may be for the highest concurrent logins for any one group?
• [10:33] Infinity Linden: which is why it's important to have technologies that scale
• [10:33] Lim Catteneo: changing the protocol to LLSD makes no difference when the backend for group im is so choked up it sets of fire alarms ;)
• [10:33] Infinity Linden: @Dalia... hmm... not sure... i'll ask our metrics folks if they can pull that data out of our logs
• [10:33] Saijanai Kuhn: Lim, this isn't what we're proposing
• [10:33] Dahlia Trimble: ty :)
• [10:33] Infinity Linden: @Lim.. yes it does
• [10:34] Saijanai Kuhn: the IIM LLSD thing is just a convenience thing to get the GPL client workign with whatever new IM system is worked out
• [10:34] Infinity Linden: because it allows us to decouple the deployment of the client that uses LLSD IM from any improved server IM implementation
• [10:34] Saijanai Kuhn: its the compatibility layer Morgaine was talking about
• [10:34] Morgaine Dinova: Infinity: 160k is a completely ridiculous figure to design to! The figures of [1] still stand, unless LL has climbed down massively.
• [10:34] Infinity Linden: because IM is not the only service we're going to LLSDify
• [10:35] Saijanai Kuhn: she did say (or more) Morgaine
• [10:35] Morgaine Dinova: That's not massively scalable, that's toying at the edges.
• [10:35] Rex Cronon: if you have 1mill users in group chat, u won't be able to read what people type, the text will scroll too fast
• [10:35] Infinity Linden: anyone remember the bad old days when you had to download a new client each time we pushed out new sim code?
• [10:35] Saijanai Kuhn: Rex that's another issue too
• [10:35] Dahlia Trimble: has to deal with rl... ty all, bye :)
• [10:35] Rex Cronon: bye dahlia
• [10:35] Infinity Linden: @Rex.. well.. hopefully they won't all be in the same channel ;-)
• [10:35] Zha Ewry: skims bnack in chat log
• [10:35] Morgaine Dinova: OK, maybe I got the wrong idea here. I thought the goal was to solve the problem once and for all, not a noddy 200k stopgap.
• [10:36] Lim Catteneo: Rex, true, people have come to a conclusion that chat rooms with more than about 1k online users are impractical and useless
• [10:36] Saijanai Kuhn: Morgaine, I don't think that is what was said...
• [10:36] Morgaine Dinova: reads back
• [10:36] Infinity Linden: Morgaine... the sad truth of large system development is that you tend to do a lot of incremental stop-gaps
• [10:36] Infinity Linden: i've seen that at Linden as well as the phone system
• [10:37] Infinity Linden: there was a time when the 5ESS's couldn't handle one tenth of their current capabilities
• [10:37] Saijanai Kuhn: BUT, with a well-defined connection point, and independent Agent Domains, we can be workiong on multiple stopgap deigns at the same time
• [10:37] Morgaine Dinova: Almost, but not quite: you design for the big picture, you roll out for the needs of today and tomorrow.
• [10:37] Infinity Linden: yet we don't complain that AT&T screwed up in 1972 with SS7
• [10:37] Zha Ewry: You define endpoints and scale design to make ti scale
• [10:37] Morgaine Dinova: Yup
• [10:37] Zha Ewry: No, we do complain a bit that NAN was short sighted
• [10:38] Infinity Linden: ol
• [10:38] Infinity Linden: lol
• [10:38] Infinity Linden: and don't get me started with AIN
• [10:38] Infinity Linden: but
• [10:38] Zha Ewry: mutters at NYC now having what, 7 area codes
• [10:38] Zha Ewry: but anyway
• [10:38] BlueWall Slade: maybe it would be helpful to design in a "near-instant-message" system to handle postings that do not need a reply to group IM?
• [10:38] Zha Ewry: I don't care about people's insddes
• [10:38] Zha Ewry: I care about the interfaces being right
• [10:38] Zha Ewry: so we can compose up as good an inside as you want
• [10:38] Infinity Linden: one key aspect here is that we need to separate the interface from the implementation
• [10:39] Zha Ewry: and allow a mesh of multipel provdiers
• [10:39] Infinity Linden: and... we need to plan to implement something "soon"
• [10:39] Zha Ewry: YES
• [10:39] Infinity Linden: so... given that the XMPP thing was a non-starter
• [10:39] Zha Ewry: because the current doesn't work
• [10:39] Zha Ewry: we all know that
• [10:39] Infinity Linden: what's the OpenSim IM protocol right now?
• [10:40] Morgaine Dinova: So, perhaps we'd better ask ... what numbers are we designing to? Because if it's just a stopgap for the next year then it's a waste of time to set up a project for it. Just keep tinkering. :-)
• [10:40] Zha Ewry: Group IM?
• [10:40] Zha Ewry: Isn't one?
• [10:40] Infinity Linden: um... my point.
• [10:40] Zha Ewry: Design the I/F and scale points
• [10:40] Infinity Linden: we can't move on with IIM
• [10:40] Lim Catteneo: last time i looked opensim didn't implement group im at all
• [10:40] Saijanai Kuhn: Morgaine, as I said, we can have multiple stopgap designs, if we do it right
• [10:40] Zha Ewry: and implement one which works at 200K
• [10:40] Infinity Linden: but
• [10:40] Zha Ewry: and could scale to 1M
• [10:41] Morgaine Dinova: Sai: you may be immortal, but I'm not :-)
• [10:41] Zha Ewry: There's been some chat in side the dev list about gourp IM
• [10:41] Zha Ewry: But nothing in code
• [10:41] Zha Ewry: A lot of people just want to pass an endpoint to jabber
• [10:41] Infinity Linden: if someone actually integrated XMPP with OpenSim, that would be awesum.. for the purposes of investigation
• [10:41] Zha Ewry: once you seperate out the interfaces
• [10:41] Zha Ewry: that's much easier
• [10:41] Infinity Linden: mmm... sending XML fragments around?
• [10:41] Infinity Linden: no thank you
• [10:42] Saijanai Kuhn: goes back to client interface though. Eveyrone wants to use a varioation of the GPL client for full 3D interface
• [10:42] Infinity Linden: it requrires the transport understand appliation layer semantics
• [10:42] Zha Ewry: Well, that's why we're talking about replacing the IIM stuff
• [10:42] Zha Ewry: and right
• [10:42] Infinity Linden: which, IMHO, is one of the reasons it's difficult to scale
• [10:42] Zha Ewry: Crossing OSI layers is always painful and to be avoided when you can
• [10:42] Morgaine Dinova: Well you have to look at the engineering tradeoffs. Just because some of us have an aversion to XML is not a valid reason for dismissing it.
• [10:43] Zha Ewry: Lets do a layer 6.5 design ;-)
• [10:43] Infinity Linden: mm... i might be a little silent about the GPL/{BSD|MIT} license issue
• [10:43] Infinity Linden: Robla's done a lot more deep thinking about it
• [10:43] Infinity Linden: Morgaine.. yes it is, if the people doing the coding are the ones with an aversion to XML
• [10:43] Lim Catteneo: Zha, with current client, you have no choice but to proxy jabber in the sim instance then
• [10:44] Morgaine Dinova: Infinity: I prefer teamwork to the BOFH approach
• [10:44] Infinity Linden: what would be ideal is if there were a plugin interface where we could have the client load IM modules
• [10:44] Lim Catteneo: teams produce COBOL ;)
• [10:44] Zha Ewry: repeats, thats why we want the gahstly IIM out
• [10:44] Lim Catteneo: and CORBA :P
• [10:44] Zha Ewry: makes the sign of Roy Fielding at the mention of CORBA
• [10:45] Infinity Linden: prepares to do battle when people disrespect CORBA
• [10:45] Lim Catteneo: examples of design-by-comittee
• [10:45] Infinity Linden: well... that's the truth though
• [10:45] Zha Ewry: So.. two very seperable issues
• [10:45] Morgaine Dinova: Talking of REST, I assume we're going for a service architecture for IM, even if it's stuck in the AD, right?
• [10:45] Zha Ewry: We need to get the endpoints cleaned up
• [10:45] Infinity Linden: though committee members tended to be attractive, intelligent and popular
• [10:45] Infinity Linden: (Zha and I were both on different CORBA committees)
• [10:46] Zha Ewry: and we need to define the basic ways that groups get handled
• [10:46] Lim Catteneo: loses a bit of respect for both :P
• [10:46] Zha Ewry: so *anyone* can build a servcie which conforms
• [10:46] Zha Ewry: laughs
• [10:46] Morgaine Dinova: Zha: service arch for IM?
• [10:46] Zha Ewry: Oh, it gets worse
• [10:46] Zha Ewry: and, yes, Service Oriented please
• [10:46] Zha Ewry: Something Duncan Cragg will like
• [10:47] Infinity Linden: Lim... hey... we tried... and i'll stack CORBA up against DCOM any day
• [10:47] Infinity Linden: ack
• [10:47] Infinity Linden: SOA?
• [10:47] Zha Ewry: has at variosu times done OMG, W3C, JCP, OASIS and IETF work
• [10:47] Lim Catteneo: its like saying plague is better than collera :P
• [10:47] Infinity Linden: mm... there seems to be a disconnect between the hard-core REST folks and the SOA folks these days
• [10:47] Morgaine Dinova: I'll stack specific technology advocates up in a heap, and light the match :-)
• [10:48] Infinity Linden: i suspect it might just be a community thing.. it seems like the SOA crowd are more into process than the RESTafarians
• [10:48] Zha Ewry: Well, until you've actuall shipped a product built around an interoperabel standard, and had it worked against another companies implementation
• [10:48] Zha Ewry: don't get too cocky
• [10:48] Infinity Linden: but that's totally an informal observation
• [10:48] Infinity Linden: lol
• [10:49] Zha Ewry: ANYWAY
• [10:49] Infinity Linden: mumbles something about 14 months, 5 major product releases on time and under budget
• [10:49] Zha Ewry: I see three or so projects
• [10:49] Lim Catteneo: Infinity, is there appetite at the Lab to allow client to connect to more than one service. Ie. abandon current way of having sim be the grand proxy?
• [10:49] Infinity Linden: ANYWAY
• [10:49] Zha Ewry: Three or so specific things needed to make it work
• [10:49] Saijanai Kuhn: Lim that's the AD goal
• [10:49] Zha Ewry: IIM->Caps
• [10:49] Infinity Linden: @Lim... i think we have an appetite to design interfaces that would allow that
• [10:49] Infinity Linden: but
• [10:49] Infinity Linden: don't plan on it in the near term
• [10:50] Zha Ewry: A good spec for what a servicr provider does to get notified of people going on an offline
• [10:50] Infinity Linden: of course... like everything else at the Lab... that could change at the end of the month
• [10:50] Morgaine Dinova: OK, so do we have a REST-like outline for how IM will look in mind?
• [10:50] Zha Ewry: and a good spec for how ti ties into the an Agent Service (which might reside in an AD)
• [10:50] Morgaine Dinova: Or does Sai have to get his whiteboard out ...
• [10:50] Infinity Linden: (for the record.. i'm referencing the "we're releasing our grand open strategy" at the end of the month.
• [10:51] Morgaine Dinova: kk Infi, I guess we'll have to wait
• [10:51] Infinity Linden: there was a memo that was leaked about LLSD/LLIDL IM
• [10:51] Lim Catteneo: IDL? img
• [10:51] Lim Catteneo: as in corbaesque IDL? :P
• [10:51] Infinity Linden: nah. it's really an abstract type system, not an IDL
• [10:52] Zha Ewry: As in the LLIDL which was used to describe the OGP
• [10:52] Zha Ewry: far from an IDL with semantics
• [10:52] Morgaine Dinova: That defines the bodies of REST messages, right?
• [10:52] Infinity Linden: but we figured people thinking we were trying to reinvent CORBA IDL was better than people thinking we were trying to reinvent ASN.1
• [10:52] Lim Catteneo: lol
• [10:52] Infinity Linden: and Zero liked the idea that LLIDL could be pronounced "little"
• [10:53] Infinity Linden: So don't try reading too much into it
• [10:53] Zha Ewry: So Infinity?
• [10:53] Morgaine Dinova: So does LLSD/LLIDL define the bodies of RESR messages or not? Ie. no verbs.
• [10:53] Morgaine Dinova: REST*
• [10:54] Infinity Linden: btw... LLIDL is documented at [2]
• [10:54] Zha Ewry: Do we have any serious thought about how the IIM stuff gets migrated out?
• [10:54] Zha Ewry: and.. yes, it doesn't attempt to do semantics
• [10:54] Infinity Linden: right. application layer verbs are implied in the resource access
• [10:54] Saijanai Kuhn: its just a translation of the current binary packets into XML or xml compatible
• [10:54] Infinity Linden: transport layer verbs are explicitly noted in the spec
• [10:55] Infinity Linden: right. no semantics or policy defined
• [10:55] Zha Ewry: I *think* between Zero, Infinity and Myself, you'll find a pretty strong aversion to verbs in content
• [10:55] Zha Ewry: We have our verbs
• [10:55] Zha Ewry: GET/PUT/POST
• [10:55] Infinity Linden: i won't speak for Zero, but i will agree with that
• [10:55] Infinity Linden: actually we're thinking we're not even going to specify anything with a PUT
• [10:55] Zha Ewry: The IDL tells us how to forma up the resoruces
• [10:55] Zha Ewry: nods
• [10:56] Infinity Linden: right. nothing too much more than that
• [10:56] Infinity Linden: so... no IDL compiler... no stubs to link in with your code
• [10:56] Zha Ewry: I can make a case for PUTs in some places, but... get/POST works for me
• [10:56] Infinity Linden: i mean... you could do that if you wanted
• [10:56] Lim Catteneo: yeah leaving it to get/post make implementation easier
• [10:56] Infinity Linden: but
• [10:56] Infinity Linden: there's no requirement for it
• [10:56] Morgaine Dinova: Cool. So, we've got the REST envelopes, we've got the contents of messages defined (at an early stage), now where are the nouns? Ie. do we know what resources we're manipulating?
• [10:56] Infinity Linden: @Lim... yeah. that's what we were thinking too
• [10:57] Infinity Linden: the nouns are defined in the LLIDL of the resource description
• [10:57] Lim Catteneo: likes the goal of eventually being able to do with javascripts's httpRequest :)
• [10:57] Zha Ewry: Wihich we hopefully
• [10:57] Zha Ewry: derive from cleaning up the IIM stuff
• [10:57] Morgaine Dinova: Which doc is that in?
• [10:58] Morgaine Dinova: checks last link
• [10:58] Infinity Linden: @Lim... you and me both... /me is a JavaScript fan
• [10:58] Lim Catteneo: Infinity, does movement of IIM to CAPS imply modification of the packet itself, or just change of the way its delivered?
• [10:58] Zha Ewry: hopefully both
• [10:58] Zha Ewry: IIM is badly overloaded
• [10:58] Infinity Linden: hmm.. this would be easier if everyone had the leaked memo
• [10:58] Infinity Linden: lemme go try to get approval to re-leak it
• [10:59] Saijanai Kuhn: at first, justy the delivery I would think
• [10:59] Zha Ewry: looks for her copy
• [10:59] Lim Catteneo: someone leak me the memo :P
• [10:59] Saijanai Kuhn: notecard i groupies?
• [10:59] Morgaine Dinova: That link is just serialization, looking further back
• [10:59] Infinity Linden: if you've got a copy of it.. sure
• [11:00] Infinity Linden: right... look at [3] as an example of how to define nouns with LLIDL
• [11:00] Infinity Linden: and
• [11:00] Morgaine Dinova: Ta
• [11:00] Infinity Linden: the leaked IM discussion memo
• [11:00] Infinity Linden: has the nouns for IM
• [11:01] Infinity Linden: that was effectively taking some of data from teh IIM packet and OGPifying it
• [11:01] Infinity Linden: krunk
• [11:01] Infinity Linden: i gotta run to a meeting
• [11:01] Saijanai Kuhn: @ Infinity adn Morgaine: seems to me that just because we're using IIM for the GPL client, doesn't mean we can't start experimenting with better factored messages on the non-GPL client, and once those become matjure, bring them back into the gPL CLIENT
• [11:01] Rex Cronon: me too. bye infinity
• [11:01] Saijanai Kuhn: hates caps lock
• [11:01] Rex Cronon: bye everybody
• [11:01] Morgaine Dinova: Cya Infi
• [11:02] Morgaine Dinova: Cya Rex
• [11:02] Rex Cronon: tc
• [11:02] Infinity Linden: right. and i'm hoping to be able to release a protocol tester after the end of this month
• [11:02] Infinity Linden: so
• [11:02] Infinity Linden: we'll have something to test any such implementation against
• [11:02] Infinity Linden: cheers all
• [11:02] Saijanai Kuhn: INfinity hoping to get a wireshark like facility in pyogop. Are we duplicating effort here?
• [11:02] Morgaine Dinova: Indeed Sai --- that's why I was querying to see how close we are to having a REST interface usable with IM.
• [11:03] Zha Ewry: mutters
• [11:04] Zha Ewry: I know I've seen that leaked copy
• [11:04] Saijanai Kuhn: that would be the IIM XML-LLSD CAP as a first pass for ta REST interface, I think, Morgaine
• [11:04] Zha Ewry: looks at the time
• [11:04] Zha Ewry: Its after 11:00
• [11:04] Saijanai Kuhn: it also lets us play with OTHER REST interfaces for other non-LL services once that is defined
• [11:04] Goldie Katsu: nods
• [11:04] Zha Ewry: Saij.. can you turn off the recorder?
• [11:04] Morgaine Dinova: It would require LL to interface their prototype REST-based IM service into the live one though. Then we could tack on using the REST interface as an alternative to the current IM interface.
• [11:04] Saijanai Kuhn: falls asleep again