User:Enus Linden/Office Hours/2008 October 17

From Second Life Wiki
Jump to navigation Jump to search
  • [9:31] Whump Linden: Hey folks.
  • [9:31] Teravus Ousley: Hi
  • [9:31] Harvz Wilber: hi whump
  • [9:32] Saijanai Kuhn: Nightcrwler sighting
  • [9:32] XLR8RRICK Hudson: I found it
  • [9:32] Tao Takashi: Hi
  • [9:32] Tao Takashi: kinda laggy..
  • [9:32] Whump Linden: Hey Tao
  • [9:32] Saijanai Kuhn: Yeah I was noticing that too
  • [9:32] Saijanai Kuhn: Typing speed is slow
  • [9:32] Teravus Ousley: made pachinko in opensim yesterday.
  • [9:33] Teravus Ousley: was working on the physics engine
  • [9:33] Whump Linden: Testing the new physics stuff?
  • [9:33] Harvz Wilber: wow, where was it?
  • [9:33] XLR8RRICK Hudson: look underground
  • [9:33] Saijanai Kuhn: Hey Tess
  • [9:34] Saijanai Kuhn: Hey Fearless Leader
  • [9:34] XLR8RRICK Hudson: Hello everyone
  • [9:34] Whump Linden: Hey Enus.
  • [9:34] Teravus Ousley: Hello
  • [9:34] Enus Linden: hi there e1!
  • [9:34] XLR8RRICK Hudson: I had to use some tricks to find your bear
  • [9:34] Enus Linden: hehe xl
  • [9:35] Enus Linden: so, not only could i not teleport from a full sim just a moment ago, my agent's presence got stuck. that makes me sad..
  • [9:35] Enus Linden: hi teravus
  • [9:35] Enus Linden: tao
  • [9:35] Enus Linden: how are y'all today?
  • [9:35] Harvz Wilber: good good
  • [9:35] Tao Takashi: fine, technically it's weekend ;-)
  • [9:35] XLR8RRICK Hudson: im in great shape
  • [9:36] Enus Linden: hooray for weekends!
  • [9:36] Tao Takashi: yeah, finally some time for some cool stuff to work on ;-)
  • [9:36] Enus Linden: mine looks a little busy tbh, ripping out a kitchen and putting a new one in.
  • [9:36] Enus Linden: i am jealous of your cool stuff
  • [9:36] Saijanai Kuhn: fun
  • [9:36] Teravus Ousley: tends to not have the weekend start until 1AM on Saturday
  • [9:36] Teravus Ousley: :D
  • [9:36] Tao Takashi: well, maybe I just sleep 2 days ;-)
  • [9:37] Enus Linden: well, let's talk shop shall we?
  • [9:37] Harvz Wilber: I used to do custom kitchens and baths
  • [9:37] Tao Takashi: actually one item is updating fashionplanet which is maybe not so cool but needs to be done
  • [9:37] Enus Linden: hehe
  • [9:37] Enus Linden: pyogp, testing ogp, etc.
  • [9:37] Teravus Ousley: I updated : https://wiki.secondlife.com/w/index.php?title=EventQueueGet_CAP for those who didn't see it on #gridnauts
  • [9:37] Enus Linden: teravus and i chatted the other day, about the possibilty of using pyogp for opensim testing
  • [9:37] Enus Linden: i sent mail
  • [9:37] Enus Linden: etc
  • [9:38] Enus Linden: how can we best use pyogp in this context i wonder?
  • [9:38] Tao Takashi: and I might wonder the same thing as Gareth ;-)
  • [9:38] Enus Linden: yeah, now that it's mentioned, i wonder the same
  • [9:38] Enus Linden: so
  • [9:38] Saijanai Kuhn: I put it a link to it in the Groupies page to
  • [9:38] Tao Takashi: esp. as we are not really talking about the part in OGP which is region specific
  • [9:39] Enus Linden: i think that making a specific opensim/ll distinction in the tests
  • [9:39] Enus Linden: rather have docs that are useful and descriptive?
  • [9:39] Tao Takashi: of course there is nothing stopping people from creating a new package on top of pyogp which creates a new testsuite for the legacy protocol
  • [9:39] Tao Takashi: I'd prefer docs before tests
  • [9:40] Tao Takashi: if it's about documenting the protocol
  • [9:40] Saijanai Kuhn: well, I think Enus wants that for his own nefarious (?) purposes
  • [9:40] Tao Takashi: but then I wonder why we might need an opensim specific test, shouldn't LL legacy and opensim be the same?
  • [9:40] Enus Linden: what is the that you are referring to sai?
  • [9:40] Saijanai Kuhn: legacy protocol tests
  • [9:41] Teravus Ousley: Tao: likely they're not the same.
  • [9:41] Teravus Ousley: Tao: likely the're 'close' but not the same.
  • [9:41] Enus Linden: ll and opensim should be the same, but there will be implementation differences in subtle ways that may matter. but at the protocol implementation level, it should be theclose
  • [9:41] Tao Takashi: but apparently I am using the same client for both
  • [9:41] Tao Takashi: except maybe for some extras like grid mode stuff etc.
  • [9:41] Tao Takashi: so more inter-opensim communication
  • [9:42] Teravus Ousley: As far as tests go, some specific ordering of things that you might get on a Linden Sim.. might be ordered differently in OpenSimulator
  • [9:42] Saijanai Kuhn: Well, right now, pyogp is officialy a client-server protocol thing. There's no reason why there can't be other modules to do other things, like Tao's AD for example
  • [9:42] Teravus Ousley: That might cause tests to fail, but client connections would still work just fine.
  • [9:43] Tao Takashi: sure, as I said, there is nothing stopping people frmo creating new test suites on top
  • [9:43] Tao Takashi: just trying to understand why this is necessary :)
  • [9:43] Saijanai Kuhn: Teravus, as long as a module keeps to the defined interface, yo can do things any way you like
  • [9:43] Tao Takashi: ok, so it might also be solveable by making tests more adapting
  • [9:43] Sea Urchin: beanbag: Going to next texture.
  • [9:43] Teravus Ousley: As far as the CAPS go, they follow the protocol drafts.. so that shouldn't be an issue.
  • [9:43] Teravus Ousley: (for OGP)
  • [9:43] Tao Takashi: I mean, I would say, make tests according to the spec but apparently there is no spec for the legacy stuff ;-)
  • [9:44] Enus Linden: so teravus: there are a set of test_ogp* tests in interop now, that cover some cases of caps handling and client login and teleport. I've got a recent ogp enabled opensim running. i'll point those tests at that sim and will let you know how things go :)
  • [9:44] Teravus Ousley: Thanks.
  • [9:44] Enus Linden: btw, i already have one small ll/opensim specific case in pyogp.lib.base, in the public_seed handling
  • [9:44] Enus Linden: [1]
  • [9:44] Enus Linden: line 72
  • [9:44] Tao Takashi: but it might be good to identify such diverging points on the wiki for later thinking about them when we do the OGP spec around these things
  • [9:45] Teravus Ousley: I've got to read the Pygop code some more to determine where the region domain pointers are.. :D
  • [9:45] Tao Takashi: Hm, I think this should be differently solved ;-)
  • [9:45] Enus Linden: sure tao, alternative solutions are welcome
  • [9:46] Saijanai Kuhn: Teravus loo at my wxexample code it might be more clear
  • [9:46] Enus Linden: wx code is not easy to read at all tho sai :)
  • [9:46] Saijanai Kuhn: ah, well the sequenceing part isn't really wx specific anyway
  • [9:47] Tao Takashi: from where is that regionuri coming again?
  • [9:47] Enus Linden: object level test based docs would be useful
  • [9:47] Enus Linden: tao, it's a parameter. based into Region when it's initialized
  • [9:47] Enus Linden: if i recall correctly
  • [9:47] Tao Takashi: ok, but why don't you pass then the correct URL
  • [9:47] Saijanai Kuhn: right now its hard-coded i the method. I've been working on a GUI to add it, aor to pass it in from a command line (or command file)
  • [9:48] Tao Takashi: anyway, I will look later with a proper editor
  • [9:48] Enus Linden: tao: the viewer takes the raw region_uri, without public seed
  • [9:48] Sea Urchin: beanbag: Going to next texture.
  • [9:48] Enus Linden: it will all change in due time anyway...
  • [9:48] Tao Takashi: what does the spec say?
  • [9:49] Enus Linden: we won't tp to [2] etc, we'll teleport to Ahern
  • [9:49] Tao Takashi: well, if it's just temporary until either spec or opensim will change then that's ok
  • [9:49] Tao Takashi: right, we need some Region Informatino Service based on the region domain
  • [9:49] Saijanai Kuhn: [3] starting at line 186. The avatar_obj calass
  • [9:49] Saijanai Kuhn: class*
  • [9:49] Tao Takashi: GET [4]
  • [9:49] Tao Takashi: and get back the URI etc.
  • [9:50] Tao Takashi: regionservice = regiondomain
  • [9:50] Teravus Ousley: well, it isn't defined in the spec, since the agent domain gets the rez_avatar/request cap from the public seed that the user types
  • [9:50] Enus Linden: is mesmerized by teravus' typing anim
  • [9:50] Teravus Ousley: it's outside the scope.
  • [9:51] Tao Takashi: well, I am not totally into the spec right now to be able to discuss it but to have some condition like this in the code is surely not correct ;-)
  • [9:51] Tao Takashi: so there needs to be some URI discovery or somesuch
  • [9:52] Tao Takashi: Enus: maybe mark it with TODO: <whatever comment>
  • [9:52] Teravus Ousley: The user types an address (which is the public seed) based on some known URL to the user.
  • [9:52] Tao Takashi: so we can search for these things later and don't forget it
  • [9:52] Enus Linden: can do Tao. or, we work with region uris that include public_seed in the case of LL
  • [9:52] Tao Takashi: ok, so he might type it with /public_seed attached then
  • [9:52] Teravus Ousley: .. the public seed gives the user a rez_avatar/request cap.
  • [9:52] Teravus Ousley: (agent domain, not user)
  • [9:53] Teravus Ousley: he might. He might not.
  • [9:53] Teravus Ousley: :D I know OpenSimulator responds to / or /<URL Encoded Region Name>
  • [9:53] Tao Takashi: well, in the long run there shouldn't be the need to type it in like that. you should type in one URL for a region domain and get a list of region names via some service IMHO
  • [9:54] Tao Takashi: or if we don't have the RD service then at least we could use some XRDS like service discovery.. do an XRDS discovery on the URL the user typed in and it will give you the location of the seedcap
  • [9:54] Enus Linden: yeah, per urlencoded region uris, we at least need to preserve that :)
  • [9:54] Tao Takashi: should be easy to write to return 5 lines of XML
  • [9:55] Saijanai Kuhn: In 15 I need to leave. Will leave avie for chat logging purposes
  • [9:55] Tao Takashi: we don't do any harm to your avi, promised!
  • [9:55] Enus Linden: so i'll start with opensim testing as soon as possible (today?, running first pass now:) )
  • [9:56] Enus Linden: what would folks like to see happen in the lib next?
  • [9:56] Tao Takashi: I will also try to make your proper svn package this weekend, Sai
  • [9:56] Tao Takashi: and try to factor out the legacy login from pyogp into it's own package
  • [9:56] Tao Takashi: if fahionplanet stuff permits, that is
  • [9:56] Tao Takashi: but I will get to Sai's package
  • [9:56] Saijanai Kuhn: KK. COuld we have a generic .pth file that I can link in that is generated with each release?
  • [9:57] Tao Takashi: as I wrote on the wiki, the best thing is to create a new egg which then sets it's path automatically
  • [9:57] Enus Linden: tao: that should be easy to do, factor out legacy login
  • [9:57] Enus Linden: but
  • [9:57] Enus Linden: pyogp.lib.base already has legacy in it
  • [9:57] Enus Linden: eg message system
  • [9:57] Enus Linden: should that move out in your opinion too?
  • [9:57] Saijanai Kuhn: Tao, for quick and dirty coding, I'd rather just import genericpath or something instead of creating and egg
  • [9:57] Tao Takashi: right, but we need that right now while we don't need the login necessarily in the same package
  • [9:57] Tao Takashi: msgsystem is too central I guess
  • [9:58] Tao Takashi: and base probably should work with open Grid beta
  • [9:58] Tao Takashi: also: login has been redefined in OGP, message system hasn't yet
  • [9:58] Saijanai Kuhn: As long as UDP exists, there's no difference between legacy and OGP for anything but logi d the TP
  • [9:58] Tao Takashi: as long as there is no other solution speced in OGP I assume it to be ok to be in base. If there's a new solution, this should be in base and the old one in legacy. does that make sense?
  • [9:59] Saijanai Kuhn: yeah, but UDP is going to be there for a LONG time
  • [9:59] Enus Linden: that is ok with me, but we need clear documentation and comments indicating such
  • [9:59] Tao Takashi: right, so it will then stay in this or similar form in base
  • [9:59] Enus Linden: but it's odd to me...
  • [9:59] Tao Takashi: first I might try the legacy login though :)
  • [9:59] Enus Linden: in time, we will have new objects, and they will have to live in 2 places?
  • [10:00] Tao Takashi: well, now we have 2 objects doing the same in one place
  • [10:00] Enus Linden: is not really the same
  • [10:00] Tao Takashi: I think it's better to factor those out now. When OGP is fully deployed we can simply not use the second place anymore
  • [10:00] Saijanai Kuhn: well, the legacy design is pretty much frozen with an EQG pipe and a UDP pipe. DOn't see that changing for a year or two at least
  • [10:01] Enus Linden: i just want to keep things simple.
  • [10:01] Tao Takashi: having both in one package just increases complexity in there IMHO
  • [10:01] Enus Linden: multiple packages, dependent on each other, is more complicated imo :)
  • [10:01] Tao Takashi: as you also need to add information what is now legacy and what isn't
  • [10:01] Tao Takashi: one package with legacy stuff which you import if you need legacy stuff
  • [10:02] Saijanai Kuhn: tao, for now, that's in the file that names what packets might be coming in through EQG instead of UDP
  • [10:03] Tao Takashi: as for EQG and UDP you migth be right, Sai. but it's still not in the OGP spec.. if it's staying the same there is no need for any change to our code regarding the spec I'd say and it can happily stay where it is now
  • [10:03] Enus Linden: tao: why wouldn't the inverse method of doing this be more apt: pyogp.lib.base does ONLY stuff in the ogp spec?
  • [10:04] Enus Linden: and pyogp.lib.legacy (or something) has everything else?
  • [10:04] Tao Takashi: and if we keep all legacy things in base and at some point OGP is active we have a hard time then to get rid of all the old code.. This might be a bit over time and this is why I'd prefer a separate package where you put it directly
  • [10:04] Tao Takashi: sure, would also be possible. But you'd always have the legacy dependancy until OGP is fully active
  • [10:04] Tao Takashi: so then you always need to use 2 packages regardless of using OGP or not
  • [10:05] Enus Linden: well, once ogp is the standard, then there's a big merge effort in pyogp
  • [10:05] Tao Takashi: and: maybe more imports would have to be renamed when things move into base
  • [10:05] Enus Linden: good point
  • [10:05] Tao Takashi: I would not propose to do it just at the end but more component by component
  • [10:05] Enus Linden: support apps in the future now
  • [10:05] Tao Takashi: big merge sounds very scary
  • [10:06] Tao Takashi: I mean people need to change their imports nevertheless of course as things will change
  • [10:06] Enus Linden: fword would be happy if we were to support future apps now
  • [10:06] Enus Linden:  :)
  • [10:06] Tao Takashi: but maybe not as many
  • [10:06] Tao Takashi: all future apps? :)
  • [10:06] Tao Takashi: up until which year? 2020? :)
  • [10:06] Enus Linden: until ogp 2.0
  • [10:06] Enus Linden: or the world blows up
  • [10:06] Enus Linden: which ever comes first
  • [10:06] Tao Takashi: is thinking about writing some alternative OGP ;-)
  • [10:06] Enus Linden: always thinking.... :D
  • [10:06] Wrapp Seiling: smiles
  • [10:06] Tao Takashi: more standards based
  • [10:07] Enus Linden: please use caps.
  • [10:07] Enus Linden: hehe
  • [10:07] Tao Takashi: YADIS/basicauth instead of the auth being used now.. header auth instead of caps, oauth instead of caps, JSON instead of LLSD
  • [10:08] Enus Linden: tao: question about separate packages
  • [10:08] Tao Takashi: but it won't get implemented anyway as there is this big viewer which would need to be changed and I am not really the C++ guys ;-)
  • [10:08] Enus Linden: so i have my avatar object
  • [10:08] Enus Linden: i want to tell it to teleport
  • [10:08] Enus Linden: it can do so in the legacy manner, or ogp manner.
  • [10:08] Tao Takashi: I think those objects also need to be thought about.. this was the first shot back then, wondering if they still make sense in future apps
  • [10:09] Enus Linden: what does that look like with separate packages?
  • [10:09] Teravus Ousley: is technically not allowed to look at the viewer as part of his contributor agreement to OpenSimulator.. so you'd have to get someone else to instill JSON support into the client.
  • [10:09] Enus Linden: yes on object rethinkn please
  • [10:09] Tao Takashi: I'd need to look at the code
  • [10:09] Teravus Ousley: (viewer source, of course)
  • [10:09] Enus Linden: i can't just say avatar.teleport can i if they are separate packages
  • [10:09] Tao Takashi: unfortunately my compt is busy just doing SL and not much more is working
  • [10:09] Enus Linden: can zca work with adapters that like inseparate packages?
  • [10:10] Tao Takashi: so no looking at code right now
  • [10:10] Tao Takashi: yes, you can use adapters from separate packages
  • [10:10] Tao Takashi: or a utility
  • [10:10] Tao Takashi: you can also name utilities, like getUtility(ILogin, 'ogplogin')
  • [10:10] Tao Takashi: or something like that
  • [10:10] Enus Linden: still has a hjard time with zca
  • [10:10] Tao Takashi: so the separate package just registers a new ILogin utility with the name "legacy"
  • [10:11] Tao Takashi: I can show you then :)
  • [10:11] Enus Linden: yay!
  • [10:11] Tao Takashi: those components are global to your application
  • [10:11] Tao Takashi: you register them and they are available everywhere, regardless of the package
  • [10:12] Tao Takashi: of course the interface is bound to some package because you import it from there
  • [10:12] Enus Linden: i see
  • [10:12] Enus Linden: is visualizing zca suddenly
  • [10:12] Tao Takashi: but you can register a new utility in a new package with an interface defined in e.g. pyogp.lib.base
  • [10:12] Enus Linden: it's a little uncomfortable
  • [10:12] Enus Linden: the visualizing is
  • [10:13] Tao Takashi: think of it like a dictionary
  • [10:13] Tao Takashi: the key is the interface, like a name
  • [10:13] Tao Takashi: and the value is a utility
  • [10:13] Enus Linden: yep
  • [10:13] Tao Takashi: or in the adapter dict it's an adapter but the key is not only one interface but two
  • [10:13] Enus Linden: i was jsut seeing the imports of utilities
  • [10:13] Enus Linden: and then their implementation in classes
  • [10:13] Tao Takashi: one interface the context object implements and one you need
  • [10:14] Tao Takashi: and as said, utilities also can have an additional key, the name.
  • [10:14] Tao Takashi: all this would be much more easier to explain in person at some sprint, so I hope people will all come to Europe someday so we can do a sprint together :)
  • [10:14] Saijanai Kuhn: running now. Will have GUI hooked to wxexample and then to working on high-level messages for GUI/commandline. Later all
  • [10:14] Saijanai Kuhn: a f k
  • [10:15] Tao Takashi: cya, Sai!
  • [10:15] Enus Linden: so there are a couple of pressing needs on my end: solving how to run mutiple threads AND be able to kill them (or some other solution for UDP/EQ)
  • [10:15] Enus Linden: that's first priority for me right now
  • [10:15] Enus Linden: second is a protype packet handler arch
  • [10:15] Enus Linden: prototype*
  • [10:16] Enus Linden: is mesmerized by ter's typing anim again
  • [10:16] Teravus Ousley: heh, threads and the EventQueue are also issues for us. Though we've resolved them enough to get it to work... they're consuming threads from an io threadpool.. which isn't the /best/ implementation :D
  • [10:17] Tao Takashi: you need threads for running multiple tests?
  • [10:17] Enus Linden: python threading works relatively well, but I can't kill the things
  • [10:17] Enus Linden: tao: testing teleport e.g.
  • [10:17] Tao Takashi: there should be some solution to stop a thread completely
  • [10:17] Tao Takashi: I know the problem
  • [10:17] Enus Linden: I log into ad. maintain eq heartbeat there
  • [10:17] Tao Takashi: but I also seen apps which do it correctly
  • [10:17] Enus Linden: rez on sim
  • [10:18] Enus Linden: parse UDP packets and event queue
  • [10:18] Tao Takashi: ok, so the basic client needs
  • [10:18] Teravus Ousley: yep
  • [10:18] Enus Linden: then time the threads out and move to another sim
  • [10:18] Tao Takashi: which I wanted to try out with twisted
  • [10:18] Enus Linden: and repeat
  • [10:18] Enus Linden: but that is a test
  • [10:18] Tao Takashi: because then you don't need threads ;-)
  • [10:18] Teravus Ousley: two threads. A EventQueue requester, that's blocked most of the time, and a UDP packet processor
  • [10:18] Enus Linden: i can't Ctrl C the thing while child threads are running
  • [10:18] Enus Linden: can't figure singal.singla + threading instances
  • [10:18] Tao Takashi: I know but there must be a solution for this
  • [10:19] Enus Linden: i can't find it yet :)
  • [10:19] Tao Takashi: unfortunately I cannot remember anymore what apps behaved correctly..
  • [10:19] Enus Linden: i type horribly...
  • [10:19] Tao Takashi: but it was during my twisted tests that I encountered CTRL-Cable threads somewhere
  • [10:19] Enus Linden: then we should open some twisted source
  • [10:19] Tao Takashi: maybe twisted would help you as well
  • [10:19] Enus Linden: i'll dig in
  • [10:20] Tao Takashi: but it's strange in it's concept at first so I guess an example is best
  • [10:20] Tao Takashi: and I hear Linden Lab shouting that they don't want another package ;-)
  • [10:20] Enus Linden: an example is easy to put together
  • [10:20] Enus Linden: i have one sitting around somewhere
  • [10:20] Enus Linden: will dig it up next week
  • [10:20] Tao Takashi: my fear is just that the current msgsystem does not support it
  • [10:21] Enus Linden: suport what?
  • [10:21] Tao Takashi: because it relies on waiting for packets
  • [10:21] Tao Takashi: twisted
  • [10:21] Enus Linden: threads?
  • [10:21] Enus Linden: oh twisted
  • [10:21] Tao Takashi: maybe it's also not threadsafe, I haven#t check all places back then
  • [10:21] Enus Linden: well we'll find out
  • [10:21] Tao Takashi: but those global variables in the class didn't look too threadsafe back then
  • [10:21] Tao Takashi: and would need a lot of locks
  • [10:21] Enus Linden: describe not threadsafein this context please?
  • [10:22] Tao Takashi: well, like there is only one parsing class for a message which does all messages
  • [10:22] Tao Takashi: and it had a pointer which message it's parsing at the moment
  • [10:22] Tao Takashi: now if you change threads then this pointer could point to another message afterwards
  • [10:22] Tao Takashi: because this parsing object is global
  • [10:22] Tao Takashi: not sure about the correct names anymore right now
  • [10:23] Tao Takashi: and this message pointer was shared between different methods
  • [10:23] Tao Takashi: curmesg or so
  • [10:23] Tao Takashi: I am also not sure what's left from that right now
  • [10:23] Tao Takashi: but that will be a problem and a hard to debug one as well
  • [10:24] Tao Takashi: that's why my proposal was to make the message parse itself.. then you always have separate objects which do the parsing and they don't mix
  • [10:24] Enus Linden: self.current_msg ?
  • [10:24] Tao Takashi: something like this, yes
  • [10:24] Tao Takashi: so this should be a local variable to the method IMHO
  • [10:24] Enus Linden: deosn't self make it so?
  • [10:24] Enus Linden: or no, thats to the class
  • [10:24] Tao Takashi: it's then an instance variable
  • [10:25] Tao Takashi: you'd need to pass the current message to every method
  • [10:25] Enus Linden: well, we can evaluate
  • [10:25] Tao Takashi: or: you put those methods inside the message class
  • [10:25] Tao Takashi: then self is ok
  • [10:25] Tao Takashi: or you put a lock around those calls
  • [10:25] Tao Takashi: but that looked like you have lots of things locked
  • [10:26] Tao Takashi: and the app would need to know where it needs to set locks
  • [10:26] Tao Takashi: because it shouldn't be in the msgsystem
  • [10:26] Tao Takashi: as it might be used without threads and no idea what locks will do then
  • [10:26] Tao Takashi: so this was something I wanted to have a look at back then but didn't came to it
  • [10:26] Enus Linden: when might you be able to look now?
  • [10:27] Enus Linden: i'd like to feel comfortable that we are good, or know what to do to improve things
  • [10:27] Tao Takashi: and as said, with twisted there is the problem with IRestClient, as this always waits for packets
  • [10:27] Tao Takashi: which is ok in threads, because then the next thread does some work
  • [10:27] Enus Linden: so that i can start pestering folks re: packet handlers
  • [10:27] Tao Takashi: but not with twisted
  • [10:27] Tao Takashi: well, not sure I have much time these days to look at it, to be honest
  • [10:27] Tao Takashi: lots of work coming in right now
  • [10:27] Enus Linden: you are busy lately tao :)
  • [10:28] Tao Takashi: plus my doubts about OGP in general ;-)
  • [10:28] Enus Linden: well, our time is just about up
  • [10:28] Tao Takashi: but I will try to have a look at least at legacy login
  • [10:29] Enus Linden: i'll work on tests pointed at opensim as soon as possible
  • [10:29] Tao Takashi: getting into the msgsystem again also feels like some effort
  • [10:29] Enus Linden: that is a major investment tao
  • [10:29] Tao Takashi: and you forget so quickly again afterwards ;-)
  • [10:29] Tao Takashi: so I still want to try to make it easier to grasp
  • [10:29] Enus Linden: indeed
  • [10:30] Enus Linden: thanks for coming today gang
  • [10:30] Tao Takashi: but in a branch
  • [10:30] Tao Takashi: should I have time ;-)
  • [10:30] Tao Takashi: thanks for hosting, Enus
  • [10:30] Teravus Ousley: Thanks for hosting
  • [10:30] Wrapp Seiling: thank you ...
  • [10:30] Enus Linden: sure thing!
  • [10:31] Enus Linden: see you all around in irc and such...
  • [10:31] Enus Linden: have a good weekend
  • [10:31] Teravus Ousley: you too sir!