User:Which Linden/Office Hours/2007 Dec 7

Transcript of Which Linden's office hours:

[11:02]	Which Linden:	all right, I'm ready to start if you are
[11:03]	Head Replacement:	Hi!
[11:03]	Which Linden:	English really needs a pronoun for "you plural" besides 'y'all'
[11:03]	Which Linden:	hey head
[11:03]	Head Replacement:	(Tao here, LL does not want Tao to login atm)
[11:03]	Which Linden:	what'd you do, man?
[11:03]	Saijanai Kuhn:	Y'all is perfect adequate. The alternative is Youse
[11:04]	Head Replacement:	what is the reason for "you cannot login before 11:10:22" btw?
[11:04]	aliceinwire Bleac:	Halllooooo
[11:04]	aliceinwire Bleac:	which
[11:04]	Head Replacement:	it's sort of annoying  ;-)
[11:04]	Which Linden:	How do you pronounce youse? Like louse, or like lose?
[11:04]	Saijanai Kuhn:	BTW, "ain't " used to be a semi-acceptable contraction of "am not"
[11:04]	Saijanai Kuhn:	use I think
[11:04]	Which Linden:	:-)
[11:04]	Harleen Gretzky:	more like "use"
[11:04]	Saijanai Kuhn:	as in it is for your use
[11:05]	Saijanai Kuhn:	not use it or loose it
[11:05]	Which Linden:	hm
[11:05]	Which Linden:	OK, well, I declare these office hours open!
[11:05]	Saijanai Kuhn:	could be yooze I guess
[11:05]	aliceinwire Bleac:	:D
[11:05]	Saijanai Kuhn:	as in youse guys
[11:05]	Which Linden:	I have two topics, we could do both or just one
[11:06]	Saijanai Kuhn:	English R fun
[11:06]	Head Replacement:	and I try with Tao again, I think it was 11:04 what it said
[11:06]	Head Replacement:	or maybe 12:04  ;-)
[11:06]	Saijanai Kuhn:	google gives local time. The wiki gives SL time
[11:06]	Head Replacement:	I mean when I am allowed to login again
[11:06]	Head Replacement:	this certainly was SLT
[11:07]	Which Linden:	one thing we could talk about is doing deferred deletes in chttp
[11:07]	Head Replacement:	Which: not sure you read it but I created my own basic caps server and started to work on login for the new arch
[11:08]	Which Linden:	ah, cool, how's that working out for ya?
[11:08]	Head Replacement:	well, I am missing the transcript of one Zero OH to be sure  ;-)
[11:08]	Head Replacement:	he gave some examples
[11:08]	Head Replacement:	so I am not sure about syntax and such
[11:08]	Wyn Galbraith:	Hey Squirrel!
[11:08]	Head Replacement:	and my caps server is quite simple. one register url to register a new caps and then you call it and it acts as proxy
[11:08]	Head Replacement:	http://pysecondlife.googlecode.com/svn/trunk/
[11:08]	Saijanai Kuhn:	the source for the RC 6 client is not online yet, so I can't document how to get the client-login info
[11:09]	Which Linden:	I am afraid I have little visibility into login stuff, Head, so it's probably not a great topic
[11:09]	Morgaine Dinova:	And your second topic, Which?
[11:09]	Which Linden:	ugh, yes, thanks for sending the email to sldev, Sai
[11:09]	Which Linden:	The other topic is the escrow design
[11:09]	Which Linden:	One question I'm trying to tackle is whether 'shuffle' is a sufficient model
[11:09]	Head Replacement:	no problem.. just still waiting for the LL caps server  ;)
[11:10]	Which Linden:	Yeah, let's talk about shuffle, you all are probably interested in this
[11:10]	Saijanai Kuhn:	Donovan said he would try to get a version of tha topen sourced for us
[11:10]	Morgaine Dinova:	Cool
[11:10]	Which Linden:	So, let me present the shuffle question to you all, then we can discuss it
[11:10]	Head Replacement:	everybody said that, I am just wondering when so I can get rid of mine  ;-)
[11:10]	Head Replacement:	anyway, ask the shuffle question  :)
[11:11]	Which Linden:	The current design of the escrow involves a gather phase and a distribution phase
[11:11]	Which Linden:	Each phase has a mapping of owners to resources
[11:11]	Which Linden:	And the escrow simply does the translation from the initial mapping to the final mapping
[11:12]	Which Linden:	I've writtend up a bunch of use cases here: http://wiki.secondlife.com/wiki/Certified_HTTP_Escrow#Current_Use_Cases
[11:12]	Which Linden:	I put out a call for more use cases, cause all the current ones can be shuffles
[11:13]	Which Linden:	The one tricky use case, that may not be a shuffle, is group balance payout
[11:14]	Which Linden:	That is the case where the group has a balance, M, and you have K members to receive it. Each member gets (M div K) and the group's balance is decremented by K*(M div K)
[11:15]	Which Linden:	So, that's the problem, can we make that into a shuffle?
[11:15]	Which Linden:	It seems there is a race condition
[11:16]	Morgaine Dinova:	Is one of those use cases on your page, group balance payout?
[11:16]	Which Linden:	Before you start the transaction, you'll have to do all the M div K work yourself, and if M decreases in the meantime, the transaction will fail
[11:17]	Which Linden:	I don't think it's on the page, Morgaine
[11:17]	Morgaine Dinova:	kk
[11:17]	Head Replacement:	so you might need to somehow take it from the group first?
[11:17]	Saijanai Kuhn:	You're now linked to the AW Groupies page https://wiki.secondlife.com/wiki/AW_Groupies#Communications
[11:17]	Which Linden:	Yeah, but you kinda want to a) leave all the transactional semantics to the escrow
[11:18]	Which Linden:	and b) not have specific knowledge about the semantics of a particular operation in the code of the escrow itself
[11:18]	Head Replacement:	you mean the div, I guess
[11:18]	Which Linden:	Right, you don't want the escrow to know about that
[11:18]	Morgaine Dinova:	But isn't the withdrawal atomic as part of the "garhering resources" phase?
[11:19]	Morgaine Dinova:	Piecemeal rollback would be a nightmare
[11:19]	Which Linden:	Yes, it is.
[11:19]	Head Replacement:	can't you maybe give the escrow a group of actions surrounded by some action?
[11:20]	Which Linden:	in this example what would be the surrounding action?
[11:20]	Gigs Taggart waves
[11:20]	Head Replacement:	well, one action might be get amount X from A
[11:20]	Head Replacement:	cya Gigs!
[11:20]	Which Linden:	bye gigs
[11:20]	Head Replacement:	and then you have an additional list for distribution
[11:20]	Morgaine Dinova:	Well M can't decrease "in the meantime" if withdrawal is atomic.
[11:20]	aliceinwire Bleac:	random number < m for random user of the group
[11:20]	aliceinwire Bleac:	when it reach m stops
[11:21]	Head Replacement:	so distribution is a list of L$ -> av1, L$ -> av2 and so on
[11:21]	Head Replacement:	but I only scanned the page  ;-)
[11:21]	aliceinwire Bleac:	in random mode i think
[11:22]	Which Linden:	Ah, but the determination of how large M is, is not atomic with the withdrawal
[11:22]	Head Replacement:	ah right, because you compute it a little bit earlier than you call the escrow
[11:22]	Morgaine Dinova:	M can't decrease during the div, because resources were acquired atomically first. There is nothing to div, until the atomic withdrawal.
[11:22]	Head Replacement:	but then the only chance is to div in the escrow, isn't it?
[11:22]	Head Replacement:	if this is where it's atomic
[11:23]	Which Linden:	Morgaine: but only the escrow can acquire, and we don't want the escrow to do the div  :-(
[11:23]	Head Replacement:	or isn't it?  :)
[11:23]	Which Linden:	yeah, it does seem to be a quandary
[11:23]	Head Replacement:	well, if it acquires then it is
[11:23]	Head Replacement:	at least it cannot decrease
[11:23]	Head Replacement:	but if you do the div before you give it to the escrow
[11:23]	Which Linden:	I was thinking of ducking it by just acquiring J < M and retrying with a smaller J if it doesn't work
[11:24]	Head Replacement:	it might fail then
[11:24]	Morgaine Dinova:	Well escrows don't actually do the withdrawal, they performs a callback defined for the escrow type.
[11:24]	Head Replacement:	but then you might know why
[11:24]	Head Replacement:	and you can try again
[11:24]	Morgaine Dinova:	Sorry, typo
[11:24]	Which Linden:	ah, Morgaine, you might be right there
[11:24]	Morgaine Dinova:	Well escrows don't actually do the DIVl, they performs a callback defined for the escrow type.
[11:24]	Morgaine Dinova:	But the escrow does the atomic withdrawal ... that's part of gatheriing resources.
[11:25]	Which Linden:	You'd have to have a resource that is "the entire balance"
[11:25]	Head Replacement:	well, withdrawl needs to be atomic in any case
[11:25]	Head Replacement:	it's just that the escrow temporarily owns the money then
[11:25]	Which Linden:	Yup
[11:26]	Morgaine Dinova:	Which: where were you attaching the functional semantics in each escrow use case?
[11:26]	Head Replacement:	or just remove paying group members from the SL feature list  ;-)
[11:26]	Which Linden:	Morgaine: I wasn't. I just wanted to see if we could get anywhere
[11:26]	Head Replacement:	so where would your retrying occur?
[11:26]	Head Replacement:	in the escrow?
[11:27]	Head Replacement:	I guess not
[11:27]	Which Linden:	Actually, here's a dumbass question: how can the group balance decrease? Do officers have the right to dip into the till?
[11:27]	Head Replacement:	if not we might have had the same idea
[11:27]	Head Replacement:	no idea, I am still waiting for mine to increase  ;-)
[11:27]	Which Linden:	I was thinking the retrying would have to happen outside the escrow
[11:27]	Head Replacement:	but couldn't decrease for e.g. land fees?
[11:27]	Which Linden:	Oh, yeah, of course
[11:28]	Which Linden:	That's one of my use cases that's not on the wiki pages yet
[11:28]	Morgaine Dinova:	Aha. OK, well presumably there is only one implementation of the escrow service mechanism, but it's generic. So, it needs to be given a function (as in higher order functions) to be invoked for each member of the "gather resources" set, and a subsequent function to be applied to the gathered resources. (Designing by the seat of pants here)
[11:28]	Which Linden:	yeah
[11:28]	Which Linden:	I was thinking of splitting up the functions by resource type
[11:28]	Head Replacement:	the basic question is how extensible an escrow should be
[11:28]	Head Replacement:	and if you can register new ones
[11:29]	Which Linden:	I think it should be really extensible
[11:29]	Which Linden:	Though the more extensible you get, the less goes into the core
[11:30]	Head Replacement:	from secondlife.escrow.core import *
[11:30]	Morgaine Dinova:	I don't usually think in terms of higher order function (though I should from background), but this looks like a rather good match.
[11:30]	Which Linden:	functions that return functions?
[11:30]	Head Replacement:	escrow_resources = getUtilities(IEscrowResourceType)
[11:30]	Head Replacement:	finished  ;-)
[11:31]	Which Linden:	oh, yeah, there's tons of ways to accomplish that sort of thing in Python
[11:31]	Head Replacement:	for me it's just unkown where those escrows actually sit
[11:31]	Which Linden:	My initial thought was that each resource type should have three functions: Gather, Distribute, and Undo
[11:31]	Head Replacement:	and how they are called
[11:31]	Morgaine Dinova:	In this case, functions passed forward into the escrow, to be invoked later, eg. at time of gathering resources, and a different one at time of dealing with the resources (div + distribut in this case)
[11:32]	Which Linden:	Ah, I see. A callback
[11:32]	Which Linden:	Or a hook
[11:32]	Which Linden:	Yeah, that would work!
[11:32]	Which Linden:	Just insert the hook in the middle there.
[11:33]	Which Linden:	It would basically be a resource converter
[11:33]	Head Replacement:	ok, so the escrow is a server and you send some REST with what to do to it?
[11:33]	Which Linden:	Head: yeah, I have sort of a design, one sec.
[11:33]	Morgaine Dinova:	Well, in low level languages, yes, just a function pointer. But if it's a more capable language, then any function, including anonymous ones created from closure of the lexical environment. But if using C/C++, then the latter isn't really easy to do.
[11:34]	Morgaine Dinova:	So yeah, callbacks will suffice.
[11:34]	Head Replacement:	What about "Give no-copy object"?
[11:34]	Which Linden:	The REST API for the escrow would be something like this: {'gather':[ {'owner':foo, 'type':'L$', 'value':10}], 'distribute':[{'owner':bar, 'type':'L$', 'value':10}]}
[11:35]	Head Replacement:	so, don't these extensions eventually need more parameters?
[11:35]	Which Linden:	yeah, that could be all in the 'value' parameter
[11:35]	Morgaine Dinova:	Head: that's a pretty easy one, because the object disappears from originator inventory during gather.
[11:35]	Head Replacement:	I was just missing it from the list  :-)
[11:35]	Which Linden:	yeah, you could have a special resource type for it
[11:35]	Which Linden:	oh, right, thanks for the reminder, I'll add it
[11:35]	Head Replacement:	and if you do that where would that escrow server reside?
[11:36]	Head Replacement:	on agent domain of host A or B?  :)
[11:36]	Head Replacement:	or somewhere else
[11:36]	Which Linden:	could be anywhere, doesn't matter
[11:37]	Head Replacement:	but I thought the thing is that you need to trust it
[11:37]	Morgaine Dinova:	It's important that it must be able to run anywhere ... interop means that the parties concerned may not all be in same grid, so transactions need to go through the interop gateways.
[11:38]	Which Linden:	so the group payout would look something like this: {'gather':[{'owner':group, 'type':'entire-balance', 'value':()}], 'distribute':[{'owner':member_a, 'type':'L$', 'value':. ..... uh... hm
[11:38]	Which Linden:	still requiring it to be explicitly specified
[11:39]	Morgaine Dinova:	IM needs <pre>  :-)
[11:39]	Which Linden:	well, ok, we just name them
[11:39]	Head Replacement:	type:multi_L$, value: [av1,av2,av3]
[11:40]	Which Linden:	restating the first case, with names: {'gather':[ {'owner':foo, 'type':'L$', 'value':10, 'name':'gift'}], 'distribute':[{'owner':bar, 'name':'gift'}]}
[11:40]	Which Linden:	Head: Oh, hm, yeah
[11:40]	Which Linden:	I guess that would work
[11:40]	Morgaine Dinova:	Wheres the residue?
[11:40]	Head Replacement:	and multi might know about the div
[11:40]	Which Linden:	the residue has to go back to the group
[11:41]	Head Replacement:	but then you need to have div implemented
[11:41]	Which Linden:	so, it can be listed as a recipient as well
[11:41]	Which Linden:	but that's ok if the div is implemented in the Gather and Distribute methods of the 'multi_L$' resource type
[11:41]	Which Linden:	that's what the resource types are for
[11:41]	Head Replacement:	then of course you need to be able to know what resource types are supported
[11:41]	Morgaine Dinova:	important to have the residue made explicit. You don't want to get into fraud investigation waters  :-)
[11:42]	Morgaine Dinova:	Even if fractions of a Linden. They mount up, hehe
[11:42]	Morgaine Dinova:	Not that we have fractions here, but other grids might
[11:42]	Head Replacement:	other grids might have something different than L$
[11:42]	Which Linden:	Actually I'll be transferring all residue to my alt's account, Office Space style.  :-)
[11:42]	Head Replacement:	like Tao$
[11:42]	Morgaine Dinova:	Hehehe
[11:43]	Head Replacement:	I am glad all this is logged  ;-)
[11:43]	Wyn Galbraith:	Other grids might have cents. :D
[11:43]	Head Replacement:	we might use it against Which someday  ;-)
[11:44]	Morgaine Dinova:	lol
[11:44]	Head Replacement:	for sharing residue with us for instance
[11:44]	Which Linden:	Ha ha
[11:44]	Morgaine Dinova wipes the residue off her skirt
[11:44]	Wyn Galbraith:	LOL
[11:45]	Morgaine Dinova:	I'm not sure what that meant, better not analyse it  ;-)
[11:45]	Head Replacement:	btw, I don't get what the two code snippets on the page are
[11:45]	Head Replacement:	what do you provide when?
[11:46]	Wyn Galbraith:	Sure that's not dust?
[11:47]	Which Linden:	So, reworking the example again: {'gather':[{'owner':group, 'type':'multi_L$', 'value':([a1, a2, a3])}], 'distribute':[{'owner':a1, 'type':'multi_L$', 'value':'member'}, ... , {'owner':group, 'type':'multi_L$', 'value':'residue'}]}
[11:47]	Which Linden:	god that took a long time to type
[11:47]	Head Replacement:	chat here needs python syntax completion
[11:47]	Which Linden:	frikkin undo would be nice
[11:47]	Wyn Galbraith:	LOL Which!
[11:48]	Head Replacement:	geeks don't need undo  ;-)
[11:48]	Which Linden:	they just upload their source to an ftp server and... hm
[11:48]	Which Linden:	oh, so about the code on the escrow page... that hasn't been updated in a long time
[11:48]	Morgaine Dinova:	I'm a quiche eater, I need undo.
[11:49]	Head Replacement:	so I don't get that line you just pasted  ;-)
[11:49]	Wyn Galbraith is a sushi eater and likes it raw.
[11:49]	Which Linden:	I think those were for pre-defined transactions, which I believe should be moved out of the escrow and into an escrow front-end or something
[11:49]	Head Replacement:	a1..a3 are avatars?
[11:49]	Which Linden:	yeah
[11:49]	Head Replacement:	so what is gather doing now?
[11:49]	Which Linden:	oh, actually the group doesn't need to be in the recipients
[11:50]	Which Linden:	gather will just do K = len(value)
[11:50]	Head Replacement:	I think I have a problem with what that syntax means  ;-)
[11:50]	Which Linden:	Feel free to invent a better one  :-)
[11:50]	Head Replacement:	ah, so if you call gather() on multi_L$ then it knows to do div?
[11:50]	Which Linden:	yeah
[11:50]	Which Linden:	that's the idea
[11:51]	Head Replacement:	ok
[11:51]	Which Linden:	oh, but there's a flaw, I think
[11:51]	Morgaine Dinova:	Is anyone else having issues cut'n'pasting between SL and Linux xterms? Works between Firefox and SL for me, but not to/from xterms.
[11:51]	Head Replacement:	so you sort of need an instance then to store the result I guess but you need an instance anyway to store the stuff gathered
[11:51]	Which Linden:	the flaw is that the number of gathered resources is not equal to the number of distributed resources
[11:51]	Head Replacement:	can you have different resource types in gather and distribute?
[11:52]	Which Linden:	Head: uh, if you do, you need a converter
[11:52]	Which Linden:	in which case you need names
[11:52]	Head Replacement:	or you create a new resource type for it
[11:52]	Morgaine Dinova:	Which: those are two sets which may overlap fully, not at all, or in between
[11:52]	Which Linden:	Morgaine: it does mean that the escrow needs to know how to split up the one resource gathered from the group
[11:52]	Head Replacement:	and if the type is always the same and you always call gather and distribute then the question is why you need to give it in the syntax  ;-)
[11:53]	Morgaine Dinova:	Which: the escrow doesn't need to know ... it just calls the callback for that escrow instance
[11:53]	Which Linden:	Ah, right, OK, I thought we could get away without the callback
[11:53]	Head Replacement:	then it could be {'type':'multi_L$','group':'blabla','members':[a1,a2,a3]}
[11:54]	Morgaine Dinova:	And the gather set is part of the input to that 2nd callback too.
[11:54]	Head Replacement:	I don't get the callback part  ;-)
[11:54]	Morgaine Dinova:	Which: well sure, you could get away without callbacks ... but then you would have to implement escrow code dozens of times.
[11:54]	Head Replacement:	can't they be just functions of some plugin?
[11:54]	Which Linden:	callback, function of plugin, same thing
[11:55]	Which Linden:	Seep and I were talking about this, and we called the callback 'conserve'
[11:55]	Which Linden:	since it has to conserve resources
[11:55]	Morgaine Dinova:	Head: the functions could be in that plugin, but the escrow code wouldn't --- it's generic.
[11:55]	Head Replacement:	we might need to define what the actual escrow does and what those plugins
[11:55]	Head Replacement:	the escrow of course does all the handling of incoming commands
[11:56]	Which Linden:	right, and all the persisting of state, and so on
[11:56]	Head Replacement:	it knows about it's open transactions
[11:56]	Head Replacement:	and the rest is done by the plugins?
[11:56]	Morgaine Dinova:	You really don't want to rewrite the very critical escrow code multiple times, for all escrow types, each with their corner cases. Do it once, reliably, and then pass in the gather and process functions.
[11:56]	Which Linden:	Morgaine: agreed
[11:57]	Head Replacement:	I think if resource types for gather and distribute are the same then we actually don't need gather and distribute
[11:57]	Head Replacement:	and the plugin instance can store data it needs
[11:57]	Head Replacement:	if they are different then some other instance needs to store that data
[11:58]	Morgaine Dinova:	Head: gather output is an input to distribute
[11:58]	Which Linden:	Head: the thing you need, though, is the assignment of owners in the distribute phase
[11:58]	Which Linden:	and what Morgaine said
[11:58]	Head Replacement:	what are the owners good for, or: what does the escrow itself need to know about the owners?
[11:59]	Head Replacement:	well, if both gather() and distribute() are in one function process() then this function in itself can use what it gathered for distributing
[11:59]	Which Linden:	heh, if it doesn't know about the owners, it doesn't have much to know about at all
[11:59]	Head Replacement:	what is an owner anyway?  ;-)
[11:59]	Which Linden:	The escrow needs to know when the gathering is done
[11:59]	Head Replacement:	for what?  :)
[12:00]	Head Replacement:	for calling distribute?
[12:00]	Morgaine Dinova:	Well escrow doesn't need to know what the "owners" are ... they're just members in a set involved in escrow. Could be anything. Objects with their own wallets for instance (not in current SL).
[12:00]	Which Linden:	Because if something fails it has to undo
[12:00]	Head Replacement:	ok, but undo is probably part of the plugin again
[12:00]	Head Replacement:	or resource type
[12:00]	Which Linden:	The escrow should just be pulling the string of the plugins
[12:00]	Morgaine Dinova:	Which: yep
[12:01]	Head Replacement:	so if it's all in one plugin anyway, then this could be done automatically without 2 calls
[12:01]	Which Linden:	So they do all the work, but the escrow's job is to make sure that the transactional semantics cross-plugin are maintained
[12:01]	Morgaine Dinova:	Head: no, it's two phases.
[12:01]	Head Replacement:	ok, so it's more or less about different resource types for gather and distribute then
[12:02]	Which Linden:	It's more about: each resource might be on a different host
[12:02]	Which Linden:	So you have to be pretty delicate about acquiring them
[12:02]	Head Replacement:	and who is acquiring it?
[12:02]	Which Linden:	The escrow, via the plugins
[12:02]	Head Replacement:	ok, so everything is in the plugins  ;-)
[12:02]	Morgaine Dinova:	No, Head
[12:02]	Morgaine Dinova:	Plugins only contain code
[12:03]	Head Replacement:	I need paper  ;-)
[12:03]	Which Linden:	Not everything, but yeah, a lot of nitty-gritty code will be in those plugins.
[12:03]	Which Linden:	There's no helpng it.
[12:03]	Which Linden:	I think the phrase is "business logic"
[12:03]	Morgaine Dinova:	Hehe
[12:03]	Head Replacement:	if all the escrow does is try: data=plugin.gather(); except: plugin.undo(); else: plugin.distribute(data)
[12:03]	Head Replacement:	then this could be in the plugin too if it's the same for both phases
[12:04]	Head Replacement:	it might be different if plugin for gather() and distr() are different ones
[12:04]	Head Replacement:	but then you might need some conversion
[12:04]	Which Linden:	Oooh, no, it goes: for x in resources: try: x.gather except: fail
[12:05]	Which Linden:	where fail is: for x in resources_gathered_already: x.undo
[12:05]	Morgaine Dinova:	Head: you really don't want that logic spread all over the place. The instances will diverge.
[12:05]	Which Linden:	Maybe it'll be clearer once there's some code
[12:05]	Head Replacement:	ok, maybe I understand now: you can have different resource types in the gathering phase
[12:05]	Which Linden:	Yep
[12:05]	Head Replacement:	so that group stuff is misleading here
[12:05]	Which Linden:	Yeah, the group example is an extreme corner case
[12:06]	Which Linden:	The most common operation will be buying an object, which has two resource types
[12:06]	Head Replacement:	ok, so where is data stored then?
[12:06]	Head Replacement:	you have one data instance per resource type?
[12:06]	Which Linden:	yeah
[12:06]	Head Replacement:	and is the data instance the same as the plugin instance?
[12:07]	Which Linden:	uh, probably not
[12:07]	Head Replacement:	(or just a dict=
[12:07]	Head Replacement:	)
[12:07]	Morgaine Dinova:	Head: yep, escrow doesn't know about groups. It doesn't know about any semantic connection between parties to the escrow at all. In fact, two parties may even be one and the same (not thought about that).
[12:07]	Which Linden:	the plugin is probably just a set of functions
[12:07]	Head Replacement:	I know that it does not know about anything  :-)
[12:07]	Morgaine Dinova:	Hehe
[12:07]	Head Replacement:	the plugin could be a class aswell and store what it gathers
[12:07]	Head Replacement:	maybe  ;-)
[12:08]	Head Replacement:	so where is stuff stored then?
[12:08]	Which Linden:	I think the escrow should store it
[12:08]	Which Linden:	Treating it as opaque data
[12:08]	Morgaine Dinova:	That's up to the implementation of escrow. Where is not visible from outside.
[12:08]	Head Replacement:	ok, so a dict  :)
[12:08]	Which Linden:	It just knows about identity.
[12:08]	Head Replacement:	(as an example)
[12:08]	Head Replacement:	probably more so some database
[12:08]	Which Linden:	Heh, yeah.  :-)
[12:09]	Which Linden:	If you look at our code we've been pickling stuff into the database
[12:09]	Saijanai Kuhn:	doh the folder IM seems to have died
[12:09]	Head Replacement would use ZODB for that  ;-)
[12:09]	Which Linden:	Anyhow, this has been a great discussion, but I have to wrap it up
[12:09]	Head Replacement:	and BTrees
[12:09]	Morgaine Dinova:	I wonder how pickling speed compared with JSON for the JSON types.
[12:10]	Head Replacement:	depends on implementation  ;-)
[12:10]	Head Replacement:	pickling might be C
[12:10]	Which Linden:	Dunno! We are using cPickle, so, hopefully it's fast
[12:10]	Head Replacement:	so it is C
[12:10]	Head Replacement:	not sure how simplejson etc. works
[12:10]	Morgaine Dinova:	Python's JSON is very fast, nearly as fast as Ruby's.
[12:10]	Which Linden:	I think simplejson might be c as well
[12:10]	Morgaine Dinova:	Simple is pretty slow
[12:10]	Head Replacement:	so who does know more about login then?
[12:10]	Which Linden:	But it has limitations to what it can store
[12:11]	Head Replacement:	I think storage is up to the implementation anyway
[12:11]	Which Linden:	Head: Tess, Donovan, Zero (I think)
[12:11]	Which Linden:	actually Zero might not know much
[12:11]	Head Replacement:	ok, missed Zero's OH...
[12:11]	Head Replacement:	hope he is well again
[12:11]	Saijanai Kuhn:	Which we've been trying to bypass Groupie group IM because it is so buggie.
[12:11]	Morgaine Dinova:	Zero suggested we try to summon Tess anyway today, hehe.
[12:11]	Saijanai Kuhn:	Buggy*
[12:11]	Head Replacement:	might work on login then for myself from my fantasy  ;-)
[12:11]	Which Linden:	I cast. .... Summon Tess!
[12:11]	Morgaine Dinova:	LOL
[12:11]	Saijanai Kuhn:	WHich requires a calling card. Do you want to lurk on our emergency group IM?
[12:12]	Which Linden:	Sai: how does that work? Just a conference IM?
[12:12]	Saijanai Kuhn:	right
[12:12]	Saijanai Kuhn:	but even that just died  :-(
[12:12]	Which Linden:	You know that the implementation for that is the same as for group IM, right?
[12:12]	Morgaine Dinova:	Just as long as you don't put on your robe and wizard hat Which, or we're out of here :-)))
[12:12]	Which Linden:	lol
[12:12]	Head Replacement:	I would simply do it on IRC  ;-)
[12:12]	Which Linden:	So is it being slow or actually broken?
[12:12]	Saijanai Kuhn:	not really as far as we know. The list is maintained differently than the group IM list is
[12:13]	Saijanai Kuhn:	or at least we've had far fewer problems with it
[12:13]	Which Linden:	Under the hood it's the same, Sai. The reason you've had fewer problems is just that the member list is shorter
[12:13]	Head Replacement:	just give us an HTML browser in the viewer and we could use some other chat programs  ;-)
[12:13]	Saijanai Kuhn:	totally broken today
[12:13]	Harleen Gretzky:	Seems broken today, haven't been able to send group IMs in any group
[12:13]	Saijanai Kuhn:	But we're the ones working on chat viewers, HR
[12:14]	Head Replacement:	but there are dozens of solutions already around, we just need some browser  ;-)
[12:14]	Which Linden:	Yeah, that would be nice.  :-)
[12:14]	Which Linden:	You can coopt the F1 help browser
[12:14]	Head Replacement:	it might not be too integrated but it would at least work  :)
[12:14]	Head Replacement:	I know
[12:14]	Head Replacement:	but everybody would need to do that
[12:14]	Which Linden:	Requires XML editing
[12:14]	Head Replacement:	we can also use the CSI viewer  ;-)
[12:14]	Saijanai Kuhn:	LIBSL is too monolithic
[12:15]	Which Linden:	Or someone's profile page, if you like tiny,tiny chat
[12:15]	Head Replacement:	maybe I should put a chat there  :)
[12:15]	Morgaine Dinova:	Which: we've set up an AWG conference on jabber.org, but it's not really had buy-in so far. Everyone is hoping group IM gets fixed ... but Zero said today that it won't near-term, needs whole redesign. :-((((
[12:15]	Harleen Gretzky:	OnRez viewer has a browser internal
[12:15]	Head Replacement:	I know, that's what I meant with CSI viewer
[12:15]	Saijanai Kuhn:	so does the main client. Look at your profile
[12:15]	Saijanai Kuhn:	and for that matter, the login screen is just a webpage
[12:16]	Which Linden:	I agree that we should do something, but it's important that we do the *right* thing
[12:16]	Head Replacement is also just a web page
[12:16]	Harleen Gretzky:	yes, but the default when you click on a link is the internal browser in OnRez
[12:16]	Saijanai Kuhn:	which leads me to my question. Day Oh posted teh login page. How can I use that with a script?
[12:16]	Saijanai Kuhn:	can I just POST First Name, Last Name, Password?
[12:16]	Which Linden:	OK, I should go, thanks again, all!
[12:16]	Head Replacement:	cya Which!  :-)
[12:17]	Harleen Gretzky:	bye Which
[12:17]	Which Linden:	Sai: I think you can continue to use the old xml-rpc for a bit
[12:17]	Morgaine Dinova:	Bye Which  :-)
[12:17]	Saijanai Kuhn:	But I'm documenting the new format, Which
[12:17]	Which Linden:	where a a bit = probably months
[12:17]	Which Linden:	Oh, right, the new thing, I'm the wrong guy to talk to, righto.
[12:17]	Which Linden:	Anyway, we out!