Open Source Meeting/2008-06-19

• [2008/06/19 14:00] Harleen Gretzky: Hi Q
• [2008/06/19 14:00] Q Linden: nobody hear but us lightbulbs
• [2008/06/19 14:00] Q Linden: whoa
• [2008/06/19 14:00] Q Linden: here
• [2008/06/19 14:00] Rob Linden: hi all
• [2008/06/19 14:00] Harleen Gretzky: HI Rob
• [2008/06/19 14:00] Carjay McGinnis: Hi Rob
• [2008/06/19 14:01] Soft Linden: Squirrel - I want a subscription version of your fortune cookie - like an object I can buy that sends me one once a day for a month or something - the cookies are fun
• [2008/06/19 14:01] Squirrel Wood: heh
• [2008/06/19 14:01] Rob Linden: transcript will (probably) be posted, so make sure you don't say anything you don't want on the wiki
• [2008/06/19 14:01] Squirrel Wood: I have dispensers set up for sale.
• [2008/06/19 14:02] Rob Linden: quickly reshuffles the agenda before really getting started
• [2008/06/19 14:03] Rob Linden: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
• [2008/06/19 14:03] Squirrel Wood: That dispenser should satisfy your cookie needs for the next 60 cookies.
• [2008/06/19 14:04] Rob Linden: first item: Threaded Local File System (LLFSThread class) - what are LLs plans for it? Carjay McGinnis 10:51, 17 June 2008 (PDT)
• [2008/06/19 14:04] Rob Linden: has no clue
• [2008/06/19 14:04] Carjay McGinnis: lol
• [2008/06/19 14:04] Carjay McGinnis: so it's forgotten code?
• [2008/06/19 14:04] Rob Linden: well, the fact that *I* have no clue about that code is indicative of pretty much nothing
• [2008/06/19 14:05] Carjay McGinnis: I just put it on the agenda because there was no answer on sldev
• [2008/06/19 14:05] JB Kraft: is that built on apache code? (sorry i didnt get a peek at the code b4 i came)
• [2008/06/19 14:05] Poppy Linden: doesn't know
• [2008/06/19 14:05] Carjay McGinnis: do you mean the apr code?
• [2008/06/19 14:05] Poppy Linden: but once again, that's not indicative of much
• [2008/06/19 14:06] JB Kraft: yeah, thats it carjay :)
• [2008/06/19 14:06] Carjay McGinnis: LLLFS seems to be a class that is commented out for most part
• [2008/06/19 14:06] Carjay McGinnis: and the apr calls are used instead
• [2008/06/19 14:06] Carjay McGinnis: but it's a bit confusing because it's still in the code
• [2008/06/19 14:06] Carjay McGinnis: so I guess it can be pretty much ignored
• [2008/06/19 14:06] Buckaroo Mu: There's a fair amount of stuff in teh code that doesn't get used - for instance, the HTTP texture requests & such, defined out at least.
• [2008/06/19 14:07] JB Kraft: i think apr was a way to deal with cross-platform issues
• [2008/06/19 14:07] Buckaroo Mu: My understanding is that APR is a cross-platform interface to the local file system.
• [2008/06/19 14:07] Carjay McGinnis: I'd like to get a definite answer, personal beliefs can cause a lot of bugs in this business :)
• [2008/06/19 14:07] Buckaroo Mu: And everything used by LSF will eventually be migrated over to the APR calls.
• [2008/06/19 14:08] Q Linden: I'm seeing llfsthread used as a base class for texture cache stuff
• [2008/06/19 14:08] Poppy Linden: in many cases we abstract a library's interface so that we can switch out said library with little code impact
• [2008/06/19 14:08] Rob Linden: I'd like to forward the original mail to sldev on this subject to one of our internal lists... Carjay, which mail should I forward?
• [2008/06/19 14:08] Carjay McGinnis: yes, but it's commented out in all places with a define, there's also code in the audiodecoder which is also not used
• [2008/06/19 14:08] Q Linden: Am I confused? The agenda is talking about LLFSThread
• [2008/06/19 14:09] Carjay McGinnis: yes, I was talking of LLFSThread
• [2008/06/19 14:09] Q Linden: carjay, where's the define?
• [2008/06/19 14:10] Carjay McGinnis: #define USE_WAV_VFILE
• [2008/06/19 14:10] Carjay McGinnis: in audioengine.h
• [2008/06/19 14:11] Carjay McGinnis: and #if USE_LFS_READ in the texture cache
• [2008/06/19 14:11] Buckaroo Mu: Right
• [2008/06/19 14:11] Buckaroo Mu: pulls up VS
• [2008/06/19 14:11] Carjay McGinnis: there's also a USE_LFS_WRITE
• [2008/06/19 14:11] Carjay McGinnis: in lltexturecache.cpp
• [2008/06/19 14:11] Carjay McGinnis: top of the file
• [2008/06/19 14:11] Carjay McGinnis: both defined as 0
• [2008/06/19 14:12] Carjay McGinnis: I think it was a mail in the cache performance thread, Rob
• [2008/06/19 14:13] Carjay McGinnis: hm, can't find it at the moment
• [2008/06/19 14:13] Battery Street: Irregulars whispers: Thanks for your interest in the Battery Street Irregulars. We'll be contacting you soon!
• [2008/06/19 14:13] Battery Street: Irregulars: Couldn't find notecard
• [2008/06/19 14:13] Q Linden: I believe I heard Steve talking about this; I think we've been tinkering with the threading, but aren't comfortable enough with its stability to turn it on yet
• [2008/06/19 14:13] Q Linden: That's vague rumors and innuendo, though
• [2008/06/19 14:13] Soft Linden: I'd drop this question back on sldev, but get it so it's clearly identified in the subject line. If I recall, this came up midway through another pretty long thread.
• [2008/06/19 14:13] Rob Linden: +1 Soft
• [2008/06/19 14:13] Carjay McGinnis: yes, think so, too
• [2008/06/19 14:14] Carjay McGinnis: ok
• [2008/06/19 14:14] Battery Street: Irregulars: Missing inventory item
• [2008/06/19 14:14] Rob Linden: next up
• [2008/06/19 14:14] Rob Linden: the "relative C++ noobs " thread
• [2008/06/19 14:15] Buckaroo Mu: regrets to admit he falls into that category
• [2008/06/19 14:15] Rob Linden: I think there was probably already more conversation on the subject than Scalar might have been anticipating
• [2008/06/19 14:15] Soft Linden: A pretty unanimous "Godspeed, yes, go for it!"
• [2008/06/19 14:15] Soft Linden: From Lindens and residents both
• [2008/06/19 14:15] Rob Linden: "yay....someone talking about dev issues!"
• [2008/06/19 14:15] Soft Linden:  :)
• [2008/06/19 14:15] Poppy Linden: YAY!
• [2008/06/19 14:16] Carjay McGinnis: indeed, nothing to say against it
• [2008/06/19 14:16] Buckaroo Mu: "If you can, do. If you can't, try anyway." :D
• [2008/06/19 14:16] Rob Linden: anyone have anything to add on that topic, or should we move on?
• [2008/06/19 14:16] Poppy Linden: be less hesitant to mail on tech issues :P
• [2008/06/19 14:16] Soft Linden: Nah, just - please. Don't be shy about that kind of thing, folks. Your typical Linden loves helping out if they see someone making an honest effort.
• [2008/06/19 14:16] Rob Linden: indeed! moving on...
• [2008/06/19 14:16] Rob Linden: * Discuss the changes to llTextureFetch and llTextureCache recently discussed on SLDEV, any issues that may arise from moving the decode and network fetch operations to llTextureCache (or possibly more or less combining the two classes into one), and other "uncompressed cache" issues. Buckaroo Mu 12:10, 19 June 2008 (PDT)
• [2008/06/19 14:17] Buckaroo Mu: Basically I wanted to get feedback about the ideas we've been discussing for the last couple of weeks, see what people think.
• [2008/06/19 14:18] Rob Linden: well, there was a little bit of a conversation that happened internally on this. I don't think anyone could see the case for this being the next big area of rearchitecture, if I read things right
• [2008/06/19 14:18] Soft Linden: I think the take internally is that there's some skepticism about how much of a gain there would be from changing the storage format. Some small proof of concept, or some way of benchmarking that part that shows it's worth jumping all over a pretty fragile system would help a lot.
• [2008/06/19 14:18] Q Linden: I think our internal take on it was that we're doubtful it'll be a big win...and there are some technical challenges...yeah
• [2008/06/19 14:18] Buckaroo Mu: I don't necessarily see it as being a "big area of reachitecture", but I could be wrong.
• [2008/06/19 14:18] Rob Linden: it's on the list of stuff to do, and the Texture Cache page on the wiki pretty much sums up what we're still thinking
• [2008/06/19 14:19] Soft Linden: I'm not sure what the best way of buying support would be, what the easiest test to implement is
• [2008/06/19 14:19] Rob Linden: there's a lot of skepticism specifically about whether storing uncompressed images buys us much. certainly hard numbers that refute that bias would be appreciated
• [2008/06/19 14:19] Soft Linden: If anyone has guidance on that, it would be valuable
• [2008/06/19 14:20] Poppy Linden: it has been said that there isn't much analysis available
• [2008/06/19 14:20] Soft Linden: I think we've got lag - repeating each other :)
• [2008/06/19 14:20] Buckaroo Mu: Gotcha. I'll see if I can put something together just implimenting the uncompressed save.
• [2008/06/19 14:21] Rob Linden: those are generally the threads where Lindens have the toughest time jumping in.....when everyone on the list has a strong opinion, and no one at Linden really does (and is heads down on other stuff)
• [2008/06/19 14:21] Rob Linden: Buckaroo: any other questions, or should we move on?
• [2008/06/19 14:21] Carjay McGinnis: so it's a good opportunity to do some profiling and testing
• [2008/06/19 14:22] Buckaroo Mu: Moving right along :>
• [2008/06/19 14:22] Rob Linden: Brief plug of the AWG_Test_Harness and the meeting this morning at Zero's...Saijanai 13:31, 19 June 2008 (PDT)
• [2008/06/19 14:22] JB Kraft: i also have a small thing i'd like to throw rob, out b4 we wrap if i may please. didnt get it on the agenda :/
• [2008/06/19 14:22] Rob Linden: JB: sure, no prob....after this item
• [2008/06/19 14:22] Saijanai Kuhn: Enus is here so HE can talk about it... ;_)
• [2008/06/19 14:22] Enus Linden: go Sai go!
• [2008/06/19 14:22] JB Kraft: hehe, that came out well
• [2008/06/19 14:22] Enus Linden: grrr
• [2008/06/19 14:22] Saijanai Kuhn: lol.
• [2008/06/19 14:23] Saijanai Kuhn: OK, I'll pretend you're not here
• [2008/06/19 14:23] Enus Linden: https://wiki.secondlife.com/wiki/AWG_Test_Harness
• [2008/06/19 14:23] Soft Linden: Buckaroo - a fair way to benchmark that, on thinking - would be to pad the saved jpeg2000 files to be as big as raw files and read the entire block whenever reading one of those files. Then if you can measure the time spent reading and the time spent in jpeg2000 decoding, if you can demonstrate the former is smaller, you have something to go on.
• [2008/06/19 14:24] Soft Linden: That would get the disk overhead question out of the way.
• [2008/06/19 14:24] Rob Linden: Sai or Enus, anything specific you wanted to bring up?
• [2008/06/19 14:24] Saijanai Kuhn: Enus, Tao and I had a meeting yesterday to just get the ball rollling. We have the webpage, a svn, and an irc channel now.
• [2008/06/19 14:24] Saijanai Kuhn: Beyond that, just to answer questions if anyone has any.
• [2008/06/19 14:25] magnus Szczepanski: slt
• [2008/06/19 14:25] Saijanai Kuhn: the first meeting was held this morning at Zero's
• [2008/06/19 14:25] Buckaroo Mu: Well, have you read the discussion about the test I did with a ramdisk? Unless the read itself is horribly wasteful, it's GOT to be the decode - because retrieving textures from a DISK cache was almost exactly the same speed as retreiving from a RAMDisk based cache.
• [2008/06/19 14:25] Saijanai Kuhn: https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_June_19
• [2008/06/19 14:25] magnus Szczepanski: ce koi ce monde pourie
• [2008/06/19 14:26] magnus Szczepanski: slt ma plus belle du monde
• [2008/06/19 14:26] Saijanai Kuhn: Buckaroo how much of that disk cache sits in RAM though?
• [2008/06/19 14:27] magnus Szczepanski: qui veu vemire avec
• [2008/06/19 14:27] Buckaroo Mu: The disk cache? Or the RAMDisk cache? If you mean the RAMDisk, all of it. I upgraded from 1.5g to 3g, put a 1g ramdrive that does NOT get swapped up, and tried the cache on it. No difference.
• [2008/06/19 14:27] Soft Linden: Buckaroo - the question though - is on fluffing the cache up to 16x its size, or whatever the jpeg2000 vs raw ratio would be to cache a similar amount of data
• [2008/06/19 14:27] Saijanai Kuhn: the disk cache has a RAM component
• [2008/06/19 14:27] Buckaroo Mu: So it's not ike the ramdisk was getting swapped out, if that's what you mean\
• [2008/06/19 14:27] Soft Linden: Hence padding those stored jpeg2000 files out to their raw size and reading the full block for that test.
• [2008/06/19 14:27] Saijanai Kuhn: a buffer
• [2008/06/19 14:28] Squirrel Wood: Personally I don't care if SL decodes 100 textures per second or just 80 as long as the textures don't look blurry for ages.
• [2008/06/19 14:28] Buckaroo Mu: I see what you mean, and I understand - reading the extra data vs. the decode speed. I don't have hard numbers yet, I will work on that.
• [2008/06/19 14:29] Buckaroo Mu: That's thething - if we cache the decoded textures, they /won't/ be blurry.
• [2008/06/19 14:29] Carjay McGinnis: if they are properly cached that shouldn't happen
• [2008/06/19 14:29] Buckaroo Mu: I agree, it shouldn't. But it does.
• [2008/06/19 14:29] Squirrel Wood: They will still be blurry if you don't have all the mip levels cached
• [2008/06/19 14:30] Carjay McGinnis: well of course the cache should store the complete image file
• [2008/06/19 14:30] Poppy Linden: so Buckaroo - it sounds like you have done testing to isolate slowdown to decode. Have you found out why decode is so slow? is the in-memory cache throwing things out prematurely? I think that's more questionable than the disk.
• [2008/06/19 14:30] Poppy Linden: (but that may just be me)
• [2008/06/19 14:31] Buckaroo Mu: I have no idea, Poppy. I haven't gotten that deep yet.
• [2008/06/19 14:31] Poppy Linden: I'd really suggest that
• [2008/06/19 14:31] Soft Linden: jpeg2000 is just ass slow. Verrrrry computationally intensive.
• [2008/06/19 14:31] Carjay McGinnis: yes, that's true
• [2008/06/19 14:31] Poppy Linden: because looking into disk could wind up being pointless if the viewer is dropping the image from memory every half second for no reason or something like that
• [2008/06/19 14:31] Saijanai Kuhn: recalls strange L1/L2 cache interactions when doing certain Doom optimizations on a PPC vs INtel CPU. PPC port from Intel was 100x slower at first
• [2008/06/19 14:32] Carjay McGinnis: needs profiling
• [2008/06/19 14:32] Rob Linden: part of the theory that keeps us from being less enthusiastic about this is that disk i/o speeds aren't doubling every 18 months whereas processor speeds are
• [2008/06/19 14:32] Poppy Linden: i'm guessing it's not that bad :P
• [2008/06/19 14:32] Saijanai Kuhn: due to the striding of vertical "scanlines" that hit the exact size of a cache line on the PPC
• [2008/06/19 14:32] Carjay McGinnis: vertical scanlines?
• [2008/06/19 14:33] Saijanai Kuhn: Doom used a vertical line stretching algorithm to get its 3D scaling
• [2008/06/19 14:33] Poppy Linden: well, that's not my point. My point is there could be a glaring algorithmic error sitting on the memory cache. I'm not the person to be able to tell you if that's the case or not.
• [2008/06/19 14:33] Soft Linden: Same time though - RAM prices are falling like a rock. Your typical $500 PC comes with twice as much RAM as our biggest disk cache size at current.
• [2008/06/19 14:34] Poppy Linden: but if you can't say "that's not the case!" i'd avoid looking so hard at the disk just yet.
• [2008/06/19 14:34] Carjay McGinnis: well, you need 64 bit to take advantage of that really :)
• [2008/06/19 14:34] Saijanai Kuhn: all the bytes with the same Y value were scaled and a wall texture's vertical line spacing in memory happened to cause a cache miss for every byte
• [2008/06/19 14:34] Buckaroo Mu: That's an argument for another part of my plan - decoupling the texture cache from the VFS so that the sizes can be set independantly.
• [2008/06/19 14:34] Soft Linden: Yar, what Poppy says is true too. It's worth maybe logging what textures are being decoded, and making sure the same textures aren't coming up repeatedly in a short interval. You could add a log line to the decode with the time and asset ID, then answer that quickly with a shell script.
• [2008/06/19 14:34] Poppy Linden: Something like that, at least.
• [2008/06/19 14:35] Carjay McGinnis: would be a good idea to track the life of a texture
• [2008/06/19 14:35] Poppy Linden: I'd say it's a prereq to this work, more than just a "good idea" :P
• [2008/06/19 14:35] Rob Linden: would love to see someone look at 2Q
• [2008/06/19 14:35] Saijanai Kuhn: X value, not Y value. sigh
• [2008/06/19 14:36] Pixie Tungl: sorry .. passing through :P
• [2008/06/19 14:36] Rob Linden: ....er rather, prototype 2Q
• [2008/06/19 14:36] Boroondas Gupte: "2Q"?
• [2008/06/19 14:37] Saijanai Kuhn: second quarter
• [2008/06/19 14:37] Buckaroo Mu: Cache discard algorithm
• [2008/06/19 14:37] Rob Linden: see https://wiki.secondlife.com/wiki/Texture_Cache
• [2008/06/19 14:37] Boroondas Gupte: ah
• [2008/06/19 14:37] Saijanai Kuhn: sec ond half of year, sorry
• [2008/06/19 14:37] Saijanai Kuhn: right the first time.
• [2008/06/19 14:37] Poppy Linden: but yeah'
• [2008/06/19 14:37] Saijanai Kuhn: is having wetwear cache errors
• [2008/06/19 14:37] Poppy Linden: i think that's the kind of analysis needed before any cache work
• [2008/06/19 14:38] Poppy Linden: not necessarily disk analysis.
• [2008/06/19 14:38] Carjay McGinnis: hm, 2Q
• [2008/06/19 14:39] Carjay McGinnis: is it put in use anywhere?
• [2008/06/19 14:39] Buckaroo Mu: Not yet. Well, not yet in the SL viewr.
• [2008/06/19 14:39] Rob Linden: Carjay: yeah, PostgreSQL, and maybe MySQL too (I can't remember for sure)
• [2008/06/19 14:39] Rob Linden: lots of other places
• [2008/06/19 14:39] Carjay McGinnis: ah, oh, I wasn't talking about the SL viewer, just in general, Buckaroo
• [2008/06/19 14:40] Carjay McGinnis: ah, ok, so it really works :)
• [2008/06/19 14:40] Rob Linden: yeah, it's not bleeding edge
• [2008/06/19 14:41] Squirrel Wood: sqlite + cache ?
• [2008/06/19 14:41] Poppy Linden:  ?
• [2008/06/19 14:41] Poppy Linden: i'm lost
• [2008/06/19 14:42] Rob Linden: basically, from what I nderstand, it was once fashionable to try to improve on LRU, then it became clear that in most cases, everyone was overthinking the problem, then people gave up for a while, then people said "oh, wait, you can improve on LRU"
• [2008/06/19 14:42] Boroondas Gupte: too
• [2008/06/19 14:42] Buckaroo Mu: I have a question that has no real relation to the OSing of the client - but does to the texture pipeline. Is there any word on implimentation of assets (particularly textures) over HTTP, any kind of very very rough timeline?
• [2008/06/19 14:42] Q Linden: Is anyone expecting that changing from LRU to $(SOMETHINGSLIGHTLYBETTER) would actually be noticeable?
• [2008/06/19 14:43] Saijanai Kuhn: premature optimization, perhap? Do we know yet if that is where the slowdown takes place?
• [2008/06/19 14:43] Rob Linden: Q: I think that was the topic of great debate last year after people complained about visiting one place, teleporting away, and teleporting back, and having the cache completely starting over
• [2008/06/19 14:44] Rob Linden: however, I suppose that debate has died down, and now it's just about raw disk space
• [2008/06/19 14:44] Saijanai Kuhn: sounds like its broke, rather than unoptimized
• [2008/06/19 14:44] Buckaroo Mu: Maybe region-based caches with LRUs for each, then a LRU that tracks which region was LRU :P
• [2008/06/19 14:44] Poppy Linden: it's not really sounding like anyone knows *for sure* how any of this works here
• [2008/06/19 14:44] Q Linden: ok...seems like instrumenting the cache would be useful
• [2008/06/19 14:44] Carjay McGinnis: well :)
• [2008/06/19 14:45] Carjay McGinnis: yes, I'd really like to see what goes on in the cache
• [2008/06/19 14:45] Buckaroo Mu: Agreed
• [2008/06/19 14:45] Carjay McGinnis: maybe it's not even used at all *g*
• [2008/06/19 14:46] Poppy Linden: and the texture cache page is pretty small, and mostly about the disk format
• [2008/06/19 14:46] Rob Linden: yeah, we should probably move on. I think the takeaway is that more study is needed
• [2008/06/19 14:46] Buckaroo Mu: I still ahven't figured out why mine clears itself every time I log in :P But that's neither here nor there.
• [2008/06/19 14:46] Poppy Linden: it'd be great to see on that page or neighboring pages algorithmic analysis and statistic on usage / paging out / etc
• [2008/06/19 14:46] Rob Linden: JB: what was your topic?
• [2008/06/19 14:47] Carjay McGinnis: agreed, Poppy
• [2008/06/19 14:47] JB Kraft: thx rob, briefly, posted a thread on dev "Viewer inventory management: duplicate/clone tool" which i would love to get feedback (esp Linden) wrt to the merits/insanity of its pursuit. basically a tab in the veiwer inv view that filtered on dupe refs to single UUIDS
• [2008/06/19 14:48] Buckaroo Mu: I'd love to see that- and at the same time, I'd love to have an "alias" ability in inventory, so that for instance, I can put an alias to my no-copy shoes in each outfit folder.
• [2008/06/19 14:48] Wilton Lundquist: So it would show a list with counts?
• [2008/06/19 14:48] Carjay McGinnis: I didn't even know there could be dupes
• [2008/06/19 14:49] JB Kraft: something like that yes wilton
• [2008/06/19 14:49] Buckaroo Mu: Sure, you could have more than one copy of the same texture.
• [2008/06/19 14:49] Q Linden: Textures yes, because they're not editable
• [2008/06/19 14:49] Saijanai Kuhn: Ipointed out the possible issue with sending a thousand updates to the asset server if you ran that thing
• [2008/06/19 14:49] JB Kraft: they are just refs, but they cause load nonetheless i would think at both ends
• [2008/06/19 14:50] Carjay McGinnis: ok, so rather 2 links that point to the same asset
• [2008/06/19 14:50] JB Kraft: sia, i was thing not batched as much as user making the deletions, its just another view im my mind
• [2008/06/19 14:50] Saijanai Kuhn: I may be wrong, but I *think* the way folders work is that everytme you edit the contents, it updates teh asset server for each edit
• [2008/06/19 14:50] Rob Linden: reading JB's email: on the question of "is this worthy of a JIRA", yes, feel free to file a feature request....that's a great place for discussion
• [2008/06/19 14:51] Saijanai Kuhn: so you'd have to make sure you could cache the update requests or some people would send thousands of delete messages, one at a time
• [2008/06/19 14:51] Wilton Lundquist: I'm sure the feature would get used. I recently squashed 20 copies of the same LM in inventory, for instance.
• [2008/06/19 14:51] Q Linden: saj: the inventory database is separate from the asset server -- but yes, it's maintained server-side
• [2008/06/19 14:52] JB Kraft: ok rob, i shall take it there. just checking it made sense at all :)
• [2008/06/19 14:52] Rob Linden: I suspect it's going to be a good thing to discuss on the newly formed sl-ux mailing list
• [2008/06/19 14:52] Saijanai Kuhn: and the folder (I think) sends an update with each edit to the content
• [2008/06/19 14:52] Wilton Lundquist: sl-ux?
• [2008/06/19 14:52] Rob Linden: ux=user experience. talk about UI stuff
• [2008/06/19 14:54] Rob Linden: Benjamin Linden is following that list more closely than sldev. the pushback in including such a feature in the mainline client would be one of complexity, I think
• [2008/06/19 14:54] Carjay McGinnis: a delicate area
• [2008/06/19 14:54] Rob Linden: JB: I recommend you file the featre request in JIRA, let sldev know you've done that, and then bring up the topic on sl-ux
• [2008/06/19 14:55] JB Kraft: ill flesh out more technically what i am thinking in the JIRA. i dont see it as much more then deleting a whle folder of stuff, same load
• [2008/06/19 14:55] Wilton Lundquist: An odd idea, but maybe implementing the feature via a web page ... spitballing here.
• [2008/06/19 14:55] Saijanai Kuhn: inventory folder class is in a separate hierachy from the list items class (whatever thy are called) not designed for simple modification, either of them
• [2008/06/19 14:55] Saijanai Kuhn: JB not sure. Folder keep track of their own inventory. Perhaps they can say ":delete me to the inventory database.
• [2008/06/19 14:56] Saijanai Kuhn: its a single UUID for a folder
• [2008/06/19 14:56] JB Kraft: yes, indeed i could be wrong there sai, i see what you are saying
• [2008/06/19 14:56] Frankie Antonioni: About os, if you go from one world to another,can you take your items with you?
• [2008/06/19 14:56] Rob Linden: we're running low on time, so I'd like to point out the Battery Street Irregulars kiosk behind me
• [2008/06/19 14:57] Squirrel Wood: Battery Street Irregulars: Missing inventory item
• [2008/06/19 14:57] Rob Linden: the Battery Street Irregulars is a group that is going to be doing testing of nightly builds off of the RC branch
• [2008/06/19 14:58] Q Linden: saj...I've just been thinking about the duplicates folder, and I keep coming up with a logical contradiction. Don't want to hijack the meeting, but we should chat after
• [2008/06/19 14:58] Buckaroo Mu: put his info into the kiosk
• [2008/06/19 14:58] Harleen Gretzky: I'll send you the missing notecard
• [2008/06/19 14:58] Saijanai Kuhn: Sure. Not sure either way. I was trying to modify the folders to handle non-inventory items and that was the issue I ran into
• [2008/06/19 14:58] Squirrel Wood: Any easy way to "filter" out dupes in your inventory which may be named different?
• [2008/06/19 14:59] Rob Linden: any quick items before we go?
• [2008/06/19 14:59] Saijanai Kuhn: Dale Glass said he'd modified the folder classes to avoid sending updates, so perhaps he knows how to do it
• [2008/06/19 14:59] JB Kraft: squirrel, thats what im after in the end
• [2008/06/19 14:59] Squirrel Wood: ^^
• [2008/06/19 14:59] Wilton Lundquist: Irregulars - Testing as in using test scripts, or just going about things as normal? Are these RCs likely to be ~stable?
• [2008/06/19 15:00] Rob Linden: Wilton, they won't be as stable as the RCs themselves, but the idea is they're in the ballpark
• [2008/06/19 15:00] Rob Linden: they are RC RCs :)
• [2008/06/19 15:01] Wilton Lundquist: I see. Thanks
• [2008/06/19 15:01] Kiosk: SL: Open Source General Info whispers: Thank you! Your items will be delivered to you soon!
• [2008/06/19 15:01] Poppy Linden: it's been great folks - ttyl!
• [2008/06/19 15:01] Rob Linden: ok....thanks everyone for showing up!
• [2008/06/19 15:01] Carjay McGinnis: thanks
• [2008/06/19 15:01] JB Kraft: cheers!
• [2008/06/19 15:01] Harleen Gretzky: ttfn