Open Source Meeting/2008-05-15

From Second Life Wiki
Jump to: navigation, search
  • paste transcript here[14:01] Rob Linden: mtg agenda: [1]
  • [14:01] Carjay McGinnis: lol
  • [14:01] Rob Linden: thanks Michelle2 for coordinating the agenda
  • [14:01] Rob Linden: we plan to post the transcript on wiki.secondlife.com, so don't say anything you don't want to show up there
  • [14:02] Rob Linden: so, I guess we should get started
  • [14:03] Rob Linden: my update
  • [14:03] Rob Linden: spoke at the ION Game Conference this week
  • [14:03] Rob Linden: a lot of folks there seem to think we need to make this more like a game ;-)
  • [14:04] Michelle2 Zenovka: In what respect?
  • [14:04] Rob Linden: we need quests!
  • [14:04] Stephen Posaner: we have rpg areas
  • [14:04] Saijanai Kuhn: well, I think more game-like options would be good but htat requires a lot of work on sim-owner's part too
  • [14:04] Rob Linden: so....here's a quest. find/fix more bugs ;-)
  • [14:04] Rob Linden: brushes off his hands
  • [14:05] Michelle2 Zenovka: i can generate bugs for you *lol*
  • [14:05] Saijanai Kuhn: has a bug...
  • [14:05] Michelle2 Zenovka: I think this is a platform its upto the residents to make a game RPG area if they desire, may be it requires new features to the platform but thats the why it should be
  • [14:06] Rob Linden: anyway, getting a lot more serious about WebKit these days. we've contracted out some prototyping that's gone well so far
  • [14:07] Michelle2 Zenovka: Any chance of what ever you do can it be loaded at run time so its optional
  • [14:07] Squirrel Wood: (on the topic of games... I have my terraformer almost ready for release... and it allows you to play with sim terrain :p)
  • [14:07] Rob Linden: Michelle2: thing is, there's going to be more and more web functionality inworld, we think, so making it optional will be pretty weak
  • [14:08] Michelle2 Zenovka: I was more thinking that you could switch out the back ends, like KDU/openjpeg
  • [14:08] Rob Linden: oh, sure, I think our interface already does that pretty well for us
  • [14:09] Saijanai Kuhn: OPenSim will probably be more versatile for games than SL. SL is more social oriented than twitch oriented
  • [14:09] Rob Linden: we haven't planned to do the same type of "rip out one dll / fall back to the next" like we have with KDU/OpenJPEG, but that's something to consider
  • [14:09] Michelle2 Zenovka: There probably are only so many web function calls you actually need
  • [14:10] Rob Linden: yeah, LLMedia is where its at
  • [14:11] Liana Linden: My update: Making progress on a trademark policy for open source viewers, but nothing to announce yet.
  • [14:11] Saijanai Kuhn: a lot of that issue is protocol stuff, Michelle. As long as the viewer-server protocols can deliver the right data, the client can handle it as it wants to and the server can be as responsive to game needs as the implementers decide
  • [14:11] Rob Linden: Qarl just recently got back from Libre Graphics. He couldn't make it today
  • [14:11] Liana Linden: Also "playing" with the Linux version of the client for my own edification and enjoyment.
  • [14:13] Rob Linden: anyone else want to give an update?
  • [14:14] Rob Linden: Lindens/non-Lindens alike....any SL viewer source projects you're working on that you can share an update about?
  • [14:14] Rob Linden: k....moving right along then
  • [14:15] Rob Linden: Texture decoding, "top corner jobs" and lossless, VWR-1815[c], VWR-2404[c
  • [14:15] Michelle2 Zenovka: Yea
  • [14:15] Carjay McGinnis:  :)
  • [14:15] Rob Linden: https://jira.secondlife.com/browse/VWR-1815
  • [14:15] Michelle2 Zenovka: Carjay and Myself have been banging on this one for the last week or so
  • [14:15] Rob Linden: https://jira.secondlife.com/browse/VWR-2404
  • [14:15] Michelle2 Zenovka: And looks like Qarl has too for even longer
  • [14:16] Michelle2 Zenovka: We now have one big band aid that really helps a lot
  • [14:16] Michelle2 Zenovka: But the fundimental issue is still present
  • [14:16] Michelle2 Zenovka: and in the server too
  • [14:16] Carjay McGinnis: we would like some feedback about what is actually happening on the server side
  • [14:17] Saijanai Kuhn: Seg Baphomet has been working on it for qutie a while too
  • [14:18] Michelle2 Zenovka: Basicly it appears the server is making the same assumptions on cut off points and only sending partial data with out a kick to help it along
  • [14:18] Rob Linden: hmmm.....lemme see if I can do a little realtime research
  • [14:18] Rob Linden: if anyone else wants to weigh in, please do
  • [14:19] Saijanai Kuhn: think the last few messages between Qarl and Seg were about the serverside issues and the texture pipeline in general
  • [14:20] Michelle2 Zenovka: Yea, seg came to the conclusion that its all pretty much broken and needs redoing
  • [14:20] Saijanai Kuhn: and Qarl pointed out the http CAP thing
  • [14:20] Squirrel Wood: client side caching needs major work, yes.
  • [14:20] Saijanai Kuhn: we had a nice dicussion about reverse http this morning at Zero's, which could solve ALL problems of this typeI think
  • [14:21] Michelle2 Zenovka: unless the fundimental handling and decoding of j2k is addressed http download is just another methnod of fetching tetures but does not address the decode issues
  • [14:21] Carjay McGinnis: in what way would it solve this?
  • [14:22] Carjay McGinnis: does not matter really if I get 1 byte per hour over UDP, HTTP or reverse HTTP :)
  • [14:22] Saijanai Kuhn: but with an entirely new ppieline on both sides, you can rewrite from scratch if you need to, without nearly as much trouble as patching the existing pipelien
  • [14:22] Saijanai Kuhn: refactoring by side-stepping
  • [14:22] Michelle2 Zenovka: possible that http could remove the issue from the server completly if the client is requesting what it requires in a different way
  • [14:23] Squirrel Wood: I have / I need lists ?
  • [14:23] Carjay McGinnis: yes, but even then the server must not guess the amount, it could simply send as much as we requested
  • [14:24] Liana Linden: /BRB. Sorry.
  • [14:24] Saijanai Kuhn: with http, the client would POST a request to the CAP, and the server would either send it via the EVentQueueGet pipeline, or just POST it if reverse http is available
  • [14:24] Rob Linden: hmmm, I think there's probably a meeting with a different set of LIndens that we need to pull together
  • [14:24] Saijanai Kuhn: so all the scruft left over from the UDP way would just disappear, or at least would eventually
  • [14:25] Michelle2 Zenovka: What i want to do first is to understand j2k codestreams and know what needs to be done, this can be hacked on to the existing pipeline or designed into a new one from scratch
  • [14:25] Q Linden: there's a very active discussion about this very issue internally
  • [14:25] Rob Linden: I'll put that on my list to help facilitate that. we might just make it an item for next week, but it might warrant a separate discussion
  • [14:25] Michelle2 Zenovka: ok cool Rob
  • [14:26] Rob Linden: Q: are you referring to the reverse HTTP discussion?
  • [14:26] Saijanai Kuhn: sorry, CAP textures wouldn't be set over EQG CAP, but the principel would be the same
  • [14:26] Q Linden: rob, yes
  • [14:27] Saijanai Kuhn: Zero's O.H. on reverse http: https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_May_15
  • [14:27] Rob Linden: ah, righto. at first glance, I'm not a fan of the reverse HTTP approach, but I'm admittedly come to this conversation late
  • [14:27] Strife Onizuka: (thx)
  • [14:27] Liana Linden: /back
  • [14:27] Carjay McGinnis: well, before discussing a new protocol it would just be interesting *how* the server handles requests currently
  • [14:28] Carjay McGinnis: right now we do not know what is happening very well without looking at the server sources
  • [14:28] Michelle2 Zenovka: Yes, details on the handling of the specific texture request and how it details with the discard parameter
  • [14:28] Saijanai Kuhn: that's been stumping the AWG, libsl and everone else for a while
  • [14:28] Michelle2 Zenovka: I can guess whats happening
  • [14:29] Michelle2 Zenovka: the same size calculation as in the viewer with the magic 0.125 factor is applied
  • [14:29] Carjay McGinnis: well, somebody should know for sure
  • [14:30] Rob Linden: I'm wondering if it makes sense for Carjay and/or Michelle2 to show up for one of Zero's office hours for this. it sounds like "maybe", thoguh it also sounds like Carjay and M2 are looking for shorter term soutions than the folks at Zero's oo deal with.
  • [14:31] Q Linden: yeah...the reverse http isn't gonna help in the short term
  • [14:31] Q Linden: but maybe knowing what's going on at the server side will
  • [14:31] Carjay McGinnis: indeed, this could still be a client issue but we can only guess unless we know what is supposed to happen
  • [14:31] Michelle2 Zenovka: I can try to get to Zero's but its right when i am at work
  • [14:31] Rob Linden: k. well, let's resolve to get some more of the relevant devs in a realtime discussion on this. I'll put this meeting on Qarl's cal for next week
  • [14:32] Carjay McGinnis: when is his office hour?
  • [14:32] Saijanai Kuhn: of courswe, reverse http may not make sense for textures anyway
  • [14:32] Saijanai Kuhn: 11 am fridays
  • [14:32] Rob Linden: Qarl's is?
  • [14:32] Saijanai Kuhn: yeah.
  • [14:32] Q Linden: michelle2, is the 0.125 factor the one in llkdu?
  • [14:33] Michelle2 Zenovka: yep thats the one
  • [14:33] Carjay McGinnis: you mean for encode?
  • [14:33] Michelle2 Zenovka: carjay managed to make openjpeg behave more like KDU but in the process found out that thats not correct so the fact kdu works is luck
  • [14:34] Carjay McGinnis: well, the OpenJPEG maintainers say they expect the application to take care of sending only the amount that's necessary
  • [14:34] Carjay McGinnis: but with the latest patches that should not be an issue anymore
  • [14:35] Carjay McGinnis: right now it's really just wondering why it takes so long for the data to arrive from the server
  • [14:36] Rob Linden: I'll ping one of our internal aliases in hopes of giving this more visibility. I'll still put this ont he calendar for next week in case things are still stalled then
  • [14:37] Rob Linden: let's keep going on the mailing list with this, though, and those of you who can make Qarl's office hour tomorrow should show up.
  • [14:37] Rob Linden: moving on?
  • [14:37] Carjay McGinnis: yes, ok
  • [14:37] Rob Linden: Thin Client status....the person who put this on the agenda is not yere
  • [14:37] Rob Linden: here, even
  • [14:37] Rob Linden: not much to say on that front
  • [14:38] Rob Linden: (not anything, really)
  • [14:38] Rob Linden: anyone want to talk about this one, speak up. moving on otherwise....
  • [14:38] Saijanai Kuhn: u m
  • [14:39] Saijanai Kuhn: Enus, tao and I have been working on a test harness that could double as a thin client so...
  • [14:39] Saijanai Kuhn: unless they want 3D graphics and/or voice, python scripts would work as good as anything else
  • [14:39] Rob Linden: well, sure, there's things like AjaxLife as well
  • [14:40] Michelle2 Zenovka: SLeek
  • [14:40] Saijanai Kuhn: AjaxLife is based on libsl, which isn't thin. DItto with SLeek
  • [14:40] Michelle2 Zenovka: its not thin but it does exactly what i want in a text client
  • [14:40] Michelle2 Zenovka: almost
  • [14:40] Q Linden: saijanai: in python?
  • [14:40] Michelle2 Zenovka: sleek is c#
  • [14:40] Michelle2 Zenovka: on liblsl
  • [14:40] Saijanai Kuhn: well, if you can get it to work on your high-end smartphone, I guess its thin enough
  • [14:41] Rob Linden: the test harness is in python. still early days for that
  • [14:41] Saijanai Kuhn: but script-based stuff could work on almost anywhere
  • [14:41] Q Linden: rob, is this the same one Don was working on last week?
  • [14:41] Rob Linden: Q: it might be
  • [14:41] Rob Linden: I'm not sure
  • [14:42] Saijanai Kuhn: donth think so. I asked Enus if he knew of any thin client work and he wasn't aware, so its something else
  • [14:42] Q Linden: i'd hate to see us duplicating effort.
  • [14:42] Q Linden: i'll ping enus and don and make sure we're not making TWO wheels.
  • [14:42] Saijanai Kuhn: I'd guess this would be C++ based. We're just using python scripts to create test clients.
  • [14:43] Saijanai Kuhn: bsaed on teh AWG work to test protocols
  • [14:43] Q Linden: don was working in python, but as I understood it, it was just weekend tinkering
  • [14:43] Q Linden: enus' may be more forward-looking
  • [14:43] Saijanai Kuhn: maybe hte same thing form a different direction then. This is just tinkering too at least on my part
  • [14:44] Saijanai Kuhn: But, regardless, really thin clients can be made to work from pure scripting languages.
  • [14:45] Q Linden: yes. I'll find out and report back next week
  • [14:45] Rob Linden: I don't remmber....is there already a wiki page for what you're all working on, Saijanai
  • [14:45] Rob Linden:  ?
  • [14:45] Saijanai Kuhn: yeah, just sec
  • [14:46] Saijanai Kuhn: https://wiki.secondlife.com/wiki/Example_protocol_code
  • [14:46] Saijanai Kuhn: mess organization though
  • [14:46] Saijanai Kuhn: The presence script is furthest along. Will rez a ruth and keep her here indefintiely
  • [14:46] Rob Linden: no worries....just wanted a pointer in case others here wanted to follow up
  • [14:46] Rob Linden: anyway, should we move on?
  • [14:47] Rob Linden: skipping the megaprim issue, per my comment in the agenda
  • [14:47] Michelle2 Zenovka: yes sure
  • [14:48] Carjay McGinnis: yes
  • [14:48] Rob Linden: next up: https://jira.secondlife.com/browse/VWR-4022
  • [14:49] Rob Linden: (sorry, I started reading the issue before posting here)
  • [14:49] Michelle2 Zenovka: This is just a case of some of my patches that i use, but these don't seem to be in ank kind of real internal process so need a prod
  • [14:49] Q Linden: / @rob, hot mic
  • [14:49] Rob Linden: heh, whaddya know
  • [14:49] Carjay McGinnis: well, they have a DEV-ID :)
  • [14:50] Carjay McGinnis: but as far as I understand that only means they *can* be triaged internally not that it means somebody even looks at them?
  • [14:51] Michelle2 Zenovka: 4022 was reopened and i patched it some time later
  • [14:51] Rob Linden: k....I pinged Soft about it
  • [14:51] Saijanai Kuhn: there she is
  • [14:51] Rob Linden: soft is here?
  • [14:52] Saijanai Kuhn: ruth is, sorry
  • [14:52] Rob Linden: anyway, we'll reassign if soft comes back with "busy" on this one.
  • [14:53] Rob Linden: next one: https://jira.secondlife.com/browse/VWR-6800
  • [14:54] Rob Linden: k....looks like this one needed to be kicked into the internal triage queue. now it is
  • [14:54] Rob Linden: https://jira.secondlife.com/browse/VWR-5717
  • [14:55] Rob Linden: same problem with the next one
  • [14:55] Rob Linden: er....with 5717
  • [14:56] Rob Linden: https://jira.secondlife.com/browse/VWR-3766
  • [14:57] Rob Linden: this one wasn't marked as having a patch in our internal tracker. fixing....
  • [14:58] Carjay McGinnis: you have to enter that manually when importing?
  • [14:58] Carjay McGinnis: I thought "importing" was just a button to press :)
  • [14:58] Rob Linden: not if it has a patch when its imported
  • [14:59] Rob Linden: this one didn't
  • [14:59] Carjay McGinnis: ah, ok
  • [14:59] Rob Linden: last one: https://jira.secondlife.com/browse/VWR-1352
  • [15:01] Rob Linden: looks like this one fell through the cracks
  • [15:02] Carjay McGinnis: it's still in 1.20.7.0
  • [15:02] Rob Linden: I put it in the internal triage queue
  • [15:03] Rob Linden: I also moved it into the DEV project in case that makes a difference
  • [15:03] Rob Linden: anyway, that's all folks
  • [15:03] Rob Linden: thanks everyone for coming