From johnniecarling at gmail.com Sun Jun 1 01:41:40 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Sun Jun 1 01:41:45 2008 Subject: [sldev] GPL violation? Message-ID: <200806010441.41299.johnniecarling@gmail.com> Looks like somebody is selling a modified copy of the SL Viewer (the "NakedLife Viewer") http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 or secondlife://Vendetta/145/180/30 in world. interesting license terms they have. ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT You expressly agree that, by using this viewer, it is to be used in accordance of, and in compliance with, the Second Life Terms of Service Agreement, and any National, State, or Local laws. This may be up to, and including, consent of the parties you choose to view in this manner. It is the express responsibility of any user of this software to ensure compliance with the aforementioned. By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited. Failure to comply with the foregoing will result in immediate revocation of the limited license. Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF LICENSOR From danteferret at gmail.com Sun Jun 1 02:00:13 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sun Jun 1 02:00:15 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > or secondlife://Vendetta/145/180/30 in world. > > interesting license terms they have. > > ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT > You expressly agree that, by using this viewer, it is to be used in > accordance > of, and in compliance with, the Second Life Terms of Service Agreement, and > any National, State, or Local laws. This may be up to, and including, > consent > of the parties you choose to view in this manner. It is the express > responsibility of any user of this software to ensure compliance with the > aforementioned. By purchasing this software, you are using the same under a > limited license agreement. Any additional duplication, distribution, or > modification of this software is expressly prohibited. Failure to comply > with > the foregoing will result in immediate revocation of the limited license. > Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF > LICENSOR > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/f61e4b44/attachment.htm From darien_caldwell at comcast.net Sun Jun 1 02:12:27 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Sun Jun 1 02:12:24 2008 Subject: [sldev] GPL violation? References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> Message-ID: <001d01c8c3c7$9d6db4e0$667ba8c0@a644000> Many games have 'naked' patches for them, i'm frankly not suprised someone did this with SL. I just wonder how they get the skin texture without clothes, doesn't each person's client send a baked composite of all layers? ----- Original Message ----- From: Dante Tucker To: Johnnie Carling Cc: sldev Sent: Sunday, June 01, 2008 2:00 AM Subject: Re: [sldev] GPL violation? I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling wrote: Looks like somebody is selling a modified copy of the SL Viewer (the "NakedLife Viewer") http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 or secondlife://Vendetta/145/180/30 in world. interesting license terms they have. ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT You expressly agree that, by using this viewer, it is to be used in accordance of, and in compliance with, the Second Life Terms of Service Agreement, and any National, State, or Local laws. This may be up to, and including, consent of the parties you choose to view in this manner. It is the express responsibility of any user of this software to ensure compliance with the aforementioned. By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited. Failure to comply with the foregoing will result in immediate revocation of the limited license. Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF LICENSOR _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/aaef2abf/attachment-0001.htm From robin.cornelius at gmail.com Sun Jun 1 02:44:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Jun 1 02:44:51 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <48426F8A.9030904@gmail.com> Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") I love this too "* The ability to browse in websites, the NakedLife viewer is connecting to a database in order to check for updates and authenticate your product." Goodbye privacy, goodbye passwords -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080601/cab2342e/signature.pgp From qieniangao at gmail.com Sun Jun 1 05:24:12 2008 From: qieniangao at gmail.com (Qie Niangao) Date: Sun Jun 1 05:24:16 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> I've been trying to keep quiet about this (mostly), because I thought it was just an innocent waste of time, kludging onto the UI something more flexibly implemented by script (once LSL gets features again), but now NAV has me scared. If there is indeed a *hint* of a long-term objective to remove LMs from Inventory, then that implies they'd no longer be first-class assets, which in turn means they'd no longer be available to scripts nor containable in objects. And all this for the grossly flawed and depressingly self-limiting Viewer=Browser analogy. Please stop NAV. Seriously, just stop. This is on a path to break much, much more than it fixes. Re-assess what's actually needed for Landmarks (mostly, they need structured content available to LSL, and availability from Profile Picks). Try not to fall victim to the Viewer=Browser canard. (E.g., the very last thing we need is to be whacking the grid with "Back" / "Next" TP buttons!) Then, before any UI design starts, make sure any changes apply to all asset types and operations on all Inventory classes. It's fine to use Landmarks as a test case, but it should test something that actually matters. From tom at streamsense.net Sun Jun 1 06:44:00 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Sun Jun 1 06:45:15 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <4842A7A0.9040205@streamsense.net> I have filed a complaint to SLExchange, and I have also lodged an abuse report inworld (secondlife://Vendetta/145/180/30). In no terms is this product legal, I suggest others do the same. ~Tom Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > or secondlife://Vendetta/145/180/30 in world. > tps://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cenji.neutra at gmail.com Sun Jun 1 07:17:19 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Sun Jun 1 07:17:25 2008 Subject: [sldev] GPL violation? Message-ID: > From: "Dante Tucker" > To: "Johnnie Carling" > Date: Sun, 1 Jun 2008 05:00:13 -0400 > Subject: Re: [sldev] GPL violation? > I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. Not sure which aspect you're referring to when you say "clear this is not allowed" Dante, but I know that the GPL certainly allows the sale of derivative works (binary and/or source). That's part of the 'freedom' granted in all Free Software licenses. However, if you purchase a copy then you're entitled to the source of their modifications (according to the GPL license). So, if you do purchase a copy, ask them for the source of their changes and they won't give them to you - then they are in violation of the GPL license terms. You're also within your right to resell or give away that viewer too (source included of course). From anthonyrbundy at gmail.com Sun Jun 1 07:31:17 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Jun 1 07:31:16 2008 Subject: [sldev] GPL violation? In-Reply-To: <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> Message-ID: <4842B2B5.2050309@gmail.com> Could someone explain to me why this violates GPL? I'm not saying that something like this doesn't go against some other rules (like TOS or community standards), and I'm definitely not supporting it as a product, but I'm not sure why it was brought up as a GPL violation? As long as any modifications they make are available for the original source (for free), and that the source of their product is available when requested, isn't it following GPL? I only bring it up because I want to understand GPL a bit better. Tony Dante Tucker wrote: > I don't even remotly understand the viewers license terms. But I would > think it is clear this is not allowed. > > On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling > > wrote: > > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > > or secondlife://Vendetta/145/180/30 in world. > > interesting license terms they have. > > ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT > You expressly agree that, by using this viewer, it is to be used > in accordance > of, and in compliance with, the Second Life Terms of Service > Agreement, and > any National, State, or Local laws. This may be up to, and > including, consent > of the parties you choose to view in this manner. It is the express > responsibility of any user of this software to ensure compliance > with the > aforementioned. By purchasing this software, you are using the > same under a > limited license agreement. Any additional duplication, > distribution, or > modification of this software is expressly prohibited. Failure to > comply with > the foregoing will result in immediate revocation of the limited > license. > Such revocation will be without compensation. REFUNDS AT SOLE > DISCRETION OF > LICENSOR > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From ordinal.malaprop at fastmail.fm Sun Jun 1 08:15:03 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sun Jun 1 08:15:08 2008 Subject: [sldev] GPL violation? In-Reply-To: <4842B2B5.2050309@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: It says "By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited." Those would seem to me to count as further restrictions incompatible with the rights granted by the GPL ("Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.") so they would be in breach of the GPL by conveying the product with those restrictions. On 1 Jun 2008, at 15:31, Tony wrote: > Could someone explain to me why this violates GPL? > > I'm not saying that something like this doesn't go against some > other rules (like TOS or community standards), and I'm definitely > not supporting it as a product, but I'm not sure why it was brought > up as a GPL violation? > As long as any modifications they make are available for the > original source (for free), and that the source of their product is > available when requested, isn't it following GPL? > I only bring it up because I want to understand GPL a bit better. > > Tony From sakkaku at gmail.com Sun Jun 1 08:29:33 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Sun Jun 1 08:29:36 2008 Subject: [sldev] GPL violation? In-Reply-To: <4842B2B5.2050309@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> On Sun, Jun 1, 2008 at 9:31 AM, Tony wrote: > Could someone explain to me why this violates GPL? > > I'm not saying that something like this doesn't go against some other rules > (like TOS or community standards), and I'm definitely not supporting it as a > product, but I'm not sure why it was brought up as a GPL violation? > As long as any modifications they make are available for the original source > (for free), and that the source of their product is available when > requested, isn't it following GPL? > I only bring it up because I want to understand GPL a bit better. > > Tony > Under the GPL any derivative works have to release the source (they can charge up to the cost of the binary form tho). So if you release a 3k viewer, then you could theoretically charge 3k for the source too, but you still have to have the source available. Read the license, it is well written and you need to know what your getting into if you do commercial development. From anthonyrbundy at gmail.com Sun Jun 1 09:43:57 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Jun 1 09:43:56 2008 Subject: [sldev] GPL violation? In-Reply-To: References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: <4842D1CD.4020306@gmail.com> Ahh, I see. Yes that definitely conflicts with the original GPL which cannot be modified. I should have read their own license a bit closer. I wonder if their distribution includes the original license at all then... ordinal.malaprop@fastmail.fm wrote: > It says "By purchasing this software, you are using the same under a > limited license agreement. Any additional duplication, distribution, > or modification of this software is expressly prohibited." Those would > seem to me to count as further restrictions incompatible with the > rights granted by the GPL ("Each time you convey a covered work, the > recipient automatically receives a license from the original > licensors, to run, modify and propagate that work, subject to this > License.") so they would be in breach of the GPL by conveying the > product with those restrictions. > > > On 1 Jun 2008, at 15:31, Tony wrote: > >> Could someone explain to me why this violates GPL? >> >> I'm not saying that something like this doesn't go against some other >> rules (like TOS or community standards), and I'm definitely not >> supporting it as a product, but I'm not sure why it was brought up >> as a GPL violation? >> As long as any modifications they make are available for the original >> source (for free), and that the source of their product is available >> when requested, isn't it following GPL? >> I only bring it up because I want to understand GPL a bit better. >> >> Tony > > From secret.argent at gmail.com Sun Jun 1 09:51:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 09:50:07 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On 2008-06-01, at 09:17, Cenji Neutra wrote: > Not sure which aspect you're referring to when you say "clear this > is not allowed" Dante, but I know that the GPL certainly allows the > sale of derivative works (binary and/or source). But it doesn't allow you to add additional restrictions to the license. Their restriction to a single avatar is clearly in violation. From danteferret at gmail.com Sun Jun 1 10:33:47 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sun Jun 1 10:33:49 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: <4d211a610806011033w2d46491dw1301fb140ee5a4c5@mail.gmail.com> Just to be clear. I was taking into account the fact that the seller is refusing to give out the source in my assessment of "what is allowed". On Sun, Jun 1, 2008 at 10:17 AM, Cenji Neutra wrote: > > From: "Dante Tucker" > > To: "Johnnie Carling" > > Date: Sun, 1 Jun 2008 05:00:13 -0400 > > Subject: Re: [sldev] GPL violation? > > I don't even remotly understand the viewers license terms. But I would > think it is clear this is not allowed. > > Not sure which aspect you're referring to when you say "clear this is > not allowed" Dante, but I know that the > GPL certainly allows the sale of derivative works (binary and/or > source). That's part of the 'freedom' granted in > all Free Software licenses. However, if you purchase a copy then > you're entitled to the source of their > modifications (according to the GPL license). So, if you do purchase > a copy, ask them for the source of > their changes and they won't give them to you - then they are in > violation of the GPL license terms. > You're also within your right to resell or give away that viewer too > (source included of course). > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/3e9a7c66/attachment.htm From soft at lindenlab.com Sun Jun 1 10:54:58 2008 From: soft at lindenlab.com (Soft) Date: Sun Jun 1 10:55:00 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On Sun, Jun 1, 2008 at 11:51 AM, Argent Stonecutter wrote: > On 2008-06-01, at 09:17, Cenji Neutra wrote: >> >> Not sure which aspect you're referring to when you say "clear this is not >> allowed" Dante, but I know that the GPL certainly allows the sale of >> derivative works (binary and/or source). > > But it doesn't allow you to add additional restrictions to the license. > Their restriction to a single avatar is clearly in violation. We definitely haven't granted a closed license to a naked avatar viewer if that's the question here. If anyone who has a patch in the viewer has already contacted the person offering this viewer, please consider forwarding any response you receive to our legal eagles. You have just as much standing to engage them about any GPL violation as we have, and may have the freedom to move more quickly here. But please do start with an attempt to educate, as they may not realize it if they really are violating the only license that would allow them to redistribute our/your work. The goal should be correcting the situation, not piling on. From apotheus at slexchange.com Sun Jun 1 11:48:28 2008 From: apotheus at slexchange.com (Apotheus Silverman) Date: Sun Jun 1 11:48:32 2008 Subject: [sldev] Email from external servers to LSL scripts failing? Message-ID: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> Hi all, This isn't exactly a development-related issue, but this seems to be the best place to ask where others might have similar experience. I'm curious if anyone else is having this problem. For the past 2.5 days or so our mail server is getting near 100% read timeouts and connect timeouts from data.agni.lindenlab.com when trying to send email to scripted objects. I called the concierge line and was told that they are aware of an issue, but the rep assured me the problem isn't widespread. It's now a day later and my server logs say otherwise. Is anyone else seeing this problem? Is anyone *not* seeing it? -- Regards, Jay Geeseman (AKA Apotheus Silverman in Second Life) SL Exchange, http://www.slexchange.com/ From robin.cornelius at gmail.com Sun Jun 1 12:03:48 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Jun 1 12:03:52 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On 6/1/08, Argent Stonecutter wrote: > On 2008-06-01, at 09:17, Cenji Neutra wrote: > > Not sure which aspect you're referring to when you say "clear this is not > allowed" Dante, but I know that the GPL certainly allows the sale of > derivative works (binary and/or source). > > > > But it doesn't allow you to add additional restrictions to the license. > Their restriction to a single avatar is clearly in violation. > Not just the single avatar but the following statement:- "Any additional duplication, distribution, or modification of this software is expressly prohibited" This is clearly a MASSIVE licence change and goes against everything the GPL stands for (not that you can make any licence change with out the copyright holders agreement) but this is particuary bad. Robin From apotheus at slexchange.com Sun Jun 1 12:06:16 2008 From: apotheus at slexchange.com (Apotheus Silverman) Date: Sun Jun 1 12:06:19 2008 Subject: [sldev] Re: Email from external servers to LSL scripts failing? In-Reply-To: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> References: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> Message-ID: <47322fe00806011206x73f31c82g6e01772c093a6172@mail.gmail.com> Wrong list. Sorry about that. :-/ On Sun, Jun 1, 2008 at 2:48 PM, Apotheus Silverman wrote: > Hi all, > > This isn't exactly a development-related issue, but this seems to be > the best place to ask where others might have similar experience. > > I'm curious if anyone else is having this problem. For the past 2.5 > days or so our mail server is getting near 100% read timeouts and > connect timeouts from data.agni.lindenlab.com when trying to send > email to scripted objects. I called the concierge line and was told > that they are aware of an issue, but the rep assured me the problem > isn't widespread. It's now a day later and my server logs say > otherwise. > > Is anyone else seeing this problem? Is anyone *not* seeing it? > > -- > Regards, > > Jay Geeseman (AKA Apotheus Silverman in Second Life) > SL Exchange, http://www.slexchange.com/ > From secret.argent at gmail.com Sun Jun 1 12:52:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 12:51:13 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: I think that it might be worthwhile to bring up plugin APIs, in particular plugin APIs that could be used by commercial software. There's a sticky situation here, because the GPL does not exclude plugin APIs... only APIs that are shipped with the OS the software it's running on (what could be called the libc exception, since that's one of the big reasons it was originally created... to allow GCC to be used on operating systems where it needed to use the standard C library provided by the OS). The reason for this is that otherwise you could use a "null" plugin as a general cutout to link *anything* to GPLed code, reducing the GPL to the LGPL. This in theory extends to Flash content on prims or in the in-world browser, and to Quicktime (if you're building the GPLed client you can't use the quicktime libraries because Quicktime isn't shipped with Windows), and who knows what else. I think LL needs to come up with some kind of explicit exception, like the FOSS exception, for SOME kind of plugin API, or else explicitly rule out plugins for GPL clients. From jacek.antonelli at gmail.com Sun Jun 1 13:24:45 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sun Jun 1 13:24:48 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> Message-ID: <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> On Sun, Jun 1, 2008 at 7:24 AM, Qie Niangao wrote: > If there is indeed a *hint* of a long-term > objective to remove LMs from Inventory, then that implies they'd no > longer be first-class assets, which in turn means they'd no longer be > available to scripts nor containable in objects. Ugh. Sorry, but it often upsets me when someone starts an obviously unfounded rumour ("Landmarks are going to be removed from inventory omgz!") and then it catches on and turns into hysteria. I've been closely following the Nav & LM project since it was first announced. I've been attending the meetings where it's discussed, and talking directly with the Vectorform people working on the project. So let me say, with full certainty based on all the knowledge I have of this project, that there is NO PLAN TO REMOVE LMs FROM INVENTORY, neither in the short term nor the long term. There was, at the first meeting, the _question_ "Should LMs be removed from inventory?" -- gathering input from Residents. It was swiftly objected to by myself and other Residents, for all the reasons people have given here on the mailing list. The fact that they sought to gather feedback about a topic does not constitute a plan. Believe me, if there was any indication that they _were_ planning to do anything of the sort, I would raise hell until they changed thier minds ;-P. But there's not. No plan. Not removing LMs from inventory. Capiche? In fact, one of their stated objectives on the wiki page is: "Backward compatibility: Everything we do must be backward compatible and seamlessly integrated with the existing system (with all of the scripted objects in IW stores right now, for example). To ensure backward compatibility, conducting a sort of "inventory assessment" on Landmark functionality IW will be necessary." See < http://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project#Requirements > It would be helpful if someone from Vectorform could step in and give an official word that removing LM from inventory is not on the agenda, and maybe we can quash this rumor before it gets out of hand. > Then, before any UI design starts, make sure any changes apply to all > asset types and operations on all Inventory classes. It's fine to use > Landmarks as a test case, but it should test something that actually > matters. One step at a time, I say. The current plan, which is still not finalized, involves a number of useful new features which could later be extended to inventory items in general: 1. An easier way to organize and manage them in inventory folders as you create / receive them. 2. A space for your own comments / description (in addition to creator-set description, I believe), which might become searchable in the future. 3. A space for tags, which also might become searchable. Honestly, I'd rather have them testing this out on a relatively minor feature -- if it breaks, I'd rather have Landmarks not working for a few days, than having objects, scripts, or clothing not working! Once the wrinkles are ironed out and it seems to be working well, then it could be extended to other inventory types. But that's outside the scope of the current project. - Jacek From kwerks.sl at gmail.com Sun Jun 1 13:28:15 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Sun Jun 1 13:28:22 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> IANAL, but the unofficial FAQ seems to attempt to account for this usage https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ On Sun, Jun 1, 2008 at 3:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. > > There's a sticky situation here, because the GPL does not exclude plugin > APIs... only APIs that are shipped with the OS the software it's running on > (what could be called the libc exception, since that's one of the big > reasons it was originally created... to allow GCC to be used on operating > systems where it needed to use the standard C library provided by the OS). > The reason for this is that otherwise you could use a "null" plugin as a > general cutout to link *anything* to GPLed code, reducing the GPL to the > LGPL. > > This in theory extends to Flash content on prims or in the in-world > browser, and to Quicktime (if you're building the GPLed client you can't use > the quicktime libraries because Quicktime isn't shipped with Windows), and > who knows what else. > > I think LL needs to come up with some kind of explicit exception, like the > FOSS exception, for SOME kind of plugin API, or else explicitly rule out > plugins for GPL clients. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/5a092c35/attachment.htm From sakkaku at gmail.com Sun Jun 1 14:06:17 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Sun Jun 1 14:06:19 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> On Sun, Jun 1, 2008 at 3:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. > > There's a sticky situation here, because the GPL does not exclude plugin > APIs... only APIs that are shipped with the OS the software it's running on > (what could be called the libc exception, since that's one of the big > reasons it was originally created... to allow GCC to be used on operating > systems where it needed to use the standard C library provided by the OS). > The reason for this is that otherwise you could use a "null" plugin as a > general cutout to link *anything* to GPLed code, reducing the GPL to the > LGPL. > > This in theory extends to Flash content on prims or in the in-world browser, > and to Quicktime (if you're building the GPLed client you can't use the > quicktime libraries because Quicktime isn't shipped with Windows), and who > knows what else. > > I think LL needs to come up with some kind of explicit exception, like the > FOSS exception, for SOME kind of plugin API, or else explicitly rule out > plugins for GPL clients. > For the most part the GPL allows you to use GPL'd code so long as you do not actually "include" that code into your binary with the exclusion of language libraries (like the c standard libraries). You can make an executable around a library then pipe data between your closed source program and the wrapped library, provided you release the wrapper containing GPL'd code as open source. You can get around the GPL, by buying rights to the library from the developers (as they still have the rights to it) or going through rather interesting schemes, but it is designed to make FOSS easy and commercial (closed source) hell. The idea is that open source apps get a free ride while commercial applications will need to fork out the dough (like they normally would anyway). From jay_reynolds_freeman at mac.com Sun Jun 1 15:17:35 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sun Jun 1 15:17:40 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> Message-ID: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> So I have been looking at the SL Viewer Architecture Wiki, and babbling a bit as I page through 600 000 lines of source code, trying to learn about the whens, hows, and wherefores of information about objects in SL, that are near the agent, being downloaded to the client. Stuff in the wiki is rather thin, but there are several possibly promising pages that seem to be limited to group access; they include the pages for Culling, Groups, and the Rendering System. Alas, the wiki also seems not entirely clear on what group can access them, or how to go about joining it. I have a project in which it would be nice to modify the client to make available a list of non-phantom SL objects that are near the agent, and I am not sure where to start to create such a list, or what is available by way of a starting point. (I won't waste bandwidth with what I would do with such a list if I had it unless someone is interested.) Any tips to documentation or to useful functions or data structures in the code itself would be much appreciated. Or, tips on how to gain access to those wiki pages ... -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From stephany at lindenlab.com Sun Jun 1 16:13:41 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Sun Jun 1 16:13:44 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> Message-ID: <48432D25.7020300@lindenlab.com> Hi everyone, Thanks for providing more background and history on the project, Jacek. At this moment in time, removing Landmarks from the inventory is NOT on our list of things to do as part of this project. I apologize for any confusion or concern that our earlier wiki comments (from our first meeting, as Jacek noted) may have caused. Stephany Jacek Antonelli wrote: > On Sun, Jun 1, 2008 at 7:24 AM, Qie Niangao wrote: > >> If there is indeed a *hint* of a long-term >> objective to remove LMs from Inventory, then that implies they'd no >> longer be first-class assets, which in turn means they'd no longer be >> available to scripts nor containable in objects. >> > > Ugh. Sorry, but it often upsets me when someone starts an obviously > unfounded rumour ("Landmarks are going to be removed from inventory > omgz!") and then it catches on and turns into hysteria. > > I've been closely following the Nav & LM project since it was first > announced. I've been attending the meetings where it's discussed, and > talking directly with the Vectorform people working on the project. So > let me say, with full certainty based on all the knowledge I have of > this project, that there is NO PLAN TO REMOVE LMs FROM INVENTORY, > neither in the short term nor the long term. > > There was, at the first meeting, the _question_ "Should LMs be removed > from inventory?" -- gathering input from Residents. It was swiftly > objected to by myself and other Residents, for all the reasons people > have given here on the mailing list. The fact that they sought to > gather feedback about a topic does not constitute a plan. Believe me, > if there was any indication that they _were_ planning to do anything > of the sort, I would raise hell until they changed thier minds ;-P. > But there's not. No plan. Not removing LMs from inventory. Capiche? > > In fact, one of their stated objectives on the wiki page is: "Backward > compatibility: Everything we do must be backward compatible and > seamlessly integrated with the existing system (with all of the > scripted objects in IW stores right now, for example). To ensure > backward compatibility, conducting a sort of "inventory assessment" on > Landmark functionality IW will be necessary." > > See < http://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project#Requirements > > > It would be helpful if someone from Vectorform could step in and give > an official word that removing LM from inventory is not on the agenda, > and maybe we can quash this rumor before it gets out of hand. > > >> Then, before any UI design starts, make sure any changes apply to all >> asset types and operations on all Inventory classes. It's fine to use >> Landmarks as a test case, but it should test something that actually >> matters. >> > > One step at a time, I say. The current plan, which is still not > finalized, involves a number of useful new features which could later > be extended to inventory items in general: > > 1. An easier way to organize and manage them in inventory folders as > you create / receive them. > 2. A space for your own comments / description (in addition to > creator-set description, I believe), which might become searchable in > the future. > 3. A space for tags, which also might become searchable. > > Honestly, I'd rather have them testing this out on a relatively minor > feature -- if it breaks, I'd rather have Landmarks not working for a > few days, than having objects, scripts, or clothing not working! Once > the wrinkles are ironed out and it seems to be working well, then it > could be extended to other inventory types. But that's outside the > scope of the current project. > > - Jacek > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/06eb8f84/attachment.htm From t8 at pobox.com Sun Jun 1 17:26:41 2008 From: t8 at pobox.com (Sato Meiji) Date: Sun Jun 1 17:26:44 2008 Subject: [sldev] Standard grid identifier string? Message-ID: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Does anyone know if there is a standard way to identify a grid in a human readable way? (i.e. a string). Not just the SL grids (main, beta etc) but a way that would include other VW grids? For SL and opensim-based grids I was considering: 1) Using the shard (as reported by the HTTP X_SECONDLIFE_SHARD header) and domain, such as "production.secondlife.com", "testing.secondlife.com", " production.centralgrid.com" etc 2) Using something like agni.secondlife.com Note in both cases they don't need to be valid domains (I'm using them as a human readable 'relm' specifiers) Is there a defacto way LL uses internally (or in the SL protocols) to identify grids? What about those out there who've recently added 3rd-party grid support to the viewer - how are grids identified in config files etc? Just wondered if there is an 'accepted' way in use or one emerging before I reinvent things. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/d5e86756/attachment.htm From secret.argent at gmail.com Sun Jun 1 18:54:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 18:53:12 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> References: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> Message-ID: <4C736DE8-15A4-43CC-8B4C-8863E460456F@gmail.com> On 2008-06-01, at 15:28, JB Kraft wrote: > IANAL, but the unofficial FAQ seems to attempt to account for this > usage > > https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ Well, that's unofficial, and I'm not sure I see where it accounts for plugins. The FLOSS exception does not apply in this case. Quicktime and Flash are not Free/Libre/Open Source. In fact http://wiki.secondlife.com/wiki/Third_Party_Libraries points out that Quicktime is not covered by the FLOSS exception. From secret.argent at gmail.com Sun Jun 1 18:59:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 18:58:48 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> Message-ID: <37E8001A-7207-495C-B6B2-DB68DA853DA9@gmail.com> On 2008-06-01, at 16:06, Matthew Underwood wrote: > For the most part the GPL allows you to use GPL'd code so long as you > do not actually "include" that code into your binary with the > exclusion of language libraries (like the c standard libraries). Language libraries are not actually an exception. Libraries shipped with the OS are, which is where the C library generally comes in. The meaning of "the OS" is normally treated VERY strictly by the FSF... embedded implementations of operating systems like Interix are not considered an exception, though they should be. Yes, there are mechanisms to create cutouts, I've talked about some on the past myself, but they strongly limit the potential for plugins. > The idea is that open source apps get a free ride while > commercial applications will need to fork out the dough (like they > normally would anyway). And what I'm talking about is the client-side equivalent of scripted HUDs. Not things like the CSI client. From secret.argent at gmail.com Sun Jun 1 19:01:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 19:00:11 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <48432D25.7020300@lindenlab.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> Message-ID: <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> On 2008-06-01, at 18:13, Stephany Filimon wrote: > At this moment in time, removing Landmarks from the inventory is > NOT on our list of things to do as part of this project. I > apologize for any confusion or concern that our earlier wiki > comments (from our first meeting, as Jacek noted) may have caused. Could you update the section in the Wiki under "Food for Thought" then? From secret.argent at gmail.com Sun Jun 1 19:02:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 19:01:49 2008 Subject: [sldev] Standard grid identifier string? In-Reply-To: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> References: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Message-ID: Interesting idea. On 2008-06-01, at 19:26, Sato Meiji wrote: > Note in both cases they don't need to be valid domains (I'm using > them as a human readable 'relm' specifiers) The latter should probably be com.secondlife.*something*.agni then, to make it clear that it's an identifier and not a domain. From lenglish5 at cox.net Sun Jun 1 20:10:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Jun 1 20:10:18 2008 Subject: [sldev] Standard grid identifier string? In-Reply-To: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> References: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Message-ID: <48436496.40908@cox.net> Sato Meiji wrote: > Does anyone know if there is a standard way to identify a grid in a > human readable way? (i.e. a string). > Not just the SL grids (main, beta etc) but a way that would include > other VW grids? > For SL and opensim-based grids I was considering: > > 1) Using the shard (as reported by the HTTP X_SECONDLIFE_SHARD header) > and domain, such as "production.secondlife.com > ", "testing.secondlife.com > ", "production.centralgrid.com > " etc > > 2) Using something like agni.secondlife.com > > Note in both cases they don't need to be valid domains (I'm using them > as a human readable 'relm' specifiers) > > Is there a defacto way LL uses internally (or in the SL protocols) to > identify grids? What about those out there who've recently added > 3rd-party grid support to the viewer - how are grids identified in > config files etc? > > Just wondered if there is an 'accepted' way in use or one emerging > before I reinvent things. > Thanks. > I'd look at the Map API VAG page, talk to the people listed, and attend AW Groupies and Zero Linden office hours (and read transcripts of them): https://wiki.secondlife.com/wiki/Map_API_VAG https://wiki.secondlife.com/wiki/Category:AW_Groupies#Chat_Logs Its been a point of controversy how to identify non-LL virtual worlds. The OpenSim folk have their own ideas too, I am sure. https://wiki.secondlife.com/wiki/Category:AW_Groupies#External_Resources Lawson From tulla at lindenlab.com Mon Jun 2 09:13:35 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi Linden)) Date: Mon Jun 2 09:13:40 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> Message-ID: <48441C2F.9090209@lindenlab.com> This is to be expected. Dave's first email mentioned that the feature would require at least a GeForce 8 to run. Enabling it on 7 series or lower hardware will have similarly bad results. Dante Tucker wrote: > I've been distributing this viewer to a group of mine for testing. So > far In 100% of cases, 7 series Nvidia cards crash on the last step. 8 > and 9 series seem to have no problem. > > On Sat, May 31, 2008 at 10:59 AM, Robin Cornelius > > wrote: > > Dave Parks wrote: > > So getting the awesome out of that branch is a little obscure: > > > > 1) Make sure atmospheric shaders and avatar hardware skinning > are enabled. > > 2) Make sure the debug setting RenderDeferred is set to FALSE > > 3) Set RenderUseFBO to TRUE > > 4) Set RenderDeferred to TRUE > > > > It's only been tested on GeForce 8 cards in Windows (Vista and > XP), but > > I don't see why it shouldn't work in linux. I'd be amazed if it > works > > in OSX since it relies on branching in the shader and a large > > instruction count limit. It's also quite unoptimized and VERY > > experimental. > > With all that i mind i tried anyway but get a crash, now i am not > sure i > am starting the options up incorrectly or if anything else should be > disabled first. Latest SVN on (my) linux crashes when trying to do > something with the shaders, it crashes when i try step 4. Also i'm > on a > 64 bit system if that matters and i'm pushing my luck with my Geforce > 7100, but though i would see what happened anyway even if it ran > slowly. > > > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/pointLightV.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/pointLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/pointLightF.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/pointLightF.glsl > 2008-05-31T14:49:49Z INFO: dumpObjectLog: Fragment info > ------------- > (8) : warning C7531: global type sampler2DRect requires "#extension > GL_ARB_texture_rectangle : enable" before use > (58) : warning C7011: implicit cast from "vec4" to "vec3" > (58) : warning C7011: implicit cast from "vec4" to "vec3" > (58) : warning C7011: implicit cast from "vec4" to "vec3" > > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 0 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 1 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 2 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 3 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 4 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightV.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/sunLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightF.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/sunLightF.glsl > 2008-05-31T14:49:49Z WARNING: linkProgramObject: GLSL Linker Error: > 2008-05-31T14:49:49Z WARNING: dumpObjectLog: Fragment info > ------------- > (9) : warning C7531: global type sampler2DRect requires "#extension > GL_ARB_texture_rectangle : enable" before use > (227) : warning C7549: OpenGL does not allow C style initializers > (268) : warning C7011: implicit cast from "int" to "float" > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (267) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (274) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link shader: > Deffered Sun Shader > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link using > shader > level 1. Trying again using shader level 0. > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightV.glsl class 0 > 2008-05-31T14:49:49Z INFO: loadShaderFile: GLSL Shader file not found: > deferred/sunLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightF.glsl class 0 > 2008-05-31T14:49:49Z INFO: loadShaderFile: GLSL Shader file not found: > deferred/sunLightF.glsl > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link shader: > Deffered Sun Shader > 2008-05-31T14:49:49Z > x86_64-linux-client-release/llrender/llrendertarget.cpp(159) : error > 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Quidquid latine dictum sit, altum sonatur." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric M. Tulla tulla@lindenlab.com Graphics Programmer Linden Lab 1 Broadway Street, 14th Floor Cambridge, MA 02142 cell: 617.388.7971 From monkowsk at watson.ibm.com Mon Jun 2 11:06:38 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:07:42 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: <484436AE.9010701@watson.ibm.com> Jay Reynolds Freeman wrote: > So I have been looking at the SL Viewer Architecture Wiki, and > babbling a bit as I page through 600 000 lines of source code, > trying to learn about the whens, hows, and wherefores of information > about objects in SL, that are near the agent, being downloaded > to the client. > > Stuff in the wiki is rather thin, but there are several possibly > promising pages that seem to be limited to group access; they > include the pages for Culling, Groups, and the Rendering System. > Alas, the wiki also seems not entirely clear on what group > can access them, or how to go about joining it. Sorry to disappoint you, but those aren't pages requiring special access, those are pages that are yet to be created. You can try searching the wiki or the archives of the mailing list. I started putting together a page on Culling by gathering bits from the mailing list, but I haven't got around to editing it. I'll send you the rough draft. Mike From lenglish5 at cox.net Mon Jun 2 11:19:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 11:19:53 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <484436AE.9010701@watson.ibm.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> Message-ID: <484439C5.6070004@cox.net> Mike Monkowski wrote: > Jay Reynolds Freeman wrote: >> So I have been looking at the SL Viewer Architecture Wiki, and >> babbling a bit as I page through 600 000 lines of source code, >> trying to learn about the whens, hows, and wherefores of information >> about objects in SL, that are near the agent, being downloaded >> to the client. >> >> Stuff in the wiki is rather thin, but there are several possibly >> promising pages that seem to be limited to group access; they >> include the pages for Culling, Groups, and the Rendering System. >> Alas, the wiki also seems not entirely clear on what group >> can access them, or how to go about joining it. > > Sorry to disappoint you, but those aren't pages requiring special > access, those are pages that are yet to be created. > > You can try searching the wiki or the archives of the mailing list. > > I started putting together a page on Culling by gathering bits from > the mailing list, but I haven't got around to editing it. I'll send > you the rough draft. > > I'd like to remind everyone to PLEASE let other people know what you're doing. At the least, putting [[Category: AW Groupies]] at the bottom of a wiki page will list it in the articles page for AW Groupies. Even better, do that AND put a link to it under https://wiki.secondlife.com/wiki/AW_Groupies#AWG_and_citizen_pages How will anyone ever find what you have done to document the protocols and so on if you don't at least do that? If you don't feel it belongs under the protocol/communication heading, please feel free to create a new heading, say, viewer documentation or viewer architecture or something. Thanks. Lawson From monkowsk at watson.ibm.com Mon Jun 2 11:34:50 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:35:09 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> Message-ID: <48443D4A.1090609@watson.ibm.com> Bj Raz wrote: > What I see here is the possibility for inter continuity between objects > within other virtual worlds, like WoW and characters to come and > interact with in SL. Now you are breaching 3D worlds and making them > one world. each world can go to SL. That is what I see. Avatar > transport between 3D worlds. Data encapsulation, from one platform > (virtual world) to another. > WoW -> SL I strongly disagree. I see no reason to transfer objects and avatars between different worlds. I can see reason to transfer them between different shards of the same base world, but between different worlds, all you need to transfer is identity. It's reasonable to expect to be able to chat with someone in a different world or to transport to another world, but what is the point of transferring 3D objects? If you want your avatar to look the same in WoW and SL, you can modify them using each world's editor, but you don't have to use the same mesh and morphs. To use an analogy, I can play Quicktime movies and Flash animations in the same browser, and I wouldn't be surprised to find a converter that can translate Flash into Quicktime, but I wouldn't expect to be able to play the Quicktime movie in a Flash viewer. Mike From monkowsk at watson.ibm.com Mon Jun 2 11:41:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:43:22 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <484439C5.6070004@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> Message-ID: <48443EDE.5090200@watson.ibm.com> Lawson English wrote: > Mike Monkowski wrote: > >> Jay Reynolds Freeman wrote: >> >>> So I have been looking at the SL Viewer Architecture Wiki, and >>> babbling a bit as I page through 600 000 lines of source code, >>> trying to learn about the whens, hows, and wherefores of information >>> about objects in SL, that are near the agent, being downloaded >>> to the client. >>> >>> Stuff in the wiki is rather thin, but there are several possibly >>> promising pages that seem to be limited to group access; they >>> include the pages for Culling, Groups, and the Rendering System. >>> Alas, the wiki also seems not entirely clear on what group >>> can access them, or how to go about joining it. >> >> >> Sorry to disappoint you, but those aren't pages requiring special >> access, those are pages that are yet to be created. >> >> You can try searching the wiki or the archives of the mailing list. >> >> I started putting together a page on Culling by gathering bits from >> the mailing list, but I haven't got around to editing it. I'll send >> you the rough draft. >> >> > I'd like to remind everyone to PLEASE let other people know what you're > doing. At the least, putting [[Category: AW Groupies]] at the bottom of > a wiki page will list it in the articles page for AW Groupies. Even > better, do that AND put a link to it under > https://wiki.secondlife.com/wiki/AW_Groupies#AWG_and_citizen_pages > > How will anyone ever find what you have done to document the protocols > and so on if you don't at least do that? > > If you don't feel it belongs under the protocol/communication heading, > please feel free to create a new heading, say, viewer documentation or > viewer architecture or something. Huh? I'm pretty sure Jay is referring to the page titled "Viewer Architecture." The page already exists, but has nothing to do with AWG or AW Groupies. Did I miss something? Mike From sakkaku at gmail.com Mon Jun 2 11:48:27 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 11:48:30 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48443D4A.1090609@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> Message-ID: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> On Mon, Jun 2, 2008 at 1:34 PM, Mike Monkowski wrote: > Bj Raz wrote: >> >> What I see here is the possibility for inter continuity between objects >> within other virtual worlds, like WoW and characters to come and interact >> with in SL. Now you are breaching 3D worlds and making them one world. each >> world can go to SL. That is what I see. Avatar transport between 3D >> worlds. Data encapsulation, from one platform (virtual world) to another. >> WoW -> SL > > I strongly disagree. I see no reason to transfer objects and avatars > between different worlds. I can see reason to transfer them between > different shards of the same base world, but between different worlds, all > you need to transfer is identity. > > It's reasonable to expect to be able to chat with someone in a different > world or to transport to another world, but what is the point of > transferring 3D objects? If you want your avatar to look the same in WoW > and SL, you can modify them using each world's editor, but you don't have to > use the same mesh and morphs. > > To use an analogy, I can play Quicktime movies and Flash animations in the > same browser, and I wouldn't be surprised to find a converter that can > translate Flash into Quicktime, but I wouldn't expect to be able to play the > Quicktime movie in a Flash viewer. > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Why not? Today you can play literally hundreds of video formats in the same player whereas several years ago you would be literally forced to have different players for different codecs. Having the ability to represent other worlds via a set standard would allow many unique opportunities. Imagine being able to watch tournaments within different games, being able to chat with friends in different worlds, etc. While it may not be feasible now, if you push you could likely end up with one or two companies participating. From bos at lindenlab.com Mon Jun 2 11:49:13 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 2 11:49:14 2008 Subject: [sldev] cmake-9 latest test results In-Reply-To: References: Message-ID: <484440A9.6010403@lindenlab.com> Hi, Robin - Thank you for taking the time to try this stuff out again. Your reports have been very helpful, and I appreciate your effort. > Current public cmake-9 status (on windows) seems to be ;- > > 1) The previous mentioned dependency of copy_win_scripts (can work > around by removing dependency reference) I just checked in a fix for this. > 2) VSTool.exe fails with an error (not critical) > Running 'tools\\vstool\\VSTool.exe --solution > build-VC90\\SecondLife.sln --config RelWithDebInfo --startup > secondlife-bin' in 'C:\\cmake-9\\indra' > Opening solution: build-VC90\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC90... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\cmake-9\indra\build-VC90\SecondLife.sln This isn't my baby, but I'll make sure it gets a look. > 3) Compiling is successful in VC90 (Visual C++ 2008) Excellent! > 4) Linking links against a not supplied ll_intel_memops.lib (missing > export file in libs zip?) does not seem to be required We don't have permission to redistribute that. I've made linking against it conditional on its presence. > 6) post-build fails due to missing script :- > Performing Post-Build Event... > C:\Python25\python25.exe: can't open file > 'C:/cmake-9/indra/newview/postbuild_win32.py': [Errno 2] No such file > or directory Oops, added. > 7) Executing the binary built in "Debug" results in missing > OpenJPEGd.dll (in fact the default build is RelWithDebInf but this > didn't get set due to (2). Need to rebuild in these different modes to > complete tests. OK. I hope that if we can fix vstool, this one will resolve itself. References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> Message-ID: <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> Excuse me if I missed it, but shouldn't it be mentioned in the design doc how the landmarks will end up in the inventory. Will those folders you make in the landmark panel also be created in the inventory landmark folder? Or will they just be dropped in the main list, and we have to clean up the clutter by hand? Frans. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/4a09983c/attachment.htm From carjay at gmx.net Mon Jun 2 13:09:45 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Jun 2 13:09:58 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48441C2F.9090209@lindenlab.com> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> Message-ID: <48445389.5050709@gmx.net> Eric M. Tulla (BigPapi Linden) wrote: > This is to be expected. Dave's first email mentioned that the feature > would require at least a GeForce 8 to run. Enabling it on 7 series or > lower hardware will have similarly bad results. > > Dante Tucker wrote: >> 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? Looking at the FBO and pipeline code I think it's the deferred sun shadow shader which stops the 7s in its track. It uses a double floating point texture (FP32) along with linear filtering which is only possible starting with G8x GPUs. But would probably not be of much use even if it worked since I guess the sun shader (which is not linking) is necessary for it to work. There are really quite some differences between G7x and G8x, for some features it's not just a case of "a bit slower" but a "can't work". You need fallback paths for all of these and those aren't present yet. Carsten From carjay at gmx.net Mon Jun 2 13:16:28 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Jun 2 13:16:32 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48445389.5050709@gmx.net> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> Message-ID: <4844551C.5020009@gmx.net> Carsten Juttner wrote: > > It uses a double floating point texture (FP32) along with linear > filtering which is only possible starting with G8x GPUs. Oops, FP32 is of course not a double but "just" a single precision float. Carsten From lenglish5 at cox.net Mon Jun 2 13:55:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 13:56:00 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48443EDE.5090200@watson.ibm.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> Message-ID: <48445E5D.4020203@cox.net> Mike Monkowski wrote: > > Huh? I'm pretty sure Jay is referring to the page titled "Viewer > Architecture." The page already exists, but has nothing to do with > AWG or AW Groupies. Did I miss something? > > Mike > > Nyah, but I did. Added a reference from AW Groupies page to it and back. Lawson From lenglish5 at cox.net Mon Jun 2 13:59:56 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 13:59:58 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> Message-ID: <48445F4C.8050305@cox.net> Matthew Underwood wrote: > [...] > Why not? Today you can play literally hundreds of video formats in > the same player whereas several years ago you would be literally > forced to have different players for different codecs. Having the > ability to represent other worlds via a set standard would allow many > unique opportunities. > > Imagine being able to watch tournaments within different games, being > able to chat with friends in different worlds, etc. While it may not > be feasible now, if you push you could likely end up with one or two > companies participating. > _______________________________________________ > Well, the current AWG focus is on the near-term goal of interoperability (including asset-sharing in some cases) between SL and OpenSim worlds. Linden Lab and IBM are also working on a universal avatar specification. Long-term, various companies and organizations are already working on interoperability, multiple viewer support, etc. https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources Lawson From monkowsk at watson.ibm.com Mon Jun 2 15:22:28 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 15:24:01 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> Message-ID: <484472A4.2030104@watson.ibm.com> Matthew Underwood wrote: > Having the > ability to represent other worlds via a set standard would allow many > unique opportunities. > > Imagine being able to watch tournaments within different games, being > able to chat with friends in different worlds, etc. This is where I don't get it. Streaming video? Sure. Chat? Sure. Even portals to other worlds makes sense as a way of transferring identity. Those don't involve 3D objects or avatar meshes. But why would you want to shoot an arrow in WoW and have it land in SL? Mike From sakkaku at gmail.com Mon Jun 2 15:30:27 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 15:30:29 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484472A4.2030104@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> Message-ID: <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> On Mon, Jun 2, 2008 at 6:22 PM, Mike Monkowski wrote: > Matthew Underwood wrote: >> >> Having the >> ability to represent other worlds via a set standard would allow many >> unique opportunities. >> >> Imagine being able to watch tournaments within different games, being >> able to chat with friends in different worlds, etc. > > This is where I don't get it. Streaming video? Sure. Chat? Sure. Even > portals to other worlds makes sense as a way of transferring identity. > Those don't involve 3D objects or avatar meshes. But why would you want to > shoot an arrow in WoW and have it land in SL? > > Mike > I don't really see that happening. For the most part that would open up a lot of security issues (imagine 10 turrets being transported into WoW, I am sure that would go well with blizzard...). I think it would be better to stop thinking of it as streaming "video" so much as streaming the world and allowing interaction. From gigstaggart at gmail.com Mon Jun 2 15:55:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 2 15:55:28 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48445E5D.4020203@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> <48445E5D.4020203@cox.net> Message-ID: <48447A4C.1080400@gmail.com> Lawson English wrote: > Nyah, but I did. Added a reference from AW Groupies page to it and back. > > Lawson What does viewer culling have to do with the AWG? If your criteria are that broad, you could include every page in the wiki. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080602/1d2899c0/smime.bin From monkowsk at watson.ibm.com Mon Jun 2 16:08:36 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 16:09:13 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48445F4C.8050305@cox.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> Message-ID: <48447D74.2050704@watson.ibm.com> Lawson English wrote: > Well, the current AWG focus is on the near-term goal of interoperability > (including asset-sharing in some cases) between SL and OpenSim worlds. They aren't really different worlds, though, just different implementations of the same virtual world. > Linden Lab and IBM are also working on a universal avatar specification. Although I work at IBM, I haven't heard anything beyond the initial announcement. Anyone else know if there's been any progress? It's net even clear to me if this means avatar meshes or avatar identities, which are very different things. > Long-term, various companies and organizations are already working on > interoperability, multiple viewer support, etc. Why? What advantage is there to sharing builds or avatar meshes across different platforms? Are they worth the effort? Mike From monkowsk at watson.ibm.com Mon Jun 2 16:12:28 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 16:13:05 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> Message-ID: <48447E5C.4080808@watson.ibm.com> Matthew Underwood wrote: > I think it would > be better to stop thinking of it as streaming "video" so much as > streaming the world and allowing interaction. What kind of interaction? Mike From danteferret at gmail.com Mon Jun 2 16:21:39 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 2 16:21:44 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48445389.5050709@gmx.net> References: <200805232003.05484.johnniecarling@gmail.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> Message-ID: <4d211a610806021621m61c13a04ue332757e20652d7e@mail.gmail.com> Your emails kinda messed up, theres a "Dante Tucker wrote:" and following that, stuff I never wrote. Oh and also, Dave never actualy stated it would require a GeForce 8, I don't know where everyone got that idea from. Thats why I was simply confirming his suspicion that it did not run on earlier cards. On Mon, Jun 2, 2008 at 4:09 PM, Carsten Juttner wrote: > Eric M. Tulla (BigPapi Linden) wrote: > >> This is to be expected. Dave's first email mentioned that the feature >> would require at least a GeForce 8 to run. Enabling it on 7 series or lower >> hardware will have similarly bad results. >> >> Dante Tucker wrote: >> >>> 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? >>> >> > > Looking at the FBO and pipeline code I think it's the deferred sun shadow > shader which stops the 7s in its track. > > It uses a double floating point texture (FP32) along with linear filtering > which is only possible starting with G8x GPUs. > > But would probably not be of much use even if it worked since I guess the > sun shader (which is not linking) is necessary for it to work. > > There are really quite some differences between G7x and G8x, for some > features it's not just a case of "a bit slower" but a "can't work". > > You need fallback paths for all of these and those aren't present yet. > > > Carsten > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/a696e98c/attachment.htm From bos at lindenlab.com Mon Jun 2 16:24:37 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 2 16:24:40 2008 Subject: [sldev] CMake project merged to release branch! Message-ID: <48448135.6090805@lindenlab.com> I'm pleased to announce that our release (aka "trunk") branch is now built using CMake on all platforms. This should have a number of benefits for the developer community: One source of all build information, for every platform. On Windows, upport for Visual Studio 2005 and 2008. Easier to develop and maintain patches. For docs, see here: http://wiki.secondlife.com/wiki/CMake I've made a quick pass over developer info for other wiki pages, but please feel welcome to edit and update those pages as appropriate. I've been editing wiki pages all afternoon, and my brain has melted. References: <200805232003.05484.johnniecarling@gmail.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> <4d211a610806021621m61c13a04ue332757e20652d7e@mail.gmail.com> Message-ID: <484486A2.3090108@gmx.net> Dante Tucker wrote: > Your emails kinda messed up, theres a "Dante Tucker wrote:" and > following that, stuff I never wrote. > Oh and also, Dave never actualy stated it would require a GeForce 8, I > don't know where everyone got that idea from. Thats why I was simply > confirming his suspicion that it did not run on earlier cards. Hm, yes, truly sorry, actually that was a stupid mistake (deleted too much of the original mail) since the reply was really directed at Robin to confirm that there's obviously not a simply fix to make this work on G7x cards (the log entry was posted by Robin in reply to your mail). Carsten From sakkaku at gmail.com Mon Jun 2 16:54:23 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 16:54:25 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447E5C.4080808@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> Message-ID: <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> On Mon, Jun 2, 2008 at 6:12 PM, Mike Monkowski wrote: > Matthew Underwood wrote: > >> I think it would >> be better to stop thinking of it as streaming "video" so much as >> streaming the world and allowing interaction. > > What kind of interaction? > > Mike > Don't ask me as I am a nobody :P From monkowsk at watson.ibm.com Mon Jun 2 17:22:10 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 17:22:46 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> Message-ID: <48448EB2.8070701@watson.ibm.com> Matthew Underwood wrote: > On Mon, Jun 2, 2008 at 6:12 PM, Mike Monkowski wrote: > >>Matthew Underwood wrote: >> >> >>>I think it would >>>be better to stop thinking of it as streaming "video" so much as >>>streaming the world and allowing interaction. >> >>What kind of interaction? >> >>Mike >> > > > Don't ask me as I am a nobody :P No fair. You were thinking of something. I don't intend to criticize; I just want to understand. It takes many eyes to see the future. :-) mike From lenglish5 at cox.net Mon Jun 2 17:32:08 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 17:32:11 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48447A4C.1080400@gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> <48445E5D.4020203@cox.net> <48447A4C.1080400@gmail.com> Message-ID: <48449108.4000006@cox.net> Jason Giglio wrote: > Lawson English wrote: > >> Nyah, but I did. Added a reference from AW Groupies page to it and back. >> >> Lawson >> > > What does viewer culling have to do with the AWG? If your criteria are > that broad, you could include every page in the wiki. > > -Jason > Eh, the AWG is about LL's 2-year plan. The AW Groupies is a bit more open, and in fact, documenting protocols for the OGP will eventually require understanding how the viewer draws things, I think, so its still within the formal "AWG" mandate, in the long run. Lawson From lenglish5 at cox.net Mon Jun 2 17:35:10 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 17:35:12 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447D74.2050704@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> Message-ID: <484491BE.3040905@cox.net> Mike Monkowski wrote: > Lawson English wrote: >> Well, the current AWG focus is on the near-term goal of >> interoperability (including asset-sharing in some cases) between SL >> and OpenSim worlds. > > They aren't really different worlds, though, just different > implementations of the same virtual world. > >> Linden Lab and IBM are also working on a universal avatar specification. > > Although I work at IBM, I haven't heard anything beyond the initial > announcement. Anyone else know if there's been any progress? It's > net even clear to me if this means avatar meshes or avatar identities, > which are very different things. > >> Long-term, various companies and organizations are already working on >> interoperability, multiple viewer support, etc. > > Why? What advantage is there to sharing builds or avatar meshes > across different platforms? Are they worth the effort? > > Mike > You'd have to ask the OpenViewer people. , Also there was some IBM guy who spoke at the Japan 2008 VW conference a few days ago along with Philip Rosen. He was hyped on going well beyond preserving avatar identity. In fact, he correct Phil LInden's 10-year timeline for full interoperability wtih non-SL-compatible worlds, and suggested it would be far, FAR sooner than that. Lawson From dmahalko at gmail.com Mon Jun 2 17:44:21 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 2 17:44:23 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: On Sun, Jun 1, 2008 at 5:17 PM, Jay Reynolds Freeman wrote: > So I have been looking at the SL Viewer Architecture Wiki, and > babbling a bit as I page through 600 000 lines of source code, > trying to learn about the whens, hows, and wherefores of information > about objects in SL, that are near the agent, being downloaded > to the client. > > Stuff in the wiki is rather thin, but there are several possibly > promising pages that seem to be limited to group access; they > include the pages for Culling, Groups, and the Rendering System. > Alas, the wiki also seems not entirely clear on what group > can access them, or how to go about joining it. Probably the best place to look for object tracking and summarizing, is in code related to the mini-map. The mini-map seems to be a live display of all objects the client has downloaded and is rendering in your vicinity, as well as showing the sims that are currently communicating with your client. The mini-map seems to act as a sort of summary of primitives and other data being actively monitored by the client, so tapping into its code could give you most of the object data you seek.. (I wonder if the mini-map may have started life as debugging tool just to monitor this background information, but later moved into general use as a common user's tool.) - Scalar Tardis / Dale Mahalko From lenglish5 at cox.net Mon Jun 2 18:24:59 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 18:25:03 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: <48449D6B.2040406@cox.net> Dale Mahalko wrote: > On Sun, Jun 1, 2008 at 5:17 PM, Jay Reynolds Freeman > wrote: > >> So I have been looking at the SL Viewer Architecture Wiki, and >> babbling a bit as I page through 600 000 lines of source code, >> trying to learn about the whens, hows, and wherefores of information >> about objects in SL, that are near the agent, being downloaded >> to the client. >> >> Stuff in the wiki is rather thin, but there are several possibly >> promising pages that seem to be limited to group access; they >> include the pages for Culling, Groups, and the Rendering System. >> Alas, the wiki also seems not entirely clear on what group >> can access them, or how to go about joining it. >> > > Probably the best place to look for object tracking and summarizing, > is in code related to the mini-map. The mini-map seems to be a live > display of all objects the client has downloaded and is rendering in > your vicinity, as well as showing the sims that are currently > communicating with your client. The mini-map seems to act as a sort of > summary of primitives and other data being actively monitored by the > client, so tapping into its code could give you most of the object > data you seek.. > > (I wonder if the mini-map may have started life as debugging tool just > to monitor this background information, but later moved into general > use as a common user's tool.) > > I believe the mini-map is generated server-side, about once a week. Lawson From secret.argent at gmail.com Mon Jun 2 18:38:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 2 18:36:45 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48443D4A.1090609@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> Message-ID: <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> On 2008-06-02, at 13:34, Mike Monkowski wrote: > If you want your avatar to look the same in WoW and SL, you can > modify them using each world's editor, but you don't have to use > the same mesh and morphs. I don't believe that it's possible to create an avatar in WoW that will look like any of my avatars in SL, and frankly I have no interest in playing Warcraft or Everquest or any other MMORPG until that changes. > To use an analogy, I can play Quicktime movies and Flash animations > in the same browser, and I wouldn't be surprised to find a > converter that can translate Flash into Quicktime, but I wouldn't > expect to be able to play the Quicktime movie in a Flash viewer. Up until QT 7.3.1 you could play Flash animations inside quicktime, and Quicktime is just a packaging mechanism for various codecs, many of which can also be used by Quicktime. This is not a matter of translation, it's is a matter of both Flash Video and Quicktime supporting the same standards. From secret.argent at gmail.com Mon Jun 2 18:47:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 2 18:46:26 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48448EB2.8070701@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> Message-ID: On 2008-06-02, at 19:22, Mike Monkowski wrote: > No fair. You were thinking of something. I don't intend to > criticize; I just want to understand. It takes many eyes to see > the future. :-) OK. At the moment, my avatar in SL is a ferret. Four legged, about two feet long, which is big for a ferret, I admit, but until LL loosens up on the mesh and skeleton that's the best I can do. I have a collar with feathers stuck in it that I wear sometimes. If a friend of mine invites me to visit him in WoW, is it possible for me to visit him as this avatar? From tateru.nino at gmail.com Mon Jun 2 19:08:15 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 19:08:55 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> Message-ID: <4844A78F.9050605@weblogsinc.com> Argent Stonecutter wrote: > On 2008-06-02, at 19:22, Mike Monkowski wrote: >> No fair. You were thinking of something. I don't intend to >> criticize; I just want to understand. It takes many eyes to see the >> future. :-) > > OK. At the moment, my avatar in SL is a ferret. Four legged, about two > feet long, which is big for a ferret, I admit, but until LL loosens up > on the mesh and skeleton that's the best I can do. > > I have a collar with feathers stuck in it that I wear sometimes. > > If a friend of mine invites me to visit him in WoW, is it possible for > me to visit him as this avatar? That would, of course, require the transfer of the avatar, the account, attachments, textures, LSL scripts(!), animations. Essentially a bit of a free-for-all, asset/content transfer, AND have the scripts reliably executed at the destination. Let me go out on a very tenuous limb here and suggest "fat chance". -- Tateru Nino http://www.massively.com/ From cjac at colliertech.org Mon Jun 2 19:51:47 2008 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Mon Jun 2 19:52:50 2008 Subject: [sldev] patch to ELFIO Message-ID: <7B0351D2-088D-410D-9C0A-621789EF44E5@colliertech.org> Hey folks, I've been trying to ease the pain of building the viewer dependencies over the last week. As I mentioned in an earlier message, I've built a gar-based system to build the dependencies listed here: http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) #Installing_the_required_dependencies_.28prepackaged_by_Linden_labs.29 The source for the system, which I've called GARINDRA, is available in subversion here: svn co http://svn.colliertech.org/svn/trunk/garindra I've made a pre-release tarball and placed it here: http://www.colliertech.org/downloads/garindra/garindra-pre0.0.1.tar.bz2 When I get a few more minutes, I'll add the last remaining dependencies. In order to reduce the delta between the libs generated by GARINDRA and the stock configurations, I've created a patch to the ELFIO lib which allows a shared object to be built using libtool. I've sent the patch to the maintainer and hosted it here: http://www.colliertech.org/downloads/garindra/ELFIO.diff The distribution of EIFIO with this patch applied is hosted here: http://www.colliertech.org/downloads/garindra/elfio-1.0.3.1.tar.gz I'd love to get some feedback :) Cheers, C.J. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/ca9c5783/attachment.htm From lenglish5 at cox.net Mon Jun 2 20:31:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 20:31:45 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844A78F.9050605@weblogsinc.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> Message-ID: <4844BB1F.4040902@cox.net> Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason From missannotoole at yahoo.com Mon Jun 2 22:05:02 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 2 22:05:08 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Message-ID: <104754.31574.qm@web59111.mail.re1.yahoo.com> And how will an asset (any type) be prevented from being carried off of one world to another world when the asset creator forbids transport of said asset from one world to another? Is there a real corporate IP lawyer from LL and IBM involved in this effort to prevent legal errors from being coded? ----- Original Message ---- From: Lawson English To: Tateru Nino Cc: sldev Mailing List Sent: Monday, June 2, 2008 11:31:43 PM Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/f0458c6b/attachment-0001.htm From tateru.nino at gmail.com Mon Jun 2 22:15:27 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 22:16:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <104754.31574.qm@web59111.mail.re1.yahoo.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <4844D36F.1050705@weblogsinc.com> Assets are already transported between worlds, no code required. Look at the number of content assets in SL that have been ripped from other worlds and from assorted games. I swear, if I see yet another cybernetic vampire castle made from Unreal 2 textures, I'll probably hurl. Ann Otoole wrote: > And how will an asset (any type) be prevented from being carried off > of one world to another world when the asset creator forbids transport > of said asset from one world to another? Is there a real corporate IP > lawyer from LL and IBM involved in this effort to prevent legal errors > from being coded? > > > ----- Original Message ---- > From: Lawson English > To: Tateru Nino > Cc: sldev Mailing List > Sent: Monday, June 2, 2008 11:31:43 PM > Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO > MPEG-V ... > > Tateru Nino wrote: > > > > > > Argent Stonecutter wrote: > >> On 2008-06-02, at 19:22, Mike Monkowski wrote: > >>> No fair. You were thinking of something. I don't intend to > >>> criticize; I just want to understand. It takes many eyes to see the > >>> future. :-) > >> > >> OK. At the moment, my avatar in SL is a ferret. Four legged, about > >> two feet long, which is big for a ferret, I admit, but until LL > >> loosens up on the mesh and skeleton that's the best I can do. > >> > >> I have a collar with feathers stuck in it that I wear sometimes. > >> > >> If a friend of mine invites me to visit him in WoW, is it possible > >> for me to visit him as this avatar? > > That would, of course, require the transfer of the avatar, the > > account, attachments, textures, LSL scripts(!), animations. > > Essentially a bit of a free-for-all, asset/content transfer, AND have > > the scripts reliably executed at the destination. > > > > Let me go out on a very tenuous limb here and suggest "fat chance". > > > Well, WoW and EQ are closed worlds. However, there's every possibility > that Wonderland, Croquet, and similar, more open, virtual worlds, will > be willing to let any and all such things in. The questions are: > > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and > its appearance? > how willing will said world be to let the avie keep its origianl name > and other such thigns? > how willing will said world be to let an externally generated avie be a > "first class" citizen? > > and so on. > > The most compatible will be something like an IBM-LL agreement where IBM > hosts its own sub-grid. > Slightly less compatible will be grids running a plain vanilla SL-like > world with full "trust." > > And it gets less compatible from there, > > Lwason > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From darien_caldwell at comcast.net Mon Jun 2 22:21:45 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Mon Jun 2 22:22:03 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <3B60A93948B840A3A8B17E0F1442B666@a644000> It's kind of a moot point. People are already carting off content from SL to OpenSim. Yes not Scripts, but everything else. You can thank things like that 'Second Inventory' program for that. Ann, it just doesn't fit in the scope of an open source world to have closed source data. If you have anything remotely valuable, patented, or actual RL 'IP', i would suggest you not bring it into SL. If you already have, take steps to get it out. You may as well lay it on your front lawn otherwise. ----- Original Message ----- From: Ann Otoole To: sldev Mailing List Sent: Monday, June 02, 2008 10:05 PM Subject: Re: Interoperability;was: [sldev] Call for requirements: ISO MPEG-V ... And how will an asset (any type) be prevented from being carried off of one world to another world when the asset creator forbids transport of said asset from one world to another? Is there a real corporate IP lawyer from LL and IBM involved in this effort to prevent legal errors from being coded? ----- Original Message ---- From: Lawson English To: Tateru Nino Cc: sldev Mailing List Sent: Monday, June 2, 2008 11:31:43 PM Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/f0cfc032/attachment.htm From tateru.nino at gmail.com Mon Jun 2 22:22:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 22:23:17 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <104754.31574.qm@web59111.mail.re1.yahoo.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <4844D51F.50109@weblogsinc.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/316f8994/attachment.htm From gigstaggart at gmail.com Tue Jun 3 00:25:07 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 3 00:25:11 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <48448135.6090805@lindenlab.com> References: <48448135.6090805@lindenlab.com> Message-ID: <4844F1D3.1090301@gmail.com> Bryan O'Sullivan wrote: > I'm pleased to announce that our release (aka "trunk") branch is now > built using CMake on all platforms. > I don't see it. Trunk doesn't seem to have it. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080603/d1d410ad/smime-0001.bin From kfa at gmx.net Tue Jun 3 01:34:25 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 01:34:35 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844BB1F.4040902@cox.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> Message-ID: <48450211.50408@gmx.net> Lawson English wrote: > Tateru Nino wrote: >> >> >> Argent Stonecutter wrote: >>> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>>> No fair. You were thinking of something. I don't intend to >>>> criticize; I just want to understand. It takes many eyes to see the >>>> future. :-) >>> >>> OK. At the moment, my avatar in SL is a ferret. Four legged, about >>> two feet long, which is big for a ferret, I admit, but until LL >>> loosens up on the mesh and skeleton that's the best I can do. >>> >>> I have a collar with feathers stuck in it that I wear sometimes. >>> >>> If a friend of mine invites me to visit him in WoW, is it possible >>> for me to visit him as this avatar? >> That would, of course, require the transfer of the avatar, the >> account, attachments, textures, LSL scripts(!), animations. >> Essentially a bit of a free-for-all, asset/content transfer, AND have >> the scripts reliably executed at the destination. >> >> Let me go out on a very tenuous limb here and suggest "fat chance". >> > Well, WoW and EQ are closed worlds. However, there's every possibility > that Wonderland, Croquet, and similar, more open, virtual worlds, will > be willing to let any and all such things in. The questions are: > > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and > its appearance? > how willing will said world be to let the avie keep its origianl name > and other such thigns? > how willing will said world be to let an externally generated avie be a > "first class" citizen? > > and so on. > > The most compatible will be something like an IBM-LL agreement where IBM > hosts its own sub-grid. > Slightly less compatible will be grids running a plain vanilla SL-like > world with full "trust." > > And it gets less compatible from there, > > Lwason > > The main question to answer for any such thing to happen is, where's the business angle to justify such an effort? Creating interfaces and mappings between spaces that were never made with interoperability in mind is not a trivial task. Ultimately the customer, the user will have to pay for it to be enabled. Is there anything you want to do so badly that you'd part with your hard earned L$, PED, gold nuggets or real world currency? And, even before that, what's the business advantage for the respective companies running those worlds? When reading about this discussion I spontaneously dismissed the idea, but upon second thought that is not so clear indeed. A while ago I played Entropia Universe, and took a brief glimpse at EVE Online. I too had fantasies of being somehow able to move my avatar between them. I have no clue what purpose it serves, but the idea is cool in a very fundamental way. Apart from the technical challenge, you'd have to crack the business models first. If a company makes money by selling you stuff they make in-house, wouldn't they find it hard to see the advantage in opening the floodgate. Why would e.g. MindArk, CCP or Microsoft want that? Why would Linden Labs? Those being answered, we'd have a starting point. Hope I didn't miss a piece. Felix From robin.cornelius at gmail.com Tue Jun 3 02:26:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 02:26:32 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4844F1D3.1090301@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 8:25 AM, Jason Giglio wrote: > Bryan O'Sullivan wrote: >> I'm pleased to announce that our release (aka "trunk") branch is now >> built using CMake on all platforms. >> > > I don't see it. Trunk doesn't seem to have it. > I have not seen any SVN commits in the last few days so i presume thats internally and i assume it will sync up when soft does the weekly sync. But any chance of getting a sync earlier so i can rattle through some tests again? Robin From secret.argent at gmail.com Tue Jun 3 02:43:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:42:33 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844A78F.9050605@weblogsinc.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> Message-ID: On 2008-06-02, at 21:08, Tateru Nino wrote: > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND > have the scripts reliably executed at the destination. Or the creation of a ferret avatar in a new format (MPEG-V?) supported by SL and WoW, with a skeleton, mesh, and animations in standard formats, and support by SL and WoW for them. I'm not sure that any less aggressive goal is worth pursuing. From secret.argent at gmail.com Tue Jun 3 02:46:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:45:19 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844D36F.1050705@weblogsinc.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> <4844D36F.1050705@weblogsinc.com> Message-ID: <12A023CA-901B-48F2-ABE0-3DB92CBCB6DF@gmail.com> On 2008-06-03, at 00:15, Tateru Nino wrote: > Assets are already transported between worlds, no code required. > Look at the number of content assets in SL that have been ripped > from other worlds and from assorted games. Naughty naughty, you're not supposed to let that skeleton out of the closet! Everyone's supposed to pretend that people who rip images from other games or poser default animations and sell them in Second Life are really content creators! From secret.argent at gmail.com Tue Jun 3 02:52:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:51:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <3B60A93948B840A3A8B17E0F1442B666@a644000> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> <3B60A93948B840A3A8B17E0F1442B666@a644000> Message-ID: On 2008-06-03, at 00:21, Darien Caldwell wrote: > It's kind of a moot point. People are already carting off content > from SL to OpenSim. Yes not Scripts, but everything else. You can > thank things like that 'Second Inventory' program for that. Well, things like SLICE. Second Inventory actually enforces tighter controls than SL. I got it to try and simplify sharing the stuff I create with my alts, but the restrictions it imposes make it all but useless even for products that are 100% mine. I believe they eventually gave up their scheme of requiring you to buy a separate copy of each of your alts, but by that time I'd given up on it... it was less work to set everything full perm, transfer it from Argent Stonecutter to Argent David, and reset the next owner permissions. From secret.argent at gmail.com Tue Jun 3 03:02:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 03:01:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48450211.50408@gmx.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> Message-ID: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> On 2008-06-03, at 03:34, Felix Duesenburg wrote: > The main question to answer for any such thing to happen is, > where's the business angle to justify such an effort? Creating > interfaces and mappings between spaces that were never made with > interoperability in mind is not a trivial task. Ultimately the > customer, the user will have to pay for it to be enabled. Is there > anything you want to do so badly that you'd part with your hard > earned L$, PED, gold nuggets or real world currency? I've spent hundreds of dollars on my avatar over the past three years: that and land rent for the Coonspiracy is where pretty much everything I earn in SL goes to. Why wouldn't I spend real money to carry that around with me? > And, even before that, what's the business advantage for the > respective companies running those worlds? Getting people who would have absolutely no interest in visiting WoW as an elf or a thinly disguised hobbit to play the game? People willing to pay a premium to have a custom avatar, but not willing to pay a penny to be a dark elf no matter how fantastic a costume Sony or Blizzard or whoever come up for it? From aimee at ama-zing.co.uk Tue Jun 3 03:45:13 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jun 3 03:45:18 2008 Subject: Fwd: [sldev] Need to learn about object download to the client... References: Message-ID: <65755B93-07D5-47D1-992B-BF6CD2D5A7FF@ama-zing.co.uk> > On Jun 3, 2008, at 02:24, Lawson English wrote: > >> > Dale Mahalko wrote: > >> Probably the best place to look for object tracking and summarizing, >> is in code related to the mini-map. The mini-map seems to be a live >> display of all objects the client has downloaded and is rendering in >> your vicinity, as well as showing the sims that are currently >> communicating with your client. > > I believe the mini-map is generated server-side, about once a week. I think you're thinking about the main map textures. You can watch objects moving around in the grey overlay on the mini-map, it's generated live. Aimee. > (Oops wrong reply button again, sorry about the two copies Lawson :) From kfa at gmx.net Tue Jun 3 05:25:12 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 05:25:16 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <48453828.50503@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 03:34, Felix Duesenburg wrote: >> The main question to answer for any such thing to happen is, where's >> the business angle to justify such an effort? Creating interfaces and >> mappings between spaces that were never made with interoperability in >> mind is not a trivial task. Ultimately the customer, the user will >> have to pay for it to be enabled. Is there anything you want to do so >> badly that you'd part with your hard earned L$, PED, gold nuggets or >> real world currency? > > I've spent hundreds of dollars on my avatar over the past three years: > that and land rent for the Coonspiracy is where pretty much everything I > earn in SL goes to. Why wouldn't I spend real money to carry that around > with me? > >> And, even before that, what's the business advantage for the >> respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW as > an elf or a thinly disguised hobbit to play the game? People willing to > pay a premium to have a custom avatar, but not willing to pay a penny to > be a dark elf no matter how fantastic a costume Sony or Blizzard or > whoever come up for it? > Great :) Needed to elicit that mention... I keep forgetting that others like to think differently. I'm not so focused on designing my appearance, more on the aspect of all these worlds/games being used as communication tools. Now, who is going to be able to convince Blizzard and the rest that they want that, too? My guess is that this will be a task of the magnitude of creating a standard for videotape or disk formats... bringing mighty competitors to work together and compromise. Talk about herding cats, big fat ones. From soft at lindenlab.com Tue Jun 3 07:55:44 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 07:55:47 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 4:26 AM, Robin Cornelius wrote: > On Tue, Jun 3, 2008 at 8:25 AM, Jason Giglio wrote: >> Bryan O'Sullivan wrote: >>> I'm pleased to announce that our release (aka "trunk") branch is now >>> built using CMake on all platforms. >>> >> >> I don't see it. Trunk doesn't seem to have it. >> > > I have not seen any SVN commits in the last few days so i presume > thats internally and i assume it will sync up when soft does the > weekly sync. But any chance of getting a sync earlier so i can rattle > through some tests again? I've pushed the current source - have a look at release/. I'm iterating over some Mac cmake export issues right now and installing VS2008 to see how the export fares there. I'll push another today with the things I know about resolved. Please speak up as you find issues with Linux or other Windows build platforms. The cmake release merge marks the point where we -do- start paying close attention to VS2005 and VS2008 builds as well, so if you've been holding back... From kelly at lindenlab.com Tue Jun 3 08:31:52 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 08:31:58 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48449D6B.2040406@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <48449D6B.2040406@cox.net> Message-ID: <484563E8.3050008@lindenlab.com> Lawson English wrote: > Dale Mahalko wrote: >> Probably the best place to look for object tracking and summarizing, >> is in code related to the mini-map. The mini-map seems to be a live >> display of all objects the client has downloaded and is rendering in >> your vicinity, as well as showing the sims that are currently >> communicating with your client. The mini-map seems to act as a sort of >> summary of primitives and other data being actively monitored by the >> client, so tapping into its code could give you most of the object >> data you seek.. >> >> (I wonder if the mini-map may have started life as debugging tool just >> to monitor this background information, but later moved into general >> use as a common user's tool.) >> >> > I believe the mini-map is generated server-side, about once a week. > > > Lawson > Nope, the mini map is generated on the fly in the viewer. The tiles in the world map are generated server-side and are not used in the mini map. - Kelly From mrfrans at gmail.com Tue Jun 3 08:32:44 2008 From: mrfrans at gmail.com (Frans) Date: Tue Jun 3 08:32:48 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <7765f2c60806030832u69fd6812ga0f4de73eea1b4e2@mail.gmail.com> > > Getting people who would have absolutely no interest in visiting WoW as an > elf or a thinly disguised hobbit to play the game? People willing to pay a > premium to have a custom avatar, but not willing to pay a penny to be a dark > elf no matter how fantastic a costume Sony or Blizzard or whoever come up > for it? > It is not just a question if Blizzard and Sony would like that, but also a hardware restriction. They keep avatar modification down, to ensure a reasonable group of people can run the game decently. So even if they are friendly to the idea to let you pay to have your custom avatar, on a large scale it would have a deteriorating for their other customers experience. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/99df7477/attachment.htm From robin.cornelius at gmail.com Tue Jun 3 08:46:32 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 08:46:47 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 3:55 PM, Soft wrote: > Please speak up as you find issues with Linux or other Windows build > platforms. The cmake release merge marks the point where we -do- start > paying close attention to VS2005 and VS2008 builds as well, so if > you've been holding back... > As at r88840/r605 We still have a reference to :- if (WINDOWS) add_subdirectory(copy_win_scripts) endif (WINDOWS) in indra/CMakeLists.txt And no empty folder or flags around the check so its a cmake fail. and VSTool.exe is still not adjusting the projects, same error as before. Running a patch build (VC 2008) of all the possible options to see what comes out the other end... Robin From kelly at lindenlab.com Tue Jun 3 08:52:24 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 08:52:28 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <484568B8.8010705@lindenlab.com> Argent Stonecutter wrote: > On 2008-06-03, at 03:34, Felix Duesenburg wrote: >> The main question to answer for any such thing to happen is, where's >> the business angle to justify such an effort? Creating interfaces and >> mappings between spaces that were never made with interoperability in >> mind is not a trivial task. Ultimately the customer, the user will >> have to pay for it to be enabled. Is there anything you want to do so >> badly that you'd part with your hard earned L$, PED, gold nuggets or >> real world currency? > > I've spent hundreds of dollars on my avatar over the past three years: > that and land rent for the Coonspiracy is where pretty much everything > I earn in SL goes to. Why wouldn't I spend real money to carry that > around with me? > >> And, even before that, what's the business advantage for the >> respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW > as an elf or a thinly disguised hobbit to play the game? People > willing to pay a premium to have a custom avatar, but not willing to > pay a penny to be a dark elf no matter how fantastic a costume Sony or > Blizzard or whoever come up for it? > > I do not think Sony or Blizzard would want that. The key component in the WoW / EQ / AoC interoperability scenario is creative control. None of these products are trying to host a free form virtual world. They are trying to tell a story, they want their characters and their content to match the story they are telling. And the people paying them to play want that story, they want elfs and/or barbarians and adventure and slaying etc etc. They don't want robot overlords from SL, or fashion models or tinies or furies or goreans. The people who have no interest in visiting WoW as an elf etc are not going to be interested in its story or game play - they aren't the target audience and no one would expect them to join WoW. Blizzard does not want to ruin the experience for their millions of paying customers to satisfy the people who aren't interested in their product. That just makes no sense at all. It is not reasonable to ever expect this sort of product to even desire content exchange with other virtual worlds - independent of what technology allows. At most they may be willing to work with identity exchange and communication protocols. Even then consider that in WoW they restrict communication between their own players (no cross faction communication). In short these are not "virtual worlds", they are MMO stories or MMO games but not virtual worlds. The people who don't want to be an Elf etc don't want to play WoW. Effort on interoperability should be focused on the products (potential and existing) that would actually want it. - Kelly From darien_caldwell at comcast.net Tue Jun 3 08:53:55 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Tue Jun 3 08:53:59 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Message-ID: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> -------------- Original message ---------------------- From: Argent Stonecutter > On 2008-06-03, at 00:21, Darien Caldwell wrote: > > It's kind of a moot point. People are already carting off content > > from SL to OpenSim. Yes not Scripts, but everything else. You can > > thank things like that 'Second Inventory' program for that. > > Well, things like SLICE. Second Inventory actually enforces tighter > controls than SL. I got it to try and simplify sharing the stuff I > create with my alts, but the restrictions it imposes make it all but > useless even for products that are 100% mine. I believe they > eventually gave up their scheme of requiring you to buy a separate > copy of each of your alts, but by that time I'd given up on it... it > was less work to set everything full perm, transfer it from Argent > Stonecutter to Argent David, and reset the next owner permissions. Well, I have had several people tell me Second Inventory makes importing items from Second Life to OpenSim a breeze. I believe Second Inventory writes assets to one's hard drive, and it seems these files can then be imported into OpenSim somehow. Perhaps they have found a way to circumvent restrictions the programmer placed within the program. From soft at lindenlab.com Tue Jun 3 08:54:13 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 08:54:15 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 10:46 AM, Robin Cornelius wrote: > On Tue, Jun 3, 2008 at 3:55 PM, Soft wrote: >> Please speak up as you find issues with Linux or other Windows build >> platforms. The cmake release merge marks the point where we -do- start >> paying close attention to VS2005 and VS2008 builds as well, so if >> you've been holding back... >> > > As at r88840/r605 > > We still have a reference to :- > > if (WINDOWS) > add_subdirectory(copy_win_scripts) > endif (WINDOWS) > > in indra/CMakeLists.txt > > And no empty folder or flags around the check so its a cmake fail. Thanks. I fixed that in cmake-9, but not in time to make cmake-9-merge for the release merge. I'll pull that over. From monkowsk at watson.ibm.com Tue Jun 3 09:03:11 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 09:03:34 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> Message-ID: <48456B3F.1070305@watson.ibm.com> I didn't feel like spamming the list with separate replies to each note, so I put them all together here so that anyone who's not interested can just delete a single note. First, although there are technical difficulties, which Tateru Nino pointed out: > That would, of course, require the transfer of the avatar, the account, attachments, textures, LSL scripts(!), animations. Essentially a bit of a free-for-all, asset/content transfer, AND have the scripts reliably executed at the destination. > Let me go out on a very tenuous limb here and suggest "fat chance". and IP issues, which Lawson English pointed out: > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and its appearance? > how willing will said world be to let the avie keep its origianl name and other such thigns? > how willing will said world be to let an externally generated avie be a "first class" citizen? > and so on. and business models, which Felix Duesenberg discussed: > The main question to answer for any such thing to happen is, where's the business angle to justify such an effort? Creating interfaces and mappings between spaces that were never made with interoperability in mind is not a trivial task. Ultimately the customer, the user will have to pay for it to be enabled. Is there anything you want to do so badly that you'd part with your hard earned L$, PED, gold nuggets or real world currency? And, even before that, what's the business advantage for the respective companies running those worlds? > Apart from the technical challenge, you'd have to crack the business models first. If a company makes money by selling you stuff they make in-house, wouldn't they find it hard to see the advantage in opening the floodgate. Why would e.g. MindArk, CCP or Microsoft want that? Why would Linden Labs? Those being answered, we'd have a starting point. Hope I didn't miss a piece. and also > Now, who is going to be able to convince Blizzard and the rest that they want that, too? My guess is that this will be a task of the magnitude of creating a standard for videotape or disk formats... bringing mighty competitors to work together and compromise. Talk about herding cats, big fat ones. and the fact that some transfers are already taking place, which Tateru Nino pointed out: > Assets are already transported between worlds, no code required. Look at the number of content assets in SL that have been ripped from other worlds and from assorted games. > I swear, if I see yet another cybernetic vampire castle made from Unreal 2 textures, I'll probably hurl. that's not really the question I was asking. I'm not so concerned with the question "How?" but rather the question "Why?" Christopher Yeoh wrote: > Between say WoW and SL it may not be important, but between SL and say something > like ActiveWorlds or other virtual world environments with similar purposes > it will be very valuable to not have to reimplement a version of a build > or tailor/dress an avatar for each world. which I understand to be a means to minimize effort. But this leads to a couple more questions: Why would you want to do the same thing in two worlds if there were a mechanism to travel between the two worlds? And aren't building, tailoring, and dressing the fun parts? Why would you want to minimize those? But there are other points of view that I never considered. Felix Duesenberg wrote: > When reading about this discussion I spontaneously dismissed the idea, but upon second thought that is not so clear indeed. A while ago I played Entropia Universe, and took a brief glimpse at EVE Online. I too had fantasies of being somehow able to move my avatar between them. I have no clue what purpose it serves, but the idea is cool in a very fundamental way. and > Great :) Needed to elicit that mention... I keep forgetting that others like to think differently. I'm not so focused on designing my appearance, more on the aspect of all these worlds/games being used as communication tools. I think I have the same bias. But Argent Stonecutter wrote: > I don't believe that it's possible to create an avatar in WoW that will > look like any of my avatars in SL, and frankly I have no interest in > playing Warcraft or Everquest or any other MMORPG until that changes. and > OK. At the moment, my avatar in SL is a ferret. Four legged, about two feet long, which is big for a ferret, I admit, but until LL loosens up on the mesh and skeleton that's the best I can do. > > I have a collar with feathers stuck in it that I wear sometimes. > > If a friend of mine invites me to visit him in WoW, is it possible for me to visit him as this avatar? and also > I've spent hundreds of dollars on my avatar over the past three years: that and land rent for the Coonspiracy is where pretty much everything I earn in SL goes to. Why wouldn't I spend real money to carry that around with me? > >> And, even before that, what's the business advantage for the respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW as an elf or a thinly disguised hobbit to play the game? People willing to pay a premium to have a custom avatar, but not willing to pay a penny to be a dark elf no matter how fantastic a costume Sony or Blizzard or whoever come up for it? which seems to imply that identity is not just an abstract concept that manifests itself differently in different worlds, but rather something visual, that cannot be extended with approximate recreations. Even if WoW allowed ferret avatars, it wouldn't be the same ferret. Am I interpreting this correctly? Mike From sldev at bitparts.org Tue Jun 3 09:11:53 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 09:12:04 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <48456D49.5020105@bitparts.org> I just doubled the memory in my PC from 1.5g to 3g. Since I knew that SL would perform perfectly fine with 2g (having performed well with 1.5g), I loaded up a RAMDisk driver and created a 1G RAMDisk. Testing with various software indicated that the drive was performing phenomenally fast, as expected. I loaded up SL, and set my Cache Folder to a new folder on that empty 1G RAMDisk, and fired things up. SL immediately created the various cache files & structures on the RAMDisk, so I know things were running as intended. The result? Even after loading everything in the sim into the cache, tping between two locations (in the same sim, but outside of draw distance from each other) resulted in ZERO perceptible texture loading speedup. Loading from the RAMDisk was as slow as loading from regular disk. I presume, therefor, that the real bottleneck in the cache isn't reading from the drive. This is horribly dismaying. What progress is there toward an improved caching mechanism? Is there a way to store the textures in a decoded, ready-to-use fashion? Why is the cache so slow? -Buckaroo Mu ps - P4 3ghz, 3gb PC3200 memory, 8600GTS, 320g SATA-2 disk. From soft at lindenlab.com Tue Jun 3 09:28:47 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 09:28:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48456D49.5020105@bitparts.org> References: <48456D49.5020105@bitparts.org> Message-ID: On Tue, Jun 3, 2008 at 11:11 AM, Buckaroo Mu wrote: > What progress is there toward an improved > caching mechanism? Is there a way to store the textures in a decoded, > ready-to-use fashion? Why is the cache so slow? The cache isn't exceptionally slow - it's the jpeg2000 decode that really bites here, and storing those decoded would use copious amounts of disk space. The quickest win would be multiple image decoding threads, seeing as most PCs have two or more cores. No idea if anyone's touching that in the near future, though. From lists at hippygeek.co.uk Tue Jun 3 09:36:56 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Tue Jun 3 09:37:34 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447D74.2050704@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> Message-ID: <48457328.6070009@hippygeek.co.uk> Mike Monkowski wrote: > Why? What advantage is there to sharing builds or avatar meshes > across different platforms? Are they worth the effort? My answer is a resounding yes! The sharing of assets between different 3D worlds is a crucial part of my personal vision of a 3D web. I should add the disclaimer here that I enter this discussion from a background in web technology rather than gaming engines and have quite different views of some architectural points than is perhaps the norm on this list. I can not see how inter-operable 3D worlds can even consider not having avatars which can travel between worlds and objects which the avatar can take with them. Yes, new security models are necessary (you don't want spammers turning up to your peaceful scene brandishing huge billboards), but that is just one of the challenges ahead. The idea of a consistent avatar in principle is similar to the images people can associate with their name in a discussion forum on the web. Interoperability for me would be anyone being able to create a 3D scene in the same way that anyone can create a web page, anyone being able to run a chat server in the same way that anyone can run a Jabber server or IRC server. It would be wandering between 3D scenes in the same way that people browse the web. In terms of business models - why not 3D representations of online stores, advertising in virtual spaces... in short the same business models that surround the web. But really I'm not sure that business models have a great deal to do with creating technology standards. The W3C doesn't tell you how to make money on the web, it tells you how to make a standards compliant web site that everyone can use and will work with the rest of the web. I think any attempt at building business values into technical standards will result in a collection of walled gardens with a frustratingly inconsistent user experience, and never reach the full commercial potential that we've seen with the World Wide Web. Sticking with my 3D Web example, an avatar is just an X3D resource which can be served from a web server and included into a X3D scene in the same way that an HTML resource can be embedded in an iframe in a web page. That's my point of view, from a web perspective, of interoperability. -- Ben Francis http://tola.me.uk From sldev at bitparts.org Tue Jun 3 09:54:13 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 09:54:27 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <48457735.9060900@bitparts.org> Soft wrote: > On Tue, Jun 3, 2008 at 11:11 AM, Buckaroo Mu wrote: > >> What progress is there toward an improved >> caching mechanism? Is there a way to store the textures in a decoded, >> ready-to-use fashion? Why is the cache so slow? >> > > The cache isn't exceptionally slow - it's the jpeg2000 decode that > really bites here, and storing those decoded would use copious amounts > of disk space. The quickest win would be multiple image decoding > threads, seeing as most PCs have two or more cores. No idea if > anyone's touching that in the near future, though. > > Given the dirt-cheap price of HD space these days, why bother compressing the cache, given that the decode is so expensive time-wise? Enlarge the cache maximum size, and toss out the compression - at least give us an option to try it, and see. A simple checkbox or debug option "UseCompressedCache" or somesuch defaulted to yes - then those of us with plenty of space can try it out. People are screaming about texture load times - I can't imagine they wouldn't sacrifice some disk space for a large boost in performance. From danteferret at gmail.com Tue Jun 3 10:03:14 2008 From: danteferret at gmail.com (Dante Tucker) Date: Tue Jun 3 10:03:16 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457735.9060900@bitparts.org> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> Message-ID: <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> I definatly second this as an option. Provided there is no technical reason this can't be done :) On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu wrote: > > > Given the dirt-cheap price of HD space these days, why bother compressing > the cache, given that the decode is so expensive time-wise? Enlarge the > cache maximum size, and toss out the compression - at least give us an > option to try it, and see. A simple checkbox or debug option > "UseCompressedCache" or somesuch defaulted to yes - then those of us with > plenty of space can try it out. People are screaming about texture load > times - I can't imagine they wouldn't sacrifice some disk space for a large > boost in performance. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/59e37d3b/attachment.htm From tateru.nino at gmail.com Tue Jun 3 10:08:43 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 10:09:23 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> Message-ID: <48457A9B.1010704@weblogsinc.com> Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From robin.cornelius at gmail.com Tue Jun 3 10:10:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 10:10:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48456D49.5020105@bitparts.org> References: <48456D49.5020105@bitparts.org> Message-ID: > > The result? Even after loading everything in the sim into the cache, tping > between two locations (in the same sim, but outside of draw distance from > each other) resulted in ZERO perceptible texture loading speedup. Loading > from the RAMDisk was as slow as loading from regular disk. I presume, > therefor, that the real bottleneck in the cache isn't reading from the > drive. This is horribly dismaying. What progress is there toward an improved > caching mechanism? Is there a way to store the textures in a decoded, > ready-to-use fashion? Why is the cache so slow? > Are you *sure* all textures are indeed being loaded from the cache and not being requested from the servers. I noticed some excessively large texture downloading when doing textures tests and i would have expected many of them to be in the cache but they were not (or may be they had just been culled/purged). I didn't do a lot of testing specifically in this area but the texture console can help also adding debug lines to lltexturefetch.cpp is probably a good check too to see which textures take which path. Robin From robin.cornelius at gmail.com Tue Jun 3 10:15:02 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 10:15:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457A9B.1010704@weblogsinc.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: On Tue, Jun 3, 2008 at 6:08 PM, Tateru Nino wrote: > Use a PNG or vanilla jpg compressor to save space on disk (and let the user > set the compression quality with a slider to let them decide how much > bang-for-the-buck they want out of their chosen megabytes of storage), then > you've got far less work to do decoding than the jpeg2000 decompressor -- or > so I presume. If I got all that fatally wrong, just whack me with a rolled > up man page. Format must be capable of saving alpha channels as well. i don't believe standard jpeg does this. You also have the overhead of an additional encoding which may only be done once, but if you are flicking around would be come a headache and would just get turned off. Also re encoding, need to be careful if it was lossless image, especially sculpties or they will just turn to **** with compression artifacts. Most (processor) efficient way to save files is to just save the LLRawImage data as it is, then it can be directly recalled into a new LLRawImage when its recalled. This should maximize speed and disk space usage at the same time ;-) Robin From sldev at bitparts.org Tue Jun 3 10:28:42 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 10:28:52 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <48457F4A.4060508@bitparts.org> Robin Cornelius wrote: > Are you *sure* all textures are indeed being loaded from the cache and > not being requested from the servers. I noticed some excessively large > texture downloading when doing textures tests and i would have > expected many of them to be in the cache but they were not (or may be > they had just been culled/purged). I didn't do a lot of testing > specifically in this area but the texture console can help also adding > debug lines to lltexturefetch.cpp is probably a good check too to see > which textures take which path. > > Robin > > Positive. Waited until everything had fully rezzed, turned slowly & repeated the process - etc. Stayed in one area about 30 minutes. Tped (actually warpPos'ed) to another area of the sim, then came right back - and texture loading was a slow as disk-based cache. Various other methods of testing backed up these results. From monkowsk at watson.ibm.com Tue Jun 3 10:48:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 10:49:47 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484568B8.8010705@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> Message-ID: <484583F1.9020505@watson.ibm.com> Kelly Linden wrote: > In short these [WoW / EQ / AoC] are not "virtual worlds", they are MMO stories or MMO > games but not virtual worlds. The people who don't want to be an Elf > etc don't want to play WoW. Effort on interoperability should be > focused on the products (potential and existing) that would actually > want it. I'm not a supply-sider so that fact that Sony or Blizzard don't "actually want it" doesn't seem like a useful predictor of the future. Would you consider Little Big Planet to be a MMO game or a virtual world? The pigeonholes are changing. Mike From sean at lindenlab.com Tue Jun 3 11:10:37 2008 From: sean at lindenlab.com (Sean Lynch) Date: Tue Jun 3 11:10:39 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> On Tue, Jun 3, 2008 at 10:15 AM, Robin Cornelius wrote: > Format must be capable of saving alpha channels as well. i don't > believe standard jpeg does this. You also have the overhead of an > additional encoding which may only be done once, but if you are > flicking around would be come a headache and would just get turned > off. Also re encoding, need to be careful if it was lossless image, > especially sculpties or they will just turn to **** with compression > artifacts. > > Most (processor) efficient way to save files is to just save the > LLRawImage data as it is, then it can be directly recalled into a new > LLRawImage when its recalled. This should maximize speed and disk > space usage at the same time ;-) > I suspect PNG with a zlib compression level of 1-3 would be faster overall due to saving the time to read the data off the disk. Of course, the compression level only affects compression speed. Perhaps it's time to revisit the format textures are stored in on the asset system. Or maybe we'll do that after allowing externally hosted HTTP textures. I believe the main advantages of jpeg2000 are the less distressing artifacts for high compression and the ability to decode progressively without looking like crap during the download. High compression factor, as people have mentioned, is pretty irrelevant, so progressive jpeg with a 75-90% quality level and some postprocessing might be just as good with far less CPU usage? I thought we already had a separate texture decoding thread; isn't that what "enable multiple threads" does in the advanced menu? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/2cd81264/attachment.htm From monkowsk at watson.ibm.com Tue Jun 3 11:10:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 11:17:02 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48457328.6070009@hippygeek.co.uk> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> Message-ID: <48458901.8030002@watson.ibm.com> I cringe every time I hear 3D virtual worlds discussed as "The 3D Web." The 2D web is primarily static, one directional, and lonely. Yes, there are chat rooms, MySpace, and blogs--the Web 2.0 stuff--but when you're talking about "3D representations of online stores, advertising in virtual spaces... in short the same business models that surround the web" you're not talking about communication and collaboration, you're still talking about marketing. If you call it Web 3.0, then I might give you the benefit of the doubt, but if you're still talking about "The 3D Web," I don't think you understand virtual worlds. "The Web" is about providing. Virtual worlds are about collaborating. Mike Ben Francis wrote: > My answer is a resounding yes! The sharing of assets between different > 3D worlds is a crucial part of my personal vision of a 3D web. I should > add the disclaimer here that I enter this discussion from a background > in web technology rather than gaming engines and have quite different > views of some architectural points than is perhaps the norm on this list. > > I can not see how inter-operable 3D worlds can even consider not having > avatars which can travel between worlds and objects which the avatar can > take with them. Yes, new security models are necessary (you don't want > spammers turning up to your peaceful scene brandishing huge billboards), > but that is just one of the challenges ahead. > > The idea of a consistent avatar in principle is similar to the images > people can associate with their name in a discussion forum on the web. > > Interoperability for me would be anyone being able to create a 3D scene > in the same way that anyone can create a web page, anyone being able to > run a chat server in the same way that anyone can run a Jabber server or > IRC server. It would be wandering between 3D scenes in the same way that > people browse the web. > > In terms of business models - why not 3D representations of online > stores, advertising in virtual spaces... in short the same business > models that surround the web. But really I'm not sure that business > models have a great deal to do with creating technology standards. The > W3C doesn't tell you how to make money on the web, it tells you how to > make a standards compliant web site that everyone can use and will work > with the rest of the web. I think any attempt at building business > values into technical standards will result in a collection of walled > gardens with a frustratingly inconsistent user experience, and never > reach the full commercial potential that we've seen with the World Wide > Web. > > Sticking with my 3D Web example, an avatar is just an X3D resource which > can be served from a web server and included into a X3D scene in the > same way that an HTML resource can be embedded in an iframe in a web page. > > That's my point of view, from a web perspective, of interoperability. > From kelly at lindenlab.com Tue Jun 3 11:19:09 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 11:19:10 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484583F1.9020505@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> Message-ID: <48458B1D.8030502@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/6cd345b1/attachment.htm From mark.burhop at gmail.com Tue Jun 3 12:22:51 2008 From: mark.burhop at gmail.com (Mark Burhop) Date: Tue Jun 3 12:22:56 2008 Subject: [sldev] Re: UC presentation on Importing Geometry into SL In-Reply-To: <773a33dc0805291459m4902844ao6c2d77f19b8da38@mail.gmail.com> References: <773a33dc0805291459m4902844ao6c2d77f19b8da38@mail.gmail.com> Message-ID: <773a33dc0806031222m49b67936j1199ee51c9bedf31@mail.gmail.com> FYI - happening now. On Thu, May 29, 2008 at 5:59 PM, Mark Burhop wrote: > I wanted to let you know the University of Cincinnati will be doing a > presentation from Orlando next week on importing geometry into Second Life. > Siemens has a conference there and have sponsored some of their work. > > > > The presentation will be done in Second Life from 4:30 to 5:30 EST (1:30 > SLT) Tue 6/3/2008 so just click on the SLURL below: > > > http://slurl.com/secondlife/Siemens%20innovation%20Connection/168/157/22/ > > As a side note, I know there are a lot of people running into the > limitations of prims, sculpties, and prim counts for bringing in data from > their favorite 3D tool. I'd love to hear more discussion and idea sharing > on the general problem. > > Mark (Burhop Piccard) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/5bfb7089/attachment.htm From carjay at gmx.net Tue Jun 3 12:40:05 2008 From: carjay at gmx.net (Carsten Juttner) Date: Tue Jun 3 12:40:13 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> Message-ID: <48459E15.1020503@gmx.net> Sean Lynch wrote: > > I thought we already had a separate texture decoding thread; isn't > that what "enable multiple threads" does in the advanced menu? I looked at that code a while ago, from what I saw threads are always enabled (but note that not every "thread" that is derived from one of the thread classes is actually run threaded. The place to look at here is initThreads() in llappviewer.cpp. So if I see this correctly, texture decoding and texture caching thread are currently run threaded, only the texture fetching is not. As for the advanced switch "Run Multiple Threads": if it is enabled, the texture decoding and caching threads are run in parallel with rendering, else they are put to sleep right before (but they are not frozen so I guess depending on the workload it's possible that one of them extends into the begin of rendering which is probably the cause for VWR-4067 since it occured in a debug build where things naturally run a bit slower). Also if MEM_TRACK is defined, threading is disabled (all "threads" run in the main thread in this case). Carsten From sldev at bitparts.org Tue Jun 3 13:01:33 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 13:01:44 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: <4845A31D.10002@bitparts.org> > Most (processor) efficient way to save files is to just save the > LLRawImage data as it is, then it can be directly recalled into a new > LLRawImage when its recalled. This should maximize speed and disk > space usage at the same time ;-) > This is my thought. If I want to compress the cache, I'll tell Windows to compress that folder - no, not seriously. I have something on the order of 100gb free on my main storage drive - I'd be more than willing to commit 10g of that to SL cache, and storing the objects as flat-out decompressed ready-to-use (llRawImage?) data would be the logical thing to do. From missannotoole at yahoo.com Tue Jun 3 15:26:12 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 3 15:26:15 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <617974.16404.qm@web59110.mail.re1.yahoo.com> Time Warner is going to try forcing metered bandwith on the cable modem community they serve. So the ugly head of the end of unlimited bandwith use raises it's head once again. (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) Has anyone measured actual bandwith utilization to the point people can predict their usage per month before they get slapped with killer bills? The reason I mention this is because, although I am also a fan of reduced compression overhead, there will no doubt be trade offs required. Perhaps there is a way to make compression/decompression more efficient? ----- Original Message ---- From: Tateru Nino To: Dante Tucker Cc: Second Life Developer Mailing List Sent: Tuesday, June 3, 2008 1:08:43 PM Subject: Re: [sldev] Cache speed experiment & results... Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/49b29f7c/attachment.htm From dmahalko at gmail.com Tue Jun 3 15:59:40 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 15:59:43 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845A31D.10002@bitparts.org> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: The price of huge storage capacities has fallen like a stone in the past two years. It seems crazy that I should be able to buy a 250 gig 7200 RPM SATA-3.0 hard drive for US$58 on NewEgg. I do wonder if the drive manufacturers are looking over their shoulder and fearing the arrival of solid state drives. Therefore, I would be in favor of storing uncompressed cache data for all cache types, including sound files, and without a defined storage limit. Even a 10 gig cache seems far too small. Just as LL raises the bar with WindLight for higher performance 3D cards, it should also raise the bar for performance increases via huge uncompressed caches. SL wants 10 gig for basic performance, and optionally, 100 gig for enhanced performance? Well, sure, I suppose I can handle that. There are however filesystem limitations that may cause slowdowns, and there may be diminishing returns at some point if only the local OS is relied upon for huge caching storage. I would be interested to see what performance gain is possible by have a dedicated slave MySQL database running on the client PC when using a ridiculously huge cache size.. Windows isn't good at dealing with directories containing tens of thousands of files. Ever tried opening a folder containing 20,000 files? There is a delay of several seconds trying to do this in Windows. Also the hidden MFT and directory structures can become ridiculously fragmented, also leading to slowdowns. A proper local database engine would likely deal with these huge numbers of tiny files more efficiently than the local operating system. An alternative would be to leave a large portion of system memory free to cache these huge directory structures alongside the client, say 2-4 gig of memory free, over and above what the client is using. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 3:01 PM, Buckaroo Mu wrote: > This is my thought. If I want to compress the cache, I'll tell Windows to > compress that folder - no, not seriously. I have something on the order of > 100gb free on my main storage drive - I'd be more than willing to commit 10g > of that to SL cache, and storing the objects as flat-out decompressed > ready-to-use (llRawImage?) data would be the logical thing to do. From robin.cornelius at gmail.com Tue Jun 3 16:13:34 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 16:13:40 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <4845D01E.5070309@gmail.com> Dale Mahalko wrote: > > There are however filesystem limitations that may cause slowdowns, and > there may be diminishing returns at some point if only the local OS is > relied upon for huge caching storage. I would be interested to see > what performance gain is possible by have a dedicated slave MySQL > database running on the client PC when using a ridiculously huge cache > size.. From what figures i have seen from random googling file system should still be significantly quicker access than via MySQL. I started hacking in a mysql read/write for the cache, just for the hell of it but fully expect it to be slower than the cache and its on the big stack of things to do. > > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. Yes this is an issue where the DB's could achieve better performance. Or possibly caches such as squid although how that could directly be used with the current set up is not obvious to me. Linux has optimisation options if you know a FS will be used for lots of files Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/b3cbbc54/signature-0001.pgp From tongb at ohio.edu Tue Jun 3 17:01:09 2008 From: tongb at ohio.edu (Bruce Tong) Date: Tue Jun 3 17:01:12 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> I'm pulling down the .zip files containing the source to a Windows box and I don't find the develop.py script. I don't see it in the TAR balls on my Linux box either, though I pulled them down last week. I'm guessing the CMake support is something I'm only going to find pulling source from SVN right now, or am I just blind? I've looked around the source folders and re-read a dozen wiki pages and I must be missing something. On Tue, Jun 3, 2008 at 10:55 AM, Soft wrote: >>>> I'm pleased to announce that our release (aka "trunk") branch is now >>>> built using CMake on all platforms. >>> >>> I don't see it. Trunk doesn't seem to have it. >> >> I have not seen any SVN commits in the last few days so i presume >> thats internally and i assume it will sync up when soft does the >> weekly sync. But any chance of getting a sync earlier so i can rattle >> through some tests again? > > I've pushed the current source - have a look at release/. I'm > iterating over some Mac cmake export issues right now and installing > VS2008 to see how the export fares there. I'll push another today with > the things I know about resolved. > > Please speak up as you find issues with Linux or other Windows build > platforms. The cmake release merge marks the point where we -do- start > paying close attention to VS2005 and VS2008 builds as well, so if > you've been holding back... -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Tue Jun 3 17:09:27 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 17:09:34 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> Message-ID: You'd need to pull from subversion, or you can download the tarballs/zip files linked from a message in the sldev-commits mailing list. The most recent release commit is here: https://lists.secondlife.com/pipermail/sldev-commits/2008-June/000858.html On Tue, Jun 3, 2008 at 7:01 PM, Bruce Tong wrote: > I'm pulling down the .zip files containing the source to a Windows box > and I don't find the develop.py script. I don't see it in the TAR > balls on my Linux box either, though I pulled them down last week. > > I'm guessing the CMake support is something I'm only going to find > pulling source from SVN right now, or am I just blind? I've looked > around the source folders and re-read a dozen wiki pages and I must be > missing something. > > On Tue, Jun 3, 2008 at 10:55 AM, Soft wrote: >>>>> I'm pleased to announce that our release (aka "trunk") branch is now >>>>> built using CMake on all platforms. >>>> >>>> I don't see it. Trunk doesn't seem to have it. >>> >>> I have not seen any SVN commits in the last few days so i presume >>> thats internally and i assume it will sync up when soft does the >>> weekly sync. But any chance of getting a sync earlier so i can rattle >>> through some tests again? >> >> I've pushed the current source - have a look at release/. I'm >> iterating over some Mac cmake export issues right now and installing >> VS2008 to see how the export fares there. I'll push another today with >> the things I know about resolved. >> >> Please speak up as you find issues with Linux or other Windows build >> platforms. The cmake release merge marks the point where we -do- start >> paying close attention to VS2005 and VS2008 builds as well, so if >> you've been holding back... > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > From kfa at gmx.net Tue Jun 3 17:12:00 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 17:12:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <4845DDD0.70305@gmx.net> Dale Mahalko wrote: > ... > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > Reiser4 is excellent with exactly these requirements. It's not mature enough to be considered reliable for critical systems, but for a cache? It doesn't help that Reiser himself is removed from the development process, but it's still there and the source available. Shouldn't that be possible to be included as a virtual filesystem even under Windows? I also always thought it must be a good way to boost performance if the cache lived on its own partition, like a Linux swap partition. For the Linux version of SL this would even sound like the most natural way to do it. Setting such a thing up on an existing Windows machine has a slight fear factor attached and is not for everyone, but if a savvy user can handle it, why not offer. I'm speculating, but the difference could be dramatic, especially if we had a better file system than NTFS on that partition. > > A proper local database engine would likely deal with these huge > numbers of tiny files more efficiently than the local operating > system. Yes, but the usual architecture with the database running as a localhost server is not ideal for our situation since everything is squeezed back and forth through the network system, plus SQL parsing, unnecessarily. With MySQL you could build directly on top of the storage engine though, even bypassing the parsing with direct API calls. It would just serve as a virtual file system the same way as suggested above. I still believe that Reiser4 would be even faster. And according to the description on its (now defunct) website, they claimed reaching 94% package density with small files. Felix From open at autistici.org Tue Jun 3 17:15:55 2008 From: open at autistici.org (Opensource Obscure) Date: Tue Jun 3 17:15:58 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: <9d9cb078fe67b0a06978abad84317d50@localhost> On Tue, 3 Jun 2008 09:55:44 -0500, Soft wrote: > Please speak up as you find issues with Linux or other Windows build > platforms. I'm new to this, please be patient. I'm on Linux Ubuntu 8.04 32bit and I managed to build the viewer some weeks ago on the same system. I'm using the tarballs at http://svn.secondlife.com/trac/linden/changeset/598 Here's what I did: tar xzf slviewer-linux-libs-... tar xzf slviewer-src-... unzip slviewer-artwork-... tar xzf fmodapi375linux.tar.gz cp fmodapi375linux/api/inc/* linden/libraries/i686-linux/include/ cp fmodapi375linux/api/libfmod-3.75.so linden/libraries/i686-linux/lib_release_client/ cd linden/indra/ ./develop.py cd viewer-linux-i686/ make I got errors as descripted in VWR-4456, so I modified indra/cmake/00-Common.cmake according to Michelle2 Zenovka's patch. I also had to install libboost-program-options-dev. If I get it right, the issue with libboost is known, however this library is not directly mentioned at the wiki page https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) Should I add it as a dependency somewhere in that page? At the next try, I got this: [100%] Built target secondlife-bin [100%] Generating ../../newview/secondlife-stripped-globalsyms [100%] Generating ../../newview/secondlife-stripped [100%] Generating ../../newview/SecondLife-i686-1.20.6.0.tar.bz2 File ".../linden/indra/newview/viewer_manifest.py", line 230 def nsi_file_commands(self, install=True): ^ SyntaxError: invalid syntax make[2]: *** [../newview/SecondLife-i686-1.20.6.0.tar.bz2] Error 1 make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 make: *** [all] Error 2 hope this helps. Opensource Obscure http://friendfeed.com/oobscure From steve at lindenlab.com Tue Jun 3 17:17:35 2008 From: steve at lindenlab.com (Steve Bennetts (Steve Linden)) Date: Tue Jun 3 17:17:37 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <4845DF1F.6060007@lindenlab.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080603/77939afa/signature.pgp From dahliatrimble at gmail.com Tue Jun 3 17:45:06 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 3 17:45:08 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845DDD0.70305@gmx.net> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: If the goal were to improve seek time in a cache, how about keeping the cache on one of those readyboost-capable usb flash drives? They can have seek times as low as 1 ms or better, although the transfer rate and write times arent all that fast. Then again it's probably moot if the bottleneck is the decoding :/ On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: > Dale Mahalko wrote: > >> ... >> Windows isn't good at dealing with directories containing tens of >> thousands of files. Ever tried opening a folder containing 20,000 >> files? There is a delay of several seconds trying to do this in >> Windows. Also the hidden MFT and directory structures can become >> ridiculously fragmented, also leading to slowdowns. >> >> > Reiser4 is excellent with exactly these requirements. It's not mature > enough to be considered reliable for critical systems, but for a cache? It > doesn't help that Reiser himself is removed from the development process, > but it's still there and the source available. Shouldn't that be possible to > be included as a virtual filesystem even under Windows? > > I also always thought it must be a good way to boost performance if the > cache lived on its own partition, like a Linux swap partition. For the Linux > version of SL this would even sound like the most natural way to do it. > Setting such a thing up on an existing Windows machine has a slight fear > factor attached and is not for everyone, but if a savvy user can handle it, > why not offer. I'm speculating, but the difference could be dramatic, > especially if we had a better file system than NTFS on that partition. > > > > > A proper local database engine would likely deal with these huge > > numbers of tiny files more efficiently than the local operating > > system. > > Yes, but the usual architecture with the database running as a localhost > server is not ideal for our situation since everything is squeezed back and > forth through the network system, plus SQL parsing, unnecessarily. With > MySQL you could build directly on top of the storage engine though, even > bypassing the parsing with direct API calls. It would just serve as a > virtual file system the same way as suggested above. I still believe that > Reiser4 would be even faster. And according to the description on its (now > defunct) website, they claimed reaching 94% package density with small > files. > > Felix > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/98809374/attachment-0001.htm From lists at hippygeek.co.uk Tue Jun 3 17:49:43 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Tue Jun 3 17:50:18 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48458901.8030002@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> <48458901.8030002@watson.ibm.com> Message-ID: <4845E6A7.4070105@hippygeek.co.uk> Mike Monkowski wrote: > I cringe every time I hear 3D virtual worlds discussed as "The 3D Web." The 3D Web is one method of delivering 3D scenes over a network and is a term used by the Web3D Consortium who define standards to do just that. I do not intend to use the terms "3D Web" and "Virtual Worlds" interchangeably. The 3D web is just one approach which in combination with other Internet standards (for authentication, instant messaging, currency etc.) can be used to create virtual worlds. That's what my disclaimer was for. > The 2D web is primarily static, one directional, and lonely. I would not describe the web applications I use every day with any of those words. > Yes, there are chat rooms, MySpace, and blogs--the Web 2.0 stuff-- Web 2.0 = Web 1.0 > but when you're talking about "3D representations of online stores, > advertising in virtual spaces... in short the same business models > that surround the web" you're not talking about communication and > collaboration, you're still talking about marketing. My point really was that the business models are in the applications, not the platform. Perhaps the examples I gave weren't very imaginative, but that's because I think we're discussing architectures, not business plans here. > > If you call it Web 3.0, then I might give you the benefit of the > doubt, but if you're still talking about "The 3D Web," I don't think > you understand virtual worlds. I'm sorry, but as far as I'm concerned web 3.0 is as much of a ridiculous term as web 2.0. The web is the web, it is continuously evolving and I believe is only currently in its early stages. The kind of things people refer to as "Web 2.0" are simply realizing the read/write nature originally intended by Sir Tim Berners-Lee (see his book, Weaving the Web). The term 3D Web describes quite precisely what it is I'm talking about. XML served over HTTP (or alternative asynchronous protocols) which represents web resources as 3D graphics. > "The Web" is about providing. Virtual worlds are about collaborating. I would argue that the web is an information space and virtual worlds are one way of representing that information. Collaboration can happen in many ways. If you want to call the new web standards that the W3C is currently working on "Web 3.0" then fair enough. But they are certainly more than just delivering static text in one direction, they are about device independent, distributed applications with a focus on collaboration and multimodal user interfaces to semantically rich data - The 3D Web is part of the web of the future. Anyway, in defending my semantics I have strayed off the original point. The point is that assets should be able to move between virtual worlds and this should be built in as standard from the start, not using a never ending list of import/export scripts in the future. MMORPGs are one use (for entertainment) of virtual worlds which may require certain stylistic restrictions on content, but this does not mean that other applications (perhaps the majority) would not want to be able to freely move assets between 3D scenes. Apologies for being long winded! Regards Ben -- Ben Francis http://tola.me.uk From soft at lindenlab.com Tue Jun 3 17:53:30 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 17:53:33 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <61a5f47b10aafc4ff71eb929813bd563@localhost> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> Message-ID: On Tue, Jun 3, 2008 at 7:13 PM, Opensource Obscure wrote: > > I also had to install libboost-program-options-dev. If I get it > right, the issue with libboost is known, however this library is > not directly mentioned at the wiki page > https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) > Should I add it as a dependency somewhere in that page? Please do. All of the compiling pages are going to need an overhaul, but that can wait for the 1.21 viewer branch, after cmake has completely settled in. > At the next try, I got this: > > [100%] Built target secondlife-bin > [100%] Generating ../../newview/secondlife-stripped-globalsyms > [100%] Generating ../../newview/secondlife-stripped > [100%] Generating ../../newview/SecondLife-i686-1.20.6.0.tar.bz2 > File ".../linden/indra/newview/viewer_manifest.py", line 230 > def nsi_file_commands(self, install=True): > ^ > SyntaxError: invalid syntax > make[2]: *** [../newview/SecondLife-i686-1.20.6.0.tar.bz2] Error 1 > make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 > make: *** [all] Error 2 That's been fixed in a subsequent release dump. Try grabbing the newest and I suspect you'll make it clean through. From dmahalko at gmail.com Tue Jun 3 18:10:13 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 18:10:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: I do apologize, but it appears I'm conflating two different caching problems. The one I'm thinking about involves enlarging the number of individual files in the cache by 10 to 100 times. This leads to file search and directory caching problems, and might need a separate partition or DB management engine to handle hundreds of thousands of locally cached files. An optional fully-decoded cache likely would not run into these problems, since it would end up being a second but identical directory structure equal to the current one, except containing all-uncompressed data. A 2x increase in directory structure size probably would not significantly change the file lookup performance.. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 7:45 PM, Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping the > cache on one of those readyboost-capable usb flash drives? They can have > seek times as low as 1 ms or better, although the transfer rate and write > times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ From sakkaku at gmail.com Tue Jun 3 18:11:54 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue Jun 3 18:11:57 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping the > cache on one of those readyboost-capable usb flash drives? They can have > seek times as low as 1 ms or better, although the transfer rate and write > times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > > On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: >> >> Dale Mahalko wrote: >>> >>> ... >>> Windows isn't good at dealing with directories containing tens of >>> thousands of files. Ever tried opening a folder containing 20,000 >>> files? There is a delay of several seconds trying to do this in >>> Windows. Also the hidden MFT and directory structures can become >>> ridiculously fragmented, also leading to slowdowns. >>> >> >> Reiser4 is excellent with exactly these requirements. It's not mature >> enough to be considered reliable for critical systems, but for a cache? It >> doesn't help that Reiser himself is removed from the development process, >> but it's still there and the source available. Shouldn't that be possible to >> be included as a virtual filesystem even under Windows? >> >> I also always thought it must be a good way to boost performance if the >> cache lived on its own partition, like a Linux swap partition. For the Linux >> version of SL this would even sound like the most natural way to do it. >> Setting such a thing up on an existing Windows machine has a slight fear >> factor attached and is not for everyone, but if a savvy user can handle it, >> why not offer. I'm speculating, but the difference could be dramatic, >> especially if we had a better file system than NTFS on that partition. >> >> > >> > A proper local database engine would likely deal with these huge >> > numbers of tiny files more efficiently than the local operating >> > system. >> >> Yes, but the usual architecture with the database running as a localhost >> server is not ideal for our situation since everything is squeezed back and >> forth through the network system, plus SQL parsing, unnecessarily. With >> MySQL you could build directly on top of the storage engine though, even >> bypassing the parsing with direct API calls. It would just serve as a >> virtual file system the same way as suggested above. I still believe that >> Reiser4 would be even faster. And according to the description on its (now >> defunct) website, they claimed reaching 94% package density with small >> files. >> >> Felix SQLite in a single user environment is incredibly fast so long as you don't let the database grow too large. Of course you have to figure out how efficiently textures can be stored and retrieved in SQL compared to the current caching system. On a side note: Does anyone know where it defines the polygon meshes for rendering cubes. I really want to try forcing untwisted, un-holed cubes down to 1-2 polygons per side and see if that will help out with the frame rate. I tried looking through the source but it is lacking in [helpful] comments. From lenglish5 at cox.net Tue Jun 3 19:04:09 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 3 19:04:11 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4845E6A7.4070105@hippygeek.co.uk> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> <48458901.8030002@watson.ibm.com> <4845E6A7.4070105@hippygeek.co.uk> Message-ID: <4845F819.4020708@cox.net> Ben Francis wrote: > [...] > > Anyway, in defending my semantics I have strayed off the original point. > > The point is that assets should be able to move between virtual worlds > and this should be built in as standard from the start, not using a > never ending list of import/export scripts in the future. > > MMORPGs are one use (for entertainment) of virtual worlds which may > require certain stylistic restrictions on content, but this does not > mean that other applications (perhaps the majority) would not want to > be able to freely move assets between 3D scenes. > > Apologies for being long winded! There are topics that the AW Groupies deal with regularly in group IM, and in the weekly meetings at Thornbridgetown and Zero Linden's office in Grasmere. From the way you discuss things, I get the impression you're not participating in either the theoretical discussions or in their practical implementation via the OGP (AKA SLOGP). Can it be that you're not familiar with them? Lawson https://wiki.secondlife.com/wiki/Category:AW_Groupies#Chat_Logs http://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 From secret.argent at gmail.com Tue Jun 3 19:17:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:15:55 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48453828.50503@gmx.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <48453828.50503@gmx.net> Message-ID: On 2008-06-03, at 07:25, Felix Duesenburg wrote: > My guess is that this will be a task of the magnitude of creating a > standard for videotape or disk formats. You think it's that simple? that's encouraging! :) From nexeus at nexeusfatale.com Tue Jun 3 19:23:12 2008 From: nexeus at nexeusfatale.com (Nexeus Fatale) Date: Tue Jun 3 19:23:16 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> Message-ID: I wonder if anyone has tested the run multiple threads and have found any improvements - Nexeus On Tue, Jun 3, 2008 at 9:11 PM, Matthew Underwood wrote: > On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: >> If the goal were to improve seek time in a cache, how about keeping the >> cache on one of those readyboost-capable usb flash drives? They can have >> seek times as low as 1 ms or better, although the transfer rate and write >> times arent all that fast. >> >> Then again it's probably moot if the bottleneck is the decoding :/ >> >> On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: >>> >>> Dale Mahalko wrote: >>>> >>>> ... >>>> Windows isn't good at dealing with directories containing tens of >>>> thousands of files. Ever tried opening a folder containing 20,000 >>>> files? There is a delay of several seconds trying to do this in >>>> Windows. Also the hidden MFT and directory structures can become >>>> ridiculously fragmented, also leading to slowdowns. >>>> >>> >>> Reiser4 is excellent with exactly these requirements. It's not mature >>> enough to be considered reliable for critical systems, but for a cache? It >>> doesn't help that Reiser himself is removed from the development process, >>> but it's still there and the source available. Shouldn't that be possible to >>> be included as a virtual filesystem even under Windows? >>> >>> I also always thought it must be a good way to boost performance if the >>> cache lived on its own partition, like a Linux swap partition. For the Linux >>> version of SL this would even sound like the most natural way to do it. >>> Setting such a thing up on an existing Windows machine has a slight fear >>> factor attached and is not for everyone, but if a savvy user can handle it, >>> why not offer. I'm speculating, but the difference could be dramatic, >>> especially if we had a better file system than NTFS on that partition. >>> >>> > >>> > A proper local database engine would likely deal with these huge >>> > numbers of tiny files more efficiently than the local operating >>> > system. >>> >>> Yes, but the usual architecture with the database running as a localhost >>> server is not ideal for our situation since everything is squeezed back and >>> forth through the network system, plus SQL parsing, unnecessarily. With >>> MySQL you could build directly on top of the storage engine though, even >>> bypassing the parsing with direct API calls. It would just serve as a >>> virtual file system the same way as suggested above. I still believe that >>> Reiser4 would be even faster. And according to the description on its (now >>> defunct) website, they claimed reaching 94% package density with small >>> files. >>> >>> Felix > > SQLite in a single user environment is incredibly fast so long as you > don't let the database grow too large. Of course you have to figure > out how efficiently textures can be stored and retrieved in SQL > compared to the current caching system. > > On a side note: Does anyone know where it defines the polygon meshes > for rendering cubes. I really want to try forcing untwisted, un-holed > cubes down to 1-2 polygons per side and see if that will help out with > the frame rate. I tried looking through the source but it is lacking > in [helpful] comments. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Tue Jun 3 19:34:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:33:06 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484568B8.8010705@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> Message-ID: <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> On 2008-06-03, at 10:52, Kelly Linden wrote: > Argent Stonecutter wrote: >> On 2008-06-03, at 03:34, Felix Duesenburg wrote: >>> And, even before that, what's the business advantage for the >>> respective companies running those worlds? >> >> Getting people who would have absolutely no interest in visiting >> WoW as an elf or a thinly disguised hobbit to play the game? >> People willing to pay a premium to have a custom avatar, but not >> willing to pay a penny to be a dark elf no matter how fantastic a >> costume Sony or Blizzard or whoever come up for it? > I do not think Sony or Blizzard would want that. And that's probably a good thing. For Linden Labs, anyway. :) But that doesn't mean there's no companies that do... good golly, I can think of at least one example. > It is not reasonable to ever expect this sort of product to even > desire content exchange with other virtual worlds Maybe. Maybe not. D&D was designed to appeal to people who wanted to play elves and hobbits and things, and pretty soon people started coming up with other kinds of fantasy settings, and TSR came up with SF-based games, and then Steve Jackson came up with GURPS... the Grand Universal Role Playing System, and pretty soon everyone, including whoever owns D&D this week, had a "universal role playing system" ... I think the newest iteration of D&D is the D20 universal role playing system. As virtual role playing environments evolve, people playing in the equivalent of Gamma World and Champions and D&D and Runequest and Car Wars are going to eventually want to get together, as their avatars. You're going to have the online equivalents of Munden's Bar, where all the metaverses come together. And you're going to have role playing scenarios played out in the Gallimaufry, or whatever this universal nexus is called. Because that's what happened in the tabletop role playing world. So it doesn't really matter whether Blizzard *right now* wants this to happen. Someone will. Linden Labs thinks Second Life should be that place. I kind of agree, but part of me kind of doesn't, and part of me is off making fun of the other two parts of me... Where was I? > In short these are not "virtual worlds", they are MMO stories or > MMO games but not virtual worlds. The people who don't want to be > an Elf etc don't want to play WoW. Effort on interoperability > should be focused on the products (potential and existing) that > would actually want it. It doesn't matter to me whether it's Blizzard or Sony or someone who isn't even around yet is the first one to come up with a universal MMO, the *business case* for it will be "Getting people who don't want to visit (insert other MMO here) as an (insert Tolkein-derived species here) to play". Effort on interoperability is still going to be constrained by "you're not going to be able to transport scripted attachments into GUMMOS (Grand Universal MMO System) worlds". Whatever universal avatar format that evolves, it's going to have to handle custom meshes, skeletons, and animations. From secret.argent at gmail.com Tue Jun 3 19:37:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:35:47 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> References: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: On 2008-06-03, at 10:53, darien_caldwell@comcast.net wrote: > Well, I have had several people tell me Second Inventory makes > importing items from Second Life to OpenSim a breeze. I'm sure it does, for stuff you own and have full permissions for. It doesn't care if you're connecting to SL or Opensim, but it won't even download stuff from SL unless it's full perm. Now if you use Slice or Ogre to rip the textures and clone the prims some other way, hey, I'm sure SI doesn't know you did that. From secret.argent at gmail.com Tue Jun 3 19:46:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:45:16 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48456B3F.1070305@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> <48456B3F.1070305@watson.ibm.com> Message-ID: <381ADC16-98FD-4B83-A265-3723B8C1B5D5@gmail.com> On 2008-06-03, at 11:03, Mike Monkowski wrote: > But this leads to a couple more questions: Why would you want to > do the same thing in two worlds if there were a mechanism to travel > between the two worlds? Who said anything about *doing the same thing*? > And aren't building, tailoring, and dressing the fun parts? For some people, yes. For others role playing is. And even if building is the fun part, building the same thing over and over again isn't. Think ahead to when there's a dozen companies with their own Grand Universal MMO or VR systems. > which seems to imply that identity is not just an abstract concept > that manifests itself differently in different worlds, but rather > something visual, that cannot be extended with approximate > recreations. Sure, it can be extended with approximate recreations... to a point. But the capabilities some worlds provide to recreate an avatar are simply too crude. Hell, the Argent who built the lunar base in "Sociopolitical Ramifications" in 1994 is still beyond the ability of SL to implement as an avatar. Some things, text still works better for. > Even if WoW allowed ferret avatars, it wouldn't be the same ferret. Maybe, maybe not. Probably not... pretty much everyone in WoW looks the same to me. Even if WoW added ferret avatars, would it have jerboas? Or binturongs, fossas, yapoks, civets, meerkats, or cape hunting dogs? Or bearded rastas with dreadlocks down to the ground, like one of my neighbors? From secret.argent at gmail.com Tue Jun 3 19:48:39 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:47:24 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: On 2008-06-03, at 11:28, Soft wrote: > The cache isn't exceptionally slow - it's the jpeg2000 decode that > really bites here, and storing those decoded would use copious amounts > of disk space. I'm willing to use copious amounts of disk space. I've got 150GB doing nothing but SL. If it took 100 times the disk to store 1GB of cache decoded, I'd still have 50GB free. From secret.argent at gmail.com Tue Jun 3 19:51:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:50:07 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457A9B.1010704@weblogsinc.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: On 2008-06-03, at 12:08, Tateru Nino wrote: > Use a PNG or vanilla jpg compressor to save space on disk (and let > the user set the compression quality with a slider to let them > decide how much bang-for-the-buck they want out of their chosen > megabytes of storage), Um, I don't think that would be a good idea. At least not for JPG. Lossy compression, remember? PNG, maybe. From secret.argent at gmail.com Tue Jun 3 20:03:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 20:01:50 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> On 2008-06-03, at 17:59, Dale Mahalko wrote: > There are however filesystem limitations that may cause slowdowns, and > there may be diminishing returns at some point if only the local OS is > relied upon for huge caching storage. I would be interested to see > what performance gain is possible by have a dedicated slave MySQL > database running on the client PC when using a ridiculously huge cache > size.. My experience with storing big objects in databases is that filesystems kick databases butts for performance when it comes to big objects. And we're not talking about small files... even a 64x64 image is 16k, which is getting into the range where databases start getting unhappy. A 256x256 is definitely in the BLOB range. > Windows isn't good at dealing with directories containing tens of > thousands of files. Nobody is, so you store the texture for 550e8400-e29b-41d4-a716-446655440000 In $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on linux, or %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on Windows. From sldev at bitparts.org Tue Jun 3 21:20:14 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:20:25 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <484617FE.40708@bitparts.org> Dale Mahalko wrote: > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > > The problem with opening an explorer window with large numbers of files in a single folder is not reading the files themselves, but the fact that Windows will read in the /entire/ directory, then sort it by whichever method is currently defaulted. Plus, this limitation can be worked around (as someone else pointed out) by adding additional layers of folders for the first X octets of the UUID. From sldev at bitparts.org Tue Jun 3 21:22:55 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:23:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845DF1F.6060007@lindenlab.com> References: <48456D49.5020105@bitparts.org> <4845DF1F.6060007@lindenlab.com> Message-ID: <4846189F.9090409@bitparts.org> Steve Bennetts (Steve Linden) wrote: > We actually have image decoding working on a separate thread, but have > not tested it enough to ship it enabled. > > You can find the setting under Advanced > Rendering > Run Multiple > Threads. > > First thing I do when installing a new copy of SL is to enable "Run Multiple Threads". Have never noticed a problem, and see a slight - VERY slight - increase in texture rendering. I figure if it is /possible/ for it to speed things up, and doesn't adversely affect the experience, might as well turn it on. From sldev at bitparts.org Tue Jun 3 21:25:59 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:26:10 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <48461956.2020104@bitparts.org> Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping > the cache on one of those readyboost-capable usb flash drives? They > can have seek times as low as 1 ms or better, although the transfer > rate and write times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > Bad idea. Flash has limited write-cycles, you don't want to use it as a cache - you'll burn it out faster than you could believe.Besides, if seek times were the bottleneck, the RAMdisk experiment would have shown noticeable improvement. The bottleneck is definitely in the decoding. That's why I'm encouraging a test of caching raw data rather than re-compressed. From sldev at bitparts.org Tue Jun 3 21:29:53 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:30:04 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48461A41.5080208@bitparts.org> Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head > once again. > > The reason I mention this is because, although I am also a fan of > reduced compression overhead, there will no doubt be trade offs > required. Perhaps there is a way to make compression/decompression > more efficient? > We're not talking about downloading raw, uncompressed data from SL across your bandwidth - we're talking about how the client currently REcompresses (or only saves the already-compressed) textures when storing them to the local disk cache. The change I'm talking about won't affect your bandwidth, but it will require more disk space for your cache. We've established that the real bottleneck with rendering textures from cache is decoding them from the JPG2000 format - so if we could decompress them once, after they come down the wire, then cache them decompressed, we would get rid of one of the major bottlenecks to texture render speed. No more grey blobs every time you turn around. From tateru.nino at gmail.com Tue Jun 3 21:32:47 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:33:26 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48461AEF.2020307@weblogsinc.com> We've always had capped and metered bandwidth out here (most countries do). We've got to watch our SL bandwidth consumption pretty much every day, and throttle back as necessary to keep within limits. If you're on a commercial, metered connection (most of those outside North America), SL is fantastically expensive to connect to - even metered residential connections can run into an end-of-month bill of hundreds or thousands of dollars if you're not paying attention. Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head > once again. > (Presumably because of those few horrid torrent/movie downloaders > messing everything up for the rest of the planet. Yes thats right, > instead of closing off the pipes used by the abusers they choose to > make more money by harming the community in general. Typical Time > Warner choice as opposed to upgrading their antiquated copper wire > infrastructure eh? anyway i worry that heavy SL users (such as content > creators) may be about to lose any further incentive for bothering > with virtual worlds...) > > Has anyone measured actual bandwith utilization to the point people > can predict their usage per month before they get slapped with killer > bills? > > The reason I mention this is because, although I am also a fan of > reduced compression overhead, there will no doubt be trade offs > required. Perhaps there is a way to make compression/decompression > more efficient? > > > ----- Original Message ---- > From: Tateru Nino > To: Dante Tucker > Cc: Second Life Developer Mailing List > Sent: Tuesday, June 3, 2008 1:08:43 PM > Subject: Re: [sldev] Cache speed experiment & results... > > Compromise? A lighterweight compressed cache format? Admittedly, yes, > the textures would still be coming down as jpeg2000 - which means they > would have to be decoded and recompressed before they went in the cache > - which is wasteful. But it's wasteful once per texture transfer, not > once per texture fetched from the cache. > > Use a PNG or vanilla jpg compressor to save space on disk (and let the > user set the compression quality with a slider to let them decide how > much bang-for-the-buck they want out of their chosen megabytes of > storage), then you've got far less work to do decoding than the jpeg2000 > decompressor -- or so I presume. If I got all that fatally wrong, just > whack me with a rolled up man page. > > Dante Tucker wrote: > > I definatly second this as an option. Provided there is no technical > > reason this can't be done :) > > > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > > >> wrote: > > > > > > > > Given the dirt-cheap price of HD space these days, why bother > > compressing the cache, given that the decode is so expensive > > time-wise? Enlarge the cache maximum size, and toss out the > > compression - at least give us an option to try it, and see. A > > simple checkbox or debug option "UseCompressedCache" or somesuch > > defaulted to yes - then those of us with plenty of space can try > > it out. People are screaming about texture load times - I can't > > imagine they wouldn't sacrifice some disk space for a large boost > > in performance. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Tue Jun 3 21:34:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:35:25 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <48461B5F.7090303@weblogsinc.com> Also you get a limited (though large) number of write cycles to any byte before it wears out and stops responding. Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping > the cache on one of those readyboost-capable usb flash drives? They > can have seek times as low as 1 ms or better, although the transfer > rate and write times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > > On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg > wrote: > > Dale Mahalko wrote: > > ... > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > > > Reiser4 is excellent with exactly these requirements. It's not > mature enough to be considered reliable for critical systems, but > for a cache? It doesn't help that Reiser himself is removed from > the development process, but it's still there and the source > available. Shouldn't that be possible to be included as a virtual > filesystem even under Windows? > > I also always thought it must be a good way to boost performance > if the cache lived on its own partition, like a Linux swap > partition. For the Linux version of SL this would even sound like > the most natural way to do it. Setting such a thing up on an > existing Windows machine has a slight fear factor attached and is > not for everyone, but if a savvy user can handle it, why not > offer. I'm speculating, but the difference could be dramatic, > especially if we had a better file system than NTFS on that > partition. > > > > > > A proper local database engine would likely deal with these huge > > numbers of tiny files more efficiently than the local operating > > system. > > Yes, but the usual architecture with the database running as a > localhost server is not ideal for our situation since everything > is squeezed back and forth through the network system, plus SQL > parsing, unnecessarily. With MySQL you could build directly on top > of the storage engine though, even bypassing the parsing with > direct API calls. It would just serve as a virtual file system the > same way as suggested above. I still believe that Reiser4 would be > even faster. And according to the description on its (now defunct) > website, they claimed reaching 94% package density with small files. > > Felix > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Tue Jun 3 21:37:28 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:38:07 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846189F.9090409@bitparts.org> References: <48456D49.5020105@bitparts.org> <4845DF1F.6060007@lindenlab.com> <4846189F.9090409@bitparts.org> Message-ID: <48461C08.3030708@weblogsinc.com> Buckaroo Mu wrote: > Steve Bennetts (Steve Linden) wrote: >> We actually have image decoding working on a separate thread, but >> have not tested it enough to ship it enabled. >> >> You can find the setting under Advanced > Rendering > Run Multiple >> Threads. >> >> > First thing I do when installing a new copy of SL is to enable "Run > Multiple Threads". Have never noticed a problem, and see a slight - > VERY slight - increase in texture rendering. I figure if it is > /possible/ for it to speed things up, and doesn't adversely affect the > experience, might as well turn it on. > Ditto. Though I may well have seen a few of those deadlocks that were mentioned. -- Tateru Nino http://www.massively.com/ From gigstaggart at gmail.com Tue Jun 3 22:04:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 3 22:04:59 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48462277.30708@gmail.com> Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once again. > (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) I'm all for metered bandwidth. I'd love to pay for what I use, instead of subsidizing other people's usage. This whole idea of selling something as unlimited, that isn't unlimited, created this problem in the first place. In the Second Life case, I think it just comes down to being able to choose your cache behavior. Metered users can choose to cache more aggressively (and keep more compressed items cached locally) to reduce the bandwidth usage. Unmetered users might instead choose a different behavior. There are some tweakables here that I don't think are going to ever be universally right for everyone. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/15e0146c/smime-0001.bin From darien_caldwell at comcast.net Tue Jun 3 22:30:05 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Tue Jun 3 22:30:09 2008 Subject: [sldev] Cache speed experiment & results... References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> If you were to run the client at full bandwidth available (1500kb) non stop 24/7, you would use up the proposed 240 gbit a month Comcast is proposing in 48 hours. Fortunately, most people don't eat up that much. A sustained data rate of 275kbps 8 hours a day for 30 days would use up the 240 gbit limit. Key word is sustained, sitting in a sim doing nothing it's rare you get a transfer rate over 50kbps. It would be interesting to see how a normal session averages out however. This certainly will impact heavy users (like me), but to the average user, they won't see any problems. ----- Original Message ----- From: Ann Otoole To: Second Life Developer Mailing List Sent: Tuesday, June 03, 2008 3:26 PM Subject: Re: [sldev] Cache speed experiment & results... Time Warner is going to try forcing metered bandwith on the cable modem community they serve. So the ugly head of the end of unlimited bandwith use raises it's head once again. (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) Has anyone measured actual bandwith utilization to the point people can predict their usage per month before they get slapped with killer bills? The reason I mention this is because, although I am also a fan of reduced compression overhead, there will no doubt be trade offs required. Perhaps there is a way to make compression/decompression more efficient? ----- Original Message ---- From: Tateru Nino To: Dante Tucker Cc: Second Life Developer Mailing List Sent: Tuesday, June 3, 2008 1:08:43 PM Subject: Re: [sldev] Cache speed experiment & results... Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/3575a63f/attachment.htm From missannotoole at yahoo.com Tue Jun 3 22:39:58 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 3 22:40:00 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <175218.2716.qm@web59111.mail.re1.yahoo.com> Looks like SL uses about 4MB per minute if your doing anything like moving around. You'll get about 24 hours of SL time per month from Time Warner at the rate SL uses bandwith. (assuming my math is correct) I.e.; 5GB per month max and $1 per GB over. And the Comcast mode of operation will be to cancel accounts of people that use a lot of bandwith. So SL users will simply be kicked off the internet unless the "auto lag system" to slow the connections down works. But that will kill off those users from using SL anyway. Looks like SL may be coming to an end along with most use of the internet unless a political solution is hammered in to force the internet service providers to use the money they have been making to bring the US network infrastructure up to modern standards. All this metaverse effort may be totally moot now. But really.. I observed bandwidth without SL running and just using stuff like yahoo mail and pretty websites with lots of google ad sense and especially news websites uses about the same bandwidth as SL if you actively use a web browser. I think the cable companies are going to get themselves in trouble with this entire sham they are perpetuating. I seriously doubt Google and the news media is going to be real positive to the thought that use of the internet will effectively cease because using the internet will cost more than gasoline. Guess we will see. Back to the reality of SLDev. I think some serious effort will be needed to knock down bandwidth utilization in general if SL and metaverses in general are to survive the ISP greed factor. I.e.; SL and metaverses will need to run smooth over DSL since thats where all the internet business will be going. DSL and direct TV for television entertainment. The days of the internet as a streaming media medium in the USA appear to be over. Suffice to say cache performance and storage capacity may need to be escalated to showstopper level criticality. This is important enough for metaverse involved companies to get on Congress about immediately. Thats enough of this depressing topic. I look forward to seeing progress on the cache performance and http texture pipeline soon. ----- Original Message ---- From: Jason Giglio To: Ann Otoole Cc: Second Life Developer Mailing List Sent: Wednesday, June 4, 2008 1:04:55 AM Subject: Re: [sldev] Cache speed experiment & results... Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once again. > (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) I'm all for metered bandwidth. I'd love to pay for what I use, instead of subsidizing other people's usage. This whole idea of selling something as unlimited, that isn't unlimited, created this problem in the first place. In the Second Life case, I think it just comes down to being able to choose your cache behavior. Metered users can choose to cache more aggressively (and keep more compressed items cached locally) to reduce the bandwidth usage. Unmetered users might instead choose a different behavior. There are some tweakables here that I don't think are going to ever be universally right for everyone. -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/52d48864/attachment.htm From dmahalko at gmail.com Tue Jun 3 23:06:55 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 23:06:57 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: For OS-filesystem caches permitting hundreds of thousands to millions of cached files, perhaps a follow-behind cache optimizer process would work better and provide more organizational efficiency. To start a new cache, just make 256 subdirectories: Cache\00\* to Cache\ff\* The client walks this tree when adding files to the cache and makes a note of any directory which has exceeded some maximum performance limit, say 10,000 GUIDs in a directory. When the user is Away, the cache optimizer process goes to each of these flagged subdirectories, and will split that directory into 256 subdirectories: - Cache\4c\* was found to contain over 10,000 GUIDs, so make it Cache\4c\00\* to Cache \4c\ff\* and move the files into their respective subdirectories. - At some later time, perhaps months later, Cache\4c\e3\* was found to contain over 10,000 GUIDs so make it Cache\4c\e3\00\* to Cache\4c\e3\ff\* and move the files into their respective subdirectories Once a directory level has been forked, the client walks as deep as necessary whenever adding new GUIDs to the cache. This would keep the number of subdirectories small and fast when there are few files, but allows the cache to branch out into as many smaller branches as necessary, to keep file counts per directory low and allow fast file searching by limiting each subbranch to 256 subdirectories. Since GUID assignments are apparently random, it would be a waste of time to create deep subbranches before they are needed since many branches would likely remain empty, and empty branches must be iterated through when looking for a file. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 10:03 PM, Argent Stonecutter wrote: > Nobody is, so you store the texture for > > 550e8400-e29b-41d4-a716-446655440000 > > In > > $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on > linux, or > %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on > Windows. From seg at haxxed.com Tue Jun 3 23:41:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 3 23:41:31 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> On Sun, Jun 1, 2008 at 2:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. I think it would be more productive to create a plugin API, develop some plugins, THEN argue about licensing once we actually have something to argue about. Right now its just utterly unproductive hypothetical handwaving. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/3bc819a0/attachment-0001.htm From Anders at Arnholm.se Tue Jun 3 23:58:57 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Jun 3 23:59:43 2008 Subject: [sldev] GPL violation? In-Reply-To: <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> Message-ID: <20080604065857.GC19105@arnholm.se> On Sun, Jun 01, 2008 at 10:29:33AM -0500, Matthew Underwood wrote: > On Sun, Jun 1, 2008 at 9:31 AM, Tony wrote: > Under the GPL any derivative works have to release the source (they > can charge up to the cost of the binary form tho). So if you release > a 3k viewer, then you could theoretically charge 3k for the source > too, but you still have to have the source available. Read the But not extra un the 3K you took for the binary release, also you can?t limit your customers form selling and changing the product. I work in the borderline berween open source (mainly GPL) and properitary additions. / Balp -- o_ Anders Arnholm, o/ /\ anders@arnholm.se /|_, \\ http://anders.arnholm.se/ / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/8020d68a/attachment.pgp From seg at haxxed.com Wed Jun 4 00:07:33 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 4 00:07:35 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <175218.2716.qm@web59111.mail.re1.yahoo.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> Message-ID: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> On Wed, Jun 4, 2008 at 12:39 AM, Ann Otoole wrote: > All this metaverse effort may be totally moot now. > Imminent death of the net predicted. How much bandwidth does WoW take, or Xbox Live? ISPs may not give a crap about SL, but pissing off users of cash cows like WoW and Xbox Live would be an epic PR blunder on their part. Online content delivery is the future. And by future, I mean now. Any ISPs standing in the way are going to find themselves losing customers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/6f25f6dd/attachment.htm From kfa at gmx.net Wed Jun 4 00:13:42 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 00:13:48 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <48453828.50503@gmx.net> Message-ID: <484640A6.3040603@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 07:25, Felix Duesenburg wrote: >> My guess is that this will be a task of the magnitude of creating a >> standard for videotape or disk formats. > > > You think it's that simple? that's encouraging! :) > > LOL :) No - not as simple, as the technology we're talking about is x times more involved - I said 'magnitude' and meant to draw the comparison with the almost war-like scenario we had until there finally was only one left. From dmahalko at gmail.com Wed Jun 4 00:31:22 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 00:31:25 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> Message-ID: I don't play much D&D, but I know exactly what sort of thing you are referring to. A good example is called Neverwinter Nights. It has its own built-in story plus a construction environment where you can build your own D&D environment with your own story and your own rules, using two-dimensional tiles containing 2.5D objects. There are hundreds of private Neverwinter Nights servers where you can login and enter a custom virtual world created by a small group of D&D fanatics, each with their own story but built on the common virtual-world platform, just like how the old text-based MUDs worked. I thought the construction concepts of Neverwinter Nights were interesting.... and yet so limited. Builds are always limited to the 2.5D tiling system and as a builder you are essentially stuck with whatever predefined 2.5D tile sets exist, and with limited event-scripting and environment-customization ability. What SL and/or MPEG-V needs to offer to D&D MMO GMs and players is something like Neverwinter Nights, but taken to a full-3D experience with fully customizable virtual environment not limited to a tiling system. It needs to be able to include the storytelling and environmental possibilities of Everquest, WoW, Eve, and all other MMO's combined, to allow whatever virtual scenario a crazed D&D GM wants to dream up. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 9:34 PM, Argent Stonecutter wrote: > As virtual role playing environments evolve, people playing in the > equivalent of Gamma World and Champions and D&D and Runequest and Car Wars > are going to eventually want to get together, as their avatars. You're going > to have the online equivalents of Munden's Bar, where all the metaverses > come together. From dmahalko at gmail.com Wed Jun 4 00:42:04 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 00:42:05 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> Message-ID: For WoW, bandwidth usage depends on your play style. WoW is completely playable as a single player on 30 kbit dialup, though voice cannot be used. I know because this is what was stuck with using, for two years. Also up to 5-man groups are playable, with a good 40-50 kbit connection, though there can be lag in busy fights, and still no voice is allowed. Larger groups are generally not possible on dialup, and entering a massively crowded city area (like IronForge, before there were multiple auction locations) would lag out and knock a dialup player offline. But even for raids the bandwidth doesn't go much over 256 kbit, so WoW is fairly lightweight. But just remember that it has around 9 gigabytes of data precached on every player's computer and that is only changed via infrequently-applied large unified patches.. - Scalar Tardis / Dale Mahalko On Wed, Jun 4, 2008 at 2:07 AM, Callum Lerwick wrote: > How much bandwidth does WoW take From kfa at gmx.net Wed Jun 4 00:46:36 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 00:46:42 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <4846485C.90107@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 17:59, Dale Mahalko wrote: >> There are however filesystem limitations that may cause slowdowns, and >> there may be diminishing returns at some point if only the local OS is >> relied upon for huge caching storage. I would be interested to see >> what performance gain is possible by have a dedicated slave MySQL >> database running on the client PC when using a ridiculously huge cache >> size.. > > My experience with storing big objects in databases is that filesystems > kick databases butts for performance when it comes to big objects. And > we're not talking about small files... even a 64x64 image is 16k, which > is getting into the range where databases start getting unhappy. A > 256x256 is definitely in the BLOB range. > >> Windows isn't good at dealing with directories containing tens of >> thousands of files. > > Nobody is, so you store the texture for > > 550e8400-e29b-41d4-a716-446655440000 > > In > > $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on > linux, or > %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on > Windows. > I don't know where I read that... someone tell me if it's just a rumour. Can it be true that for reasons related to the historical evolution of Windows, it's still a wee bit faster if filenames sticked to the old 8.3 convention? If that is so, just break the filename up into parts with no more than 8 characters. What we have here is simply the hex-ascii representation of a 128 bit number, requiring 32 characters to encode. The dashes are superfluous and can be omitted. Thus, %CACHEDIR%\textures\550e8400\e29b41d4\a7164466\55440000.tga Dismiss if this is rubbish. From gbrandon at gmail.com Wed Jun 4 00:59:40 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 00:59:43 2008 Subject: [sldev] RevokePermissions Message-ID: Hey all, just wanted to ask if there's been any discussion as to why the RevokePermissions message hasn't been implemented in the official viewer. It seems to be in working order all this time from what I can tell. But the official viewer even goes so far as to warn that you "can't revoke this" in the PERMISSION_DEBIT dialog. Is there some issue with it that noone is aware of? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/09f4a395/attachment.htm From tateru.nino at gmail.com Wed Jun 4 01:54:33 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 4 01:55:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <175218.2716.qm@web59111.mail.re1.yahoo.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> Message-ID: <48465849.4090507@weblogsinc.com> We get 20GB/month, right now - which is really the best we can get for the foreseeable future. We're just a couple days into the month and having to throttle usage back to make sure we'll get to the end of it. Ann Otoole wrote: > Looks like SL uses about 4MB per minute if your doing anything like > moving around. > > You'll get about 24 hours of SL time per month from Time Warner at the > rate SL uses bandwith. (assuming my math is correct) > I.e.; 5GB per month max and $1 per GB over. > > And the Comcast mode of operation will be to cancel accounts of people > that use a lot of bandwith. So SL users will simply be kicked off the > internet unless the "auto lag system" to slow the connections down > works. But that will kill off those users from using SL anyway. > > Looks like SL may be coming to an end along with most use of the > internet unless a political solution is hammered in to force the > internet service providers to use the money they have been making to > bring the US network infrastructure up to modern standards. > > All this metaverse effort may be totally moot now. > > But really.. I observed bandwidth without SL running and just using > stuff like yahoo mail and pretty websites with lots of google ad sense > and especially news websites uses about the same bandwidth as SL if > you actively use a web browser. I think the cable companies are going > to get themselves in trouble with this entire sham they are > perpetuating. I seriously doubt Google and the news media is going to > be real positive to the thought that use of the internet will > effectively cease because using the internet will cost more than gasoline. > > Guess we will see. Back to the reality of SLDev. > > I think some serious effort will be needed to knock down bandwidth > utilization in general if SL and metaverses in general are to survive > the ISP greed factor. > I.e.; SL and metaverses will need to run smooth over DSL since thats > where all the internet business will be going. DSL and direct TV for > television entertainment. The days of the internet as a streaming > media medium in the USA appear to be over. > > Suffice to say cache performance and storage capacity may need to be > escalated to showstopper level criticality. > > This is important enough for metaverse involved companies to get on > Congress about immediately. > > Thats enough of this depressing topic. I look forward to seeing > progress on the cache performance and http texture pipeline soon. > > > ----- Original Message ---- > From: Jason Giglio > To: Ann Otoole > Cc: Second Life Developer Mailing List > Sent: Wednesday, June 4, 2008 1:04:55 AM > Subject: Re: [sldev] Cache speed experiment & results... > > Ann Otoole wrote: > > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > > So the ugly head of the end of unlimited bandwith use raises it's > head once again. > > (Presumably because of those few horrid torrent/movie downloaders > messing everything up for the rest of the planet. Yes thats right, > instead of closing off the pipes used by the abusers they choose to > make more money by harming the community in general. Typical Time > Warner choice as opposed to upgrading their antiquated copper wire > infrastructure eh? anyway i worry that heavy SL users (such as content > creators) may be about to lose any further incentive for bothering > with virtual worlds...) > > I'm all for metered bandwidth. I'd love to pay for what I use, instead > of subsidizing other people's usage. This whole idea of selling > something as unlimited, that isn't unlimited, created this problem in > the first place. > > In the Second Life case, I think it just comes down to being able to > choose your cache behavior. Metered users can choose to cache more > aggressively (and keep more compressed items cached locally) to reduce > the bandwidth usage. > > Unmetered users might instead choose a different behavior. There are > some tweakables here that I don't think are going to ever be universally > right for everyone. > > -Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jun 4 01:57:59 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 4 01:58:39 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> Message-ID: <48465917.1010005@weblogsinc.com> Callum Lerwick wrote: > On Wed, Jun 4, 2008 at 12:39 AM, Ann Otoole > wrote: > > All this metaverse effort may be totally moot now. > > > Imminent death of the net predicted. > > How much bandwidth does WoW take, or Xbox Live? ISPs may not give a > crap about SL, but pissing off users of cash cows like WoW and Xbox > Live would be an epic PR blunder on their part. > > Online content delivery is the future. And by future, I mean now. Any > ISPs standing in the way are going to find themselves losing customers. > Well, most MMOs use a fraction of the bandwidth. You can play most of them on dialup. Since the content pre-exists at the client-side, there's very little data to exchange. Even less, when you take into account that a lot of processing can be done in the client itself. -- Tateru Nino http://www.massively.com/ From belxjander at gmail.com Wed Jun 4 04:20:55 2008 From: belxjander at gmail.com (Belxjander Serechai) Date: Wed Jun 4 04:20:58 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> Message-ID: <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> What is actually being transported and what are the spaces being transported between? if OSgrid.org is my room and the LL SL grid is the next room...then there is an obvious compatability, same root tech, however transfer of AV concept would remain local to the owner while others may see entirely different AV forms in MMORPG systems, as for content (Asset) provision, I see Web style Server Farms happening... each Farm having own key... something like a "keyring" function for access seems appropriate, as content providers would host for a creator, and each item would need a user/creator/provider keychain, as for Inventory, a similar model can be introduced... as far as AVs are concerned... this is a "root" object of transfer, whats needed to support the AV?, What "objects" is the AV going to have "come with it" ala "Airport baggage""... I forsee something similar to an "Airport" for Inter-realm transfers... similar to International customs, each "realm" OSgrid/LLSL/WoW/... needs to define what it will and will not "import" as baggage permissions, and then the technology has to provide for inter-connection, ... every "site" is going to need "grid" and "user" support with allocation for "anonymous" users being part of the "passport" keychain, as you are talking about Identity, you need to have a representation of Identity in each "realm" or VW, and then an interconnection agreement as well, The standards as I see it need to focus on making the interconnection and access of assets being "user/server/provider" keyed so that any individuals Items are permissible, I use 'Freija Yoshikawa' on both the Linden and OSgrid realms, I would want for the login on each to represent the same AV, the material on OSgrid started there, and the material on the Linden grid started on the LLSL grid, I would have a "Suitcase" where I would "pack" what I wish to keep with me, and then travel between the two,... when I am in the OSgrid using the LLSL AV, I would expect *my* view on my local machine to remain the same, however, I personally do not expect what other people to see to be the same (maybe I am given a "basic visitor" AV to start?) Once I am on the OSgrid realm, what is stopping me from purchasing or making content there, and this is where the travel interconnect agreement comes into play, are "Materia"(Assets/Inventory) I make on the OSgrid using the LLSL AV presence with OSgrid Passport(UserLogin) going to be hosted where? the answer to that seems obvious to me... I am on the OSgrid, therefore hosting for Inventory remains on OSgrid, the only issue I see is how to make any interconnect between realms allow for "luggage" like a suitcase... or some kind of "permissible" hosting, What is to stop a User Client from "keeping" access to Assets and Inventory when crossing between grid/realms? example 2: I travel back from OSgrid to LLSL using Freija Yoshikawa, my "Primary" Inventory is now LLSL again with full access restored, and the OSgrid Inventory is now "Secondary"... in this case I may have full login and access to both LL and OSgrid services... a modular client with Inventory access to both systems as Full credentialled login... transfer of inventory would become easy... but the key to the above examples is actually "walled garden" model with an interconnect... every "web site" I visit I consider to be a walled garden, disney/microsoft/borland/... whomever... they want to "keep" custom with you each realm without interconnect loses customers... where are they coming from? Customers are visiting through Interconnects... a Web Browser is interconnect to ALL web services through a common HTTP/HTML standard, I see a base requirement of Assets and Inventory needing the same kind of paired protocol/format evolution, Ive already worked up a basic idea that would work and still provide for some legal concerns to be dealt with... but would require that any SecondLife grid style system with content creation is not just *any interconnect will do*... LL is first provider for the SecondLife grid and protocol, now we need for a non-LL business to be providing a grid as well, along with an interconnection agreement and mechanism in place. just because there is a legal divide between LL and OS about code (GPL/BSD license)... does not mean there needs to also be a non-communication divide as well, the only division there is legal and related to the code (GPL doing pacman to BSD) Yes the above can be a "walled garden" but I see the above as "provider" gardens and interconnects between garden "realms" how many business will use the same provider ? and who will access each providers system for a given service ? The above model does have the LL"main" and LL"teen" grid approach in seperating Adult material from minors... they WILL find out eventually,... just dont let the technology override the parents choices... There is also another social impact... provision of the grid AND the business ON that grid are not the same company ... LL does the grid, IBM/Microsoft/etc... market on their grid... there is nothing stopping alternative providers of grid services... but there does need to be an honourable means of marketing to the end users to let them decide where to go... Do you go to Tahiti or the Bahamas or Japan for a Holiday ? or are you going for other reasons? How about Europe? ALL of the above is available seperately and is a rehash of a conversation I had on the EFnet/#OpenSIM IRC channel, the first thing about a "3D" system like SL is that there is still the 2D mapping limitation... each "realm" may be "flat" but whats to stop an alternate region mapping things in 3D as well? Im personally hacking at a modified OpenSIM to run a cube of grid regions... going *any direction* beyond a region boundary in X Y or Z axis *will* step you to another region... whats to stop a given "region" within a grid having the special "interconnect" property? and promoting anyone who enters that region as being TP'd to a "staging island" region... call it Teleport/Stargate/DimensionJump/... Whatever... the name doesnt matter so much as getting from A(origin realm) to B(target realm) Any Client no matter HOW feature rich is still a "browser" for each of the virtual worlds... is the "world" it is accessing "complete" or only "part"? LLSL and OSgrid are now fragments of that "world"... with the result split... therefore to appease everyone.. allow for a non-single provider... *make* the market by providing for it... either content within the realms or the realms themselves, ( I am looking to make realm service and content seperate ) Contact Names ?IM & Email?Abh??????? ?IRC & Chat?Belxjander Serechai ?LLSL/OSgrid?Freija Yoshikawa ?Real?Life??Jeremy Sutherland I also play on Guild Wars / Exteel and Fury systems occasionally, ... On Wed, Jun 4, 2008 at 4:31 PM, Dale Mahalko wrote: > I don't play much D&D, but I know exactly what sort of thing you are > referring to. A good example is called Neverwinter Nights. It has its > own built-in story plus a construction environment where you can build > your own D&D environment with your own story and your own rules, using > two-dimensional tiles containing 2.5D objects. There are hundreds of > private Neverwinter Nights servers where you can login and enter a > custom virtual world created by a small group of D&D fanatics, each > with their own story but built on the common virtual-world platform, > just like how the old text-based MUDs worked. > > I thought the construction concepts of Neverwinter Nights were > interesting.... and yet so limited. Builds are always limited to the > 2.5D tiling system and as a builder you are essentially stuck with > whatever predefined 2.5D tile sets exist, and with limited > event-scripting and environment-customization ability. > > What SL and/or MPEG-V needs to offer to D&D MMO GMs and players is > something like Neverwinter Nights, but taken to a full-3D experience > with fully customizable virtual environment not limited to a tiling > system. It needs to be able to include the storytelling and > environmental possibilities of Everquest, WoW, Eve, and all other > MMO's combined, to allow whatever virtual scenario a crazed D&D GM > wants to dream up. > > - Scalar Tardis / Dale Mahalko > > On Tue, Jun 3, 2008 at 9:34 PM, Argent Stonecutter > wrote: >> As virtual role playing environments evolve, people playing in the >> equivalent of Gamma World and Champions and D&D and Runequest and Car Wars >> are going to eventually want to get together, as their avatars. You're going >> to have the online equivalents of Munden's Bar, where all the metaverses >> come together. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Wed Jun 4 06:02:21 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:01:12 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48462277.30708@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> Message-ID: On 2008-06-04, at 00:04, Jason Giglio wrote: > I'm all for metered bandwidth. I don't think "metered bandwidth" is a good term. Bandwidth is "how much you can transmit per unit of time", and is metered in units of bits-per-second. My bandwidth is capped to 256 kilobits per second, for example. This is good enough to play SL, but not enough to stream HD movies (or stream anything while I'm playing SL). What we're talking about here needs a different term. It's not a bandwidth cap, it's a total traffic cap. I prefer real bandwidth caps to traffic caps because I don't care if the guy next door who's running a 5 megabyte per second download is going to get capped off sooner, while he's doing it I'm still suffering. Either way I'd much rather be able to use my whole disk for cache, with no limits other than disk space, to the current scheme. From secret.argent at gmail.com Wed Jun 4 06:13:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:12:00 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On 2008-06-04, at 01:06, Dale Mahalko wrote: > Since GUID assignments are apparently random, it would be a waste of > time to create deep subbranches before they are needed since many > branches would likely remain empty, and empty branches must be > iterated through when looking for a file. I didn't pull this scheme out of thin air. I actively use it. There's no searching or iterating by the client needed. No empty directories are created. When you create an object in the cache, you do something like this: sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, uuid+6, uuid); if(!(fp = fopen(filename, "w"))) { filename[2] = 0; success = mkdir(filename); filename[2] = '/'; if(success != ERR) { filename[4] = 0; success = mkdir(filename); filename[4] = '/'; } if(success != ERR) { filename[6] = 0; success = mkdir(filename); filename[6] = '/'; } if(success != ERR) { filename[8] = 0; success = mkdir(filename); filename[8] = '/'; } if(success != ERR) { fp = fopen(filename, "w"); } if(!fp) { fatal(filename, strerror(errno)); } } This means that when opening a cached file you have a single system call: sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, uuid+6, uuid); if(!(fp = fopen(filename, "r"))) { fatal(filename, strerror(errno)); } This avoids populating the tree unnecessarily, while making the common operation (reading from cache) MUCH faster than if the file name varies depending on depth. From secret.argent at gmail.com Wed Jun 4 06:17:56 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:16:39 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> References: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> Message-ID: On 2008-06-04, at 01:41, Callum Lerwick wrote: > I think it would be more productive to create a plugin API, develop > some plugins, THEN argue about licensing once we actually have > something to argue about. Right now its just utterly unproductive > hypothetical handwaving. There's been a couple of plugin APIs designed, and prototypes for what could be possible plugins created, and distributed as custom builds of SL. Things kind of stalled, though, partly because of a lack of feedback from LL. From secret.argent at gmail.com Wed Jun 4 06:29:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:28:36 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846485C.90107@gmx.net> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846485C.90107@gmx.net> Message-ID: <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> On 2008-06-04, at 02:46, Felix Duesenburg wrote: > I don't know where I read that... someone tell me if it's just a > rumour. Can it be true that for reasons related to the historical > evolution of Windows, it's still a wee bit faster if filenames > sticked to the old 8.3 convention? Not in NTFS. If you're using FAT32, it's possible. that would make it maybe... %CACHEDIR%\textures\55\0e\84\00e2\9b41d4\a7164466\55440000 You still want the early levels to be limited to a maximum of 256 entries, otherwise you end up with the problem of tens of thousands of entries in a directory again. From secret.argent at gmail.com Wed Jun 4 06:37:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:35:51 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> Message-ID: <4EDB3E4B-99CF-4C2D-A67F-9D70A29F0730@gmail.com> On 2008-06-04, at 06:20, Belxjander Serechai wrote: > as far as AVs are concerned... this is a "root" object of transfer, > whats needed to support the AV?, For arbitrary avatars: a skeleton, a set of meshes, textures, and animations. For an avatar holding an object that could be represented by attached objects and an object mesh, or a more complex skeleton and mesh. These may not exactly match the internal formats of any of the worlds involved, and would have to be approximated for each. From sakkaku at gmail.com Wed Jun 4 07:22:43 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed Jun 4 07:23:01 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846485C.90107@gmx.net> <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> Message-ID: <79e704e0806040722r714421bbra8021abe1864bf67@mail.gmail.com> If a compatibility flag is set then NTFS generates an 8.3 name based on the filename. You can often see the effects of this with the old(er) office that had to have a shorter name in order to open the file, it would create a temporary file (or link?) and open that. On Wed, Jun 4, 2008 at 8:29 AM, Argent Stonecutter wrote: > On 2008-06-04, at 02:46, Felix Duesenburg wrote: >> >> I don't know where I read that... someone tell me if it's just a rumour. >> Can it be true that for reasons related to the historical evolution of >> Windows, it's still a wee bit faster if filenames sticked to the old 8.3 >> convention? > > Not in NTFS. If you're using FAT32, it's possible. that would make it > maybe... > > %CACHEDIR%\textures\55\0e\84\00e2\9b41d4\a7164466\55440000 > > You still want the early levels to be limited to a maximum of 256 entries, > otherwise you end up with the problem of tens of thousands of entries in a > directory again. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dmahalko at gmail.com Wed Jun 4 09:37:09 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 09:37:12 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: My only concern is that the GUID distribution is may be just merely pseudo-random. When this system was dreamed up at the start of SL, did anyone actually do studies of the randomness of the distributions? I do not know if LL is using a randomness algorithm rigorously tested by professional mathematicians and statisticians, or if it just something Cory Ondrejka threw together one day and called good. It is possible that the GUID distribution is not as truly random as we may think, and many GUIDs end up falling into certain branches, sort of like how a 3D array of dots may appear random from one angle but end up all aligning into an even grid when rotated properly. As far as I know, no one has yet tried caching absolutely everything LL throws at them and just never deleting anything, and running statistics on that, so no one outside LL knows where the GUIDs tend to fall at this point. Your suggested method is four levels deep, and offers up to four billion subdirectories for GUIDs to fall into, which seems granular enough... but what if for some reason they all end up piling up into just a few of these branches? Then you'll end up with 50,000+ GUIDs sitting in Cache\00\41\31\d1\* and no way to split that any deeper. For an "ultimate, never-delete" local cache spanning terabytes of local storage, I am in favor of allowing for splitting all the way to the "bottom" if necessary, up to 19 directories deep, to deal with possible pseudo-random distribution problems. At this ridiculously deep splitting, there can only ever be 256 GUIDs per directory, at the bottom-most level. %CACHEDIR%\textures\55\0e\84\00\55\0e\84\00\e2\9b\41\d4\a7\16\44\66\55\44\00\00 While some people will debate the value of this vs just requesting the data from LL directly, I am also still looking for caching options for people with extremely limited bandwidth. This could be laying the foundation for the design of a local network proxy/cache server. I am aware that public schools must share a minuscule network pipe with hundreds of students, and the only way to effectively deal with SL in a school environment is to have some sort of local building-wide asset-cache server. With regard to the ISP bandwidth limiting problem also being discussed, imagine if an ISP could buy a "Second Life Asset Appliance" similar to the current Google Search Appliance. They could effectively cut user traffic to LL in half or less by caching all assets locally and transparently proxying SL asset requests, and meanwhile be able to offer a greater quality of service to all other users of their network.. - Scalar Tardis / Dale Mahalko On Wed, Jun 4, 2008 at 8:13 AM, Argent Stonecutter wrote: > I didn't pull this scheme out of thin air. I actively use it. > > There's no searching or iterating by the client needed. No empty directories > are created. When you create an object in the cache, you do something like > this: > > sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, > uuid+6, uuid); > if(!(fp = fopen(filename, "w"))) { > filename[2] = 0; success = mkdir(filename); filename[2] = '/'; > if(success != ERR) { filename[4] = 0; success = mkdir(filename); > filename[4] = '/'; } > if(success != ERR) { filename[6] = 0; success = mkdir(filename); > filename[6] = '/'; } > if(success != ERR) { filename[8] = 0; success = mkdir(filename); > filename[8] = '/'; } > if(success != ERR) { fp = fopen(filename, "w"); } > if(!fp) { fatal(filename, strerror(errno)); } > } From Celierra at gmail.com Wed Jun 4 09:54:53 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Jun 4 09:54:56 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko wrote: > My only concern is that the GUID distribution is may be just merely > pseudo-random. ... Why not hash the (entire) GUID and use that instead? ~Cel From q at lindenlab.com Wed Jun 4 10:17:41 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Jun 4 10:18:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko > wrote: >> My only concern is that the GUID distribution is may be just merely >> pseudo-random. ... > > Why not hash the (entire) GUID and use that instead? The point of a GUID is that it's already random. Or more correctly, "merely" pseudo-random. Not that most computers have a handy source of true randomness anyway. Our GUID generation code is found in lluuid.h/.cpp. There are comments in there that indicate that we've thought about distribution and the quality of our randomness before. Which makes sense, given that we have to store *all* of those assets ourselves. If they had a tendency to sort themselves into buckets, we'd have a lot more trouble managing them than any external caching scheme will. I don't think this is something to bother with. Q From monkowsk at watson.ibm.com Wed Jun 4 10:21:43 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jun 4 10:23:13 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48458B1D.8030502@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> <48458B1D.8030502@lindenlab.com> Message-ID: <4846CF27.90007@watson.ibm.com> Kelly Linden wrote: > Sorry, Perhaps my response was pigeonholed? :) Didn't mean to. :-) > "Effort on interoperability should be focused on the products (potential > and existing) that would actually want it. " And I would say "Effort on interoperability should be focused on the customers (potential and existing) that would actually want it." The focus is different. > The actual example being discussed was WoW, the specific reason given > was a user who didn't want to play WoW because they wanted a fully > customizable avatar in WoW because they didn't like elves and similar. > WoW is not going to want to upset their millions of paying subscribers > by allowing arbitrary content in world - it just isn't the product that > WoW is. And people who don't like elves aren't the customers for WoW. > Almost all other MMORPGs in existance today fall into that category. I > think this will be true of many games for a good long time. I don't disagree, except perhaps in the meaning of "long time." > Now that I've written this I realize what is being discussed isn't > really 'interoperability' but a small subset of it: content exchange. > What I have said primarily focuses on this aspect of interoperability, > and this isn't probably even the biggest part, nor the most important. My feelings are the same as yours, but, as my wife often points out, most people do not think the way I do. :-) I'm trying to understand why content exchange is at all important to anyone. > There are definitely places where interoperability is not only possible > but highly desired. My point is just to focus efforts there. Even > products that may not want full interoperability (such as content > exchange) may be interested in other forms of interoperability such as > communication or authentication or a standard viewer (which is I think > what started this thread). It might be beneficial even to WoW to be > able to get customers without them needing to install new software on > their machine. In fact that future probably puts dollar signs in many > an Exec's eyes. Those dollar signs often distort one's vision. :-) > Little Big Planet is interesting because it does have facilities for > content creation ..... however from what I have seen that content > creation is still somewhat limited. The characters have a specific > look, the content has a specific look. Perhaps it isn't as vital to the > product as WoW and similar content-creation-less products, and perhaps > LBP is a potential customer for content exchange interoperability. > After thinking about this I think it is very important to be clear about > what form interoperability is being discussed and to allow and encourage > varying degrees of interoperability. I brought up Little Big Planet because it doesn't fit either of the categories: MMO game or virtual world. I imagine that more MMO games might begin to include content creation. But back to the main topic. You say that "LBP is a potential customer for content exchange interoperability." Why? Just because it has content? Or does the content exchange provide synergy? Mike From cenji.neutra at gmail.com Wed Jun 4 10:37:04 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Wed Jun 4 10:37:07 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: > From: "Dale Mahalko" > To: "Argent Stonecutter" > Date: Wed, 4 Jun 2008 11:37:09 -0500 > Subject: Re: [sldev] Cache speed experiment & results... [...] > It is possible that the GUID distribution is not as truly random as we > may think, [...] I've not looked at the source, but if LL implemented the standard for UUIDs (aka GUIDs) then they shouldn't be completely random at all. UUIDs aren't made up of all random parts - they have components that have to be generated in specific ways, only some of which are intended to be random. The original (V1) UUIDs actually contain the network card Mac address of the computer that generated it (!) Look at SL keys - they are all of the form xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx for a start - and there are other internal consistencies I believe. It may be that LL didn't follow the standard at all and just made up their own system of course. -Cenji. From kelly at lindenlab.com Wed Jun 4 10:42:14 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jun 4 10:42:21 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4846CF27.90007@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> <48458B1D.8030502@lindenlab.com> <4846CF27.90007@watson.ibm.com> Message-ID: <4846D3F6.6070007@lindenlab.com> Mike Monkowski wrote: > I brought up Little Big Planet because it doesn't fit either of the > categories: MMO game or virtual world. I imagine that more MMO games > might begin to include content creation. > > But back to the main topic. You say that "LBP is a potential customer > for content exchange interoperability." Why? Just because it has > content? Or does the content exchange provide synergy? > > Mike At that point, yeah, I just meant that it has user-generated-content and so could potentially be a customer for content exchange - at least more so than products that do not have user-generated-content. - Kelly From sakkaku at gmail.com Wed Jun 4 10:44:17 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed Jun 4 10:44:20 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: Message-ID: <79e704e0806041044q14b8bc6coba63993c430e482b@mail.gmail.com> http://en.wikipedia.org/wiki/UUID There are several standards, some relying solely on a random number. Given the range of these numbers (128bit), I don't think they would collide easily (shoot they probably will eventually collide). On Wed, Jun 4, 2008 at 12:37 PM, Cenji Neutra wrote: >> From: "Dale Mahalko" >> To: "Argent Stonecutter" >> Date: Wed, 4 Jun 2008 11:37:09 -0500 >> Subject: Re: [sldev] Cache speed experiment & results... > [...] >> It is possible that the GUID distribution is not as truly random as we >> may think, > [...] > > I've not looked at the source, but if LL implemented the standard for > UUIDs (aka GUIDs) then they shouldn't be completely random at all. > UUIDs aren't made up of all random parts - they have components that > have to be generated in specific ways, only some of which are intended > to be random. The original (V1) UUIDs actually contain the network > card Mac address of the computer that generated it (!) > > Look at SL keys - they are all of the form > xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx for a start - and there are other > internal consistencies I believe. > > It may be that LL didn't follow the standard at all and just made up > their own system of course. > -Cenji. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From alex at lindenlab.com Wed Jun 4 11:44:06 2008 From: alex at lindenlab.com (Alex Dailey) Date: Wed Jun 4 11:44:09 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org><4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com><48457A9B.1010704@weblogs inc.com><4845A31D.10002@bitparts.org><897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <4846E276.8050809@lindenlab.com> A humorous side note to this. The distribution of uuid's is so random and there is so much 'space' between values, that Cory et al. joked about putting phony assets in the early range, ...0000000, 0000001 that rezz'ed signs saying things like, "Give up now!" and "Abandon your quest or despair!" for people who tried to guess asset_id's starting from the beginning of the uuid range. Kent Quirk (Q Linden) wrote: > > On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > >> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko >> wrote: >>> My only concern is that the GUID distribution is may be just merely >>> pseudo-random. ... >> >> Why not hash the (entire) GUID and use that instead? > > The point of a GUID is that it's already random. Or more correctly, > "merely" pseudo-random. Not that most computers have a handy source of > true randomness anyway. > > Our GUID generation code is found in lluuid.h/.cpp. There are comments > in there that indicate that we've thought about distribution and the > quality of our randomness before. > > Which makes sense, given that we have to store *all* of those assets > ourselves. If they had a tendency to sort themselves into buckets, > we'd have a lot more trouble managing them than any external caching > scheme will. I don't think this is something to bother with. > > Q > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at lindenlab.com Wed Jun 4 11:54:29 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 11:54:31 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846E276.8050809@lindenlab.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846E276.8050809@lindenlab.com> Message-ID: That said, there *are* stripes of consecutive IDs out there. :) Check out a few elder Linden LLUUIDs. On Wed, Jun 4, 2008 at 1:44 PM, Alex Dailey wrote: > A humorous side note to this. The distribution of uuid's is so random and > there is so much 'space' between values, that Cory et al. joked about > putting phony assets in the early range, ...0000000, 0000001 that rezz'ed > signs saying things like, "Give up now!" and "Abandon your quest or > despair!" for people who tried to guess asset_id's starting from the > beginning of the uuid range. > > Kent Quirk (Q Linden) wrote: >> >> On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: >> >>> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko wrote: >>>> >>>> My only concern is that the GUID distribution is may be just merely >>>> pseudo-random. ... >>> >>> Why not hash the (entire) GUID and use that instead? >> >> The point of a GUID is that it's already random. Or more correctly, >> "merely" pseudo-random. Not that most computers have a handy source of true >> randomness anyway. >> >> Our GUID generation code is found in lluuid.h/.cpp. There are comments in >> there that indicate that we've thought about distribution and the quality of >> our randomness before. >> >> Which makes sense, given that we have to store *all* of those assets >> ourselves. If they had a tendency to sort themselves into buckets, we'd have >> a lot more trouble managing them than any external caching scheme will. I >> don't think this is something to bother with. >> >> Q >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Wed Jun 4 12:02:43 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 4 12:02:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> On 6/4/08, Dale Mahalko wrote: > My only concern is that the GUID distribution is may be just merely > pseudo-random. When this system was dreamed up at the start of SL, > did anyone actually do studies of the randomness of the distributions? I believe the SL UUIDs are actually generated randomly, often on the user's computer(!), with a variety of seeds. But if that turns out to be an issue... don't forget that this is just a cache, there's no issue with *changing it* to take other bits from the UUID for the first couple of levels. You could even use a simple CRC or other cheap polynomial on the UUID to generate a 16-bit value for the first two levels. If the UUID is still used for the rest of the file name, you don't even need to version the cache, all that will happen is you'll get cache misses when the algorithm changes and the old files will eventually age out of the cache. From mrfrans at gmail.com Wed Jun 4 12:12:45 2008 From: mrfrans at gmail.com (Frans) Date: Wed Jun 4 12:12:50 2008 Subject: [sldev] RevokePermissions In-Reply-To: References: Message-ID: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> I suspect that there isn't a list kept on the servers to what you have given permission_debit. So it would only be usefull for things you do know of, which in most cases you can revoke by reseting the script anyway. On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby wrote: > Hey all, just wanted to ask if there's been any discussion as to why the > RevokePermissions message hasn't been implemented in the official viewer. > It seems to be in working order all this time from what I can tell. But the > official viewer even goes so far as to warn that you "can't revoke this" in > the PERMISSION_DEBIT dialog. Is there some issue with it that noone is > aware of? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/8b82bb38/attachment.htm From soft at lindenlab.com Wed Jun 4 12:13:20 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 12:13:23 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 2:02 PM, Argent wrote: > On 6/4/08, Dale Mahalko wrote: >> My only concern is that the GUID distribution is may be just merely >> pseudo-random. When this system was dreamed up at the start of SL, >> did anyone actually do studies of the randomness of the distributions? > > I believe the SL UUIDs are actually generated randomly, often on the > user's computer(!), with a variety of seeds. The ones generated in the viewer are placeholders until the asset is assigned a proper ID as part of the asset storage process. If any type client-generated UUIDs persists, that should be filed as a security issue in JIRA. From mrfrans at gmail.com Wed Jun 4 12:22:12 2008 From: mrfrans at gmail.com (Frans) Date: Wed Jun 4 12:22:18 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <48465917.1010005@weblogsinc.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> Message-ID: <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> 5GB doesn't sounds like much if you video chat and use services like joost and hulu. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/d4dbf1f0/attachment.htm From nexeus at nexeusfatale.com Wed Jun 4 12:34:09 2008 From: nexeus at nexeusfatale.com (Nexeus Fatale) Date: Wed Jun 4 12:34:11 2008 Subject: [sldev] RevokePermissions In-Reply-To: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> References: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> Message-ID: Isn't it just easier to, when running the script, set the permission changes in the entry state or rezzed state? On Wed, Jun 4, 2008 at 3:12 PM, Frans wrote: > I suspect that there isn't a list kept on the servers to what you have > given permission_debit. So it would only be usefull for things you do know > of, which in most cases you can revoke by reseting the script anyway. > > On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby > wrote: > >> Hey all, just wanted to ask if there's been any discussion as to why the >> RevokePermissions message hasn't been implemented in the official viewer. >> It seems to be in working order all this time from what I can tell. But the >> official viewer even goes so far as to warn that you "can't revoke this" in >> the PERMISSION_DEBIT dialog. Is there some issue with it that noone is >> aware of? >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/d48f2d3d/attachment.htm From darien_caldwell at comcast.net Wed Jun 4 12:48:54 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Wed Jun 4 12:49:05 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? -------------- Original message ---------------------- From: Alex Dailey > A humorous side note to this. The distribution of uuid's is so random > and there is so much 'space' between values, that Cory et al. joked > about putting phony assets in the early range, ...0000000, 0000001 that > rezz'ed signs saying things like, "Give up now!" and "Abandon your quest > or despair!" for people who tried to guess asset_id's starting from the > beginning of the uuid range. > > Kent Quirk (Q Linden) wrote: > > > > On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > > > >> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko > >> wrote: > >>> My only concern is that the GUID distribution is may be just merely > >>> pseudo-random. ... > >> > >> Why not hash the (entire) GUID and use that instead? > > > > The point of a GUID is that it's already random. Or more correctly, > > "merely" pseudo-random. Not that most computers have a handy source of > > true randomness anyway. > > > > Our GUID generation code is found in lluuid.h/.cpp. There are comments > > in there that indicate that we've thought about distribution and the > > quality of our randomness before. > > > > Which makes sense, given that we have to store *all* of those assets > > ourselves. If they had a tendency to sort themselves into buckets, > > we'd have a lot more trouble managing them than any external caching > > scheme will. I don't think this is something to bother with. > > > > Q > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robin.cornelius at gmail.com Wed Jun 4 13:25:36 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 13:25:42 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: <4846FA40.4010102@gmail.com> darien_caldwell@comcast.net wrote: > This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your specific question its 1/4294967296 (1 in about 4.2 billion). Chance of winning the UK lottery is about 1/14 Million for a perspective BUT i can generate *vastly* more assets than i can ever buy lottery tickets and they are being generated by a lot of sources. But 8 may provide a useful sort providing you do allow for the possibility of a collision and have a fall back to higher precision. Either that or i've gone nuts and cant do math(s) any more, which is not an unreasonable assumption. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/814ce701/signature.pgp From robin.cornelius at gmail.com Wed Jun 4 13:27:31 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 13:27:36 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> Message-ID: <4846FAB3.1060009@gmail.com> Robin Cornelius wrote: > darien_caldwell@comcast.net wrote: >> This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? >> > > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). Oh assuming a perfect random (white) distribution of cause, any error, grouping, bais or offset throws this to the dogs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/0e059355/signature-0001.pgp From thordain at thordain.com Wed Jun 4 13:28:19 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jun 4 13:28:22 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> Message-ID: Maybe I'm just reading this wrong, but the bandwidth is availible in tiers. I haven't used Road Runner for some years, but it _used_ to be $50.00 PERIOD. Now it's "* [T]iers will range from $29.95 a month for... 768 kilobits per second and a 5-gigabyte monthly cap to $54.90 per month for... 15 megabits per second and a 40-gigabyte cap".* At 40GB per month, that's 40,960MB per month which (assuming your calculations are correct at 4MB per minute) is 28 days straight access without ceasing activity. Don't get me wrong, I think Time Warner is shooting below the belt with a max 40GB cap, but tiered access makes perfect sense. Grandma who wants to read her GMail from her grandsons and browse the internet for better sugar cookie recipies shouldn't have to pay $49.99 a month, and she'll never use 40GB. Also, they appear to be offering symmetric 15MBps for their higher tier plan (probably trying to compete with FIOS) which is quite an upgrade from what they used to offer. I'm not defending Time Warner Cable here because for the most part I think they're a bunch of idiots (having used their services for years), but I'm hearing an awful lot of doom and gloom about "SL and the media-rich internet going away now" and I just don't think that's going to happen here. TWC is the only major broadband service provider in the US offering a cap of less than 100-GB/month, and they are doing this as a trial for two months where they won't even be charging overage fees. If their pilot program goes bad (and tiered access for them has before) they'll likely ditch it. If not, AT&T and Verizon both sell 7Mbps DSL plans with unlimited bandwidth for around $30.00. My feeling is alot of people will be switching to DSL at that point if they don't see the light. On Wed, Jun 4, 2008 at 3:22 PM, Frans wrote: > 5GB doesn't sounds like much if you video chat and use services like joost > and hulu. > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/0a7596bb/attachment.htm From soft at lindenlab.com Wed Jun 4 13:37:40 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 13:37:43 2008 Subject: LLUUID collisions - was Re: [sldev] Cache speed experiment & results... Message-ID: On Wed, Jun 4, 2008 at 2:48 PM, wrote: > This reminds me of something I once pondered. Do you think the UUIDs > are random enough, that one could rely on a comparison of only the > first 8 digits as a sort of quick and dirty identification? What would the > chance be of a false match in such a case? http://en.wikipedia.org/wiki/Birthday_problem#Generalizations From q at lindenlab.com Wed Jun 4 14:17:11 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Jun 4 14:17:18 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> Message-ID: <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> On Jun 4, 2008, at 4:25 PM, Robin Cornelius wrote: > darien_caldwell@comcast.net wrote: >> This reminds me of something I once pondered. Do you think the >> UUIDs are random enough, that one could rely on a comparison of >> only the first 8 digits as a sort of quick and dirty >> identification? What would the chance be of a false match in such a >> case? >> > > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits > its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). > > Chance of winning the UK lottery is about 1/14 Million for a > perspective > BUT i can generate *vastly* more assets than i can ever buy lottery > tickets and they are being generated by a lot of sources. But 8 may > provide a useful sort providing you do allow for the possibility of a > collision and have a fall back to higher precision. > > Either that or i've gone nuts and cant do math(s) any more, which is > not > an unreasonable assumption. There are a couple more issues here: a) UUIDs are constructed from a collection of bytes, some of which are a timestamp. Using a subset of them might well lead to collisions. b) The probability of a collision if you only use 8 bits is about 1.1% if you have 10K items, and about 68% if you have 100K items. That seems WAY too high to me. It's the birthday "paradox" -- the probability that two people have the same birthday. In python, the formula is: import math def birthday(n, bits): return 1. - math.exp((-(n*n) / (2.*pow(2, bits)))) >>> birthday(10000, 32) 0.011574031737030754 >>> birthday(100000, 32) 0.68781309569379223 >>> birthday(1000, 32) 0.00011640854582628535 Why bother? Comparing strings is slowest if they agree, and fastest if they disagree...so you only pay for a full length comparison if they're the same, which is then swamped by what you do with the item once you've found it. This definitely feels like an unnecessary "optimization". From robin.cornelius at gmail.com Wed Jun 4 14:44:40 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 14:44:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> Message-ID: <48470CC8.60702@gmail.com> Kent Quirk (Q Linden) wrote: > There are a couple more issues here: > > a) UUIDs are constructed from a collection of bytes, some of which are a > timestamp. Using a subset of them might well lead to collisions. > b) The probability of a collision if you only use 8 bits is about 1.1% > if you have 10K items, and about 68% if you have 100K items. That seems > WAY too high to me. It's the birthday "paradox" -- the probability that > two people have the same birthday. In python, the formula is: Yes of cause and thanks soft for the link too. I only considered a single match which was a straight probability but we are considering a match in a pool where any member can match any other member so the actual resultant probability drops substantially in relation to the square of the pool size. I did warn you about my math(s) ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/449d7649/signature.pgp From Celierra at gmail.com Wed Jun 4 14:51:48 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Jun 4 14:51:52 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: On Wed, Jun 4, 2008 at 3:48 PM, wrote: > This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? > The texture console already does this. :) But the tradeoff for the texture console is much better than for looking up in the cache, since the full UUID would be overkill for the console's purposes. ~Cel From darien_caldwell at comcast.net Wed Jun 4 16:24:12 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jun 4 16:24:17 2008 Subject: [sldev] Cache speed experiment & results... References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> Message-ID: <87EE6574C29C413CB85C0E4165C2EB07@a644000> Thanks Quarl, Robin, and Soft for your replies. Initially i was thinking like Robin first stated, but was concerned I might be missing something. And I was. :) ----- Original Message ----- From: "Kent Quirk (Q Linden)" To: Cc: ; "Second Life Developer Mailing List" Sent: Wednesday, June 04, 2008 2:17 PM Subject: Re: [sldev] Cache speed experiment & results... > > On Jun 4, 2008, at 4:25 PM, Robin Cornelius wrote: > >> darien_caldwell@comcast.net wrote: >>> This reminds me of something I once pondered. Do you think the UUIDs >>> are random enough, that one could rely on a comparison of only the >>> first 8 digits as a sort of quick and dirty identification? What would >>> the chance be of a false match in such a case? >>> >> >> Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its >> 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your >> specific question its 1/4294967296 (1 in about 4.2 billion). >> >> Chance of winning the UK lottery is about 1/14 Million for a perspective >> BUT i can generate *vastly* more assets than i can ever buy lottery >> tickets and they are being generated by a lot of sources. But 8 may >> provide a useful sort providing you do allow for the possibility of a >> collision and have a fall back to higher precision. >> >> Either that or i've gone nuts and cant do math(s) any more, which is not >> an unreasonable assumption. > > There are a couple more issues here: > > a) UUIDs are constructed from a collection of bytes, some of which are a > timestamp. Using a subset of them might well lead to collisions. > b) The probability of a collision if you only use 8 bits is about 1.1% if > you have 10K items, and about 68% if you have 100K items. That seems WAY > too high to me. It's the birthday "paradox" -- the probability that two > people have the same birthday. In python, the formula is: > > import math > def birthday(n, bits): > return 1. - math.exp((-(n*n) / (2.*pow(2, bits)))) > > >>> birthday(10000, 32) > 0.011574031737030754 > >>> birthday(100000, 32) > 0.68781309569379223 > >>> birthday(1000, 32) > 0.00011640854582628535 > > > Why bother? Comparing strings is slowest if they agree, and fastest if > they disagree...so you only pay for a full length comparison if they're > the same, which is then swamped by what you do with the item once you've > found it. This definitely feels like an unnecessary "optimization". > > > From jake at lindenlab.com Wed Jun 4 17:15:35 2008 From: jake at lindenlab.com (Jake Simpson) Date: Wed Jun 4 17:15:40 2008 Subject: [sldev] Puppettering Branch Message-ID: <48473027.9090101@lindenlab.com> Some of you may have noticed there's a new build package on S3 named "Puppeteering". The link to it is here - http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset urls is http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) I wanted to give you some background on what it is, why it's there and what it can do. Puppeteering is a project that we had going last year that we dropped in order to focus on stability issues. Note, at the time this was a pretty contentious move, some internal people were fairly upset about it (one even quit over it) but it was deemed necessary for focus on stability to be the main issue. Also, using a mouse to actually generate animation is less instinctual than we had originally imagined and that was another nail in the coffin. The basic idea of the project was to enable real time animation of the avatar, via mouse so that you can animate on the fly and other people can see you doing it. Therefore there is (obviously) some simulator side code that's not being released and which is not in our current simulator releases, nor is there much intent to really make it so. However, the client side code works fine without the simulator data passing code - it's just that no one else logged in can see you when you do the puppeteering animation. Now we recently resurrected this code and have distributed it to various partners who have items in the works that might well end up using this code - basically we've given it to them, said "see if you can make something compelling with it, and if you can, we may reconsider finishing up the simulator code and pushing it through". Anyway, to cut a long story short we (myself and Robla) thought about it and said "Well, if they can't, maybe the SLDev crew can do something with this" and with that we decided to publish the code to you guys. The code itself is somewhat complete - there are definitely some things we would do differently and there are still definitely bugs in there, but right now it's pretty unlikely that we will return to this to complete it or refactor that which we would want to change with the code and intent as it stands. So, this is unsupported code, lets be clear, but it's out there and if you guys can do cool things with it then we would definitely love to see it. It's based off 1.19.1 by the way, and we do actually have a region on aditi that is running the simulator code (note, again, this code is relatively incomplete and the simulator could well crash) named Puppeteering (You may well need to log directly into it by they way). Enjoy. Jake Simpson From loom at loomiverse.net Wed Jun 4 17:26:08 2008 From: loom at loomiverse.net (Loom) Date: Wed Jun 4 17:26:10 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> Message-ID: FWIW, Australia has had metered broadband for years. Aside from the argument about whether that is good or bad, it hasn't stopped us using the internet, Secondlife, torrents, p2p, WoW or much else I can't say I'm happy with what seems to be happening in the US, since it is justifies what our ISP's have been doing for years, but I am farily confident that it isn't going to end SL for anyone. Loom Kish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/4c9554b1/attachment.htm From loom at loomiverse.net Wed Jun 4 17:41:42 2008 From: loom at loomiverse.net (Loom) Date: Wed Jun 4 17:41:44 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> Message-ID: On 04/06/2008, Darien Caldwell wrote: > > If you were to run the client at full bandwidth available (1500kb) non > stop 24/7, you would use up the proposed 240 gbit a month Comcast is > proposing in 48 hours. Fortunately, most people don't eat up that much. A > sustained data rate of 275kbps 8 hours a day for 30 days would use up the > 240 gbit limit. Key word is sustained, sitting in a sim doing nothing > it's rare you get a transfer rate over 50kbps. It would be interesting to > see how a normal session averages out however. This certainly will impact > heavy users (like me), but to the average user, they won't see any problems. > > I think that you might be comparing Gigabits and Gigabytes there, since bandwidth is measured in Gbps and the cap is measured in GB. 275kbps for 8 hours a day for 30 days is about 24 GB, not 240 and thats allowing 10 bits to the byte to err on the side of caution Using the same number 1500kbps used 24/7 would take just under 20 days to use 250GB Loom Kish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3f3e52d3/attachment.htm From darien_caldwell at comcast.net Wed Jun 4 18:06:27 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jun 4 18:06:32 2008 Subject: [sldev] Cache speed experiment & results... References: <617974.16404.qm@web59110.mail.re1.yahoo.com><3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> Message-ID: <164E7CC7409F4E0887935BDC18DA3561@a644000> You are probably right. I've always found the units a little confusing. But i like your numbers even better than mine. ^.^ ----- Original Message ----- From: Loom To: Second Life Developer Mailing List Sent: Wednesday, June 04, 2008 5:41 PM Subject: Re: [sldev] Cache speed experiment & results... On 04/06/2008, Darien Caldwell wrote: If you were to run the client at full bandwidth available (1500kb) non stop 24/7, you would use up the proposed 240 gbit a month Comcast is proposing in 48 hours. Fortunately, most people don't eat up that much. A sustained data rate of 275kbps 8 hours a day for 30 days would use up the 240 gbit limit. Key word is sustained, sitting in a sim doing nothing it's rare you get a transfer rate over 50kbps. It would be interesting to see how a normal session averages out however. This certainly will impact heavy users (like me), but to the average user, they won't see any problems. I think that you might be comparing Gigabits and Gigabytes there, since bandwidth is measured in Gbps and the cap is measured in GB. 275kbps for 8 hours a day for 30 days is about 24 GB, not 240 and thats allowing 10 bits to the byte to err on the side of caution Using the same number 1500kbps used 24/7 would take just under 20 days to use 250GB Loom Kish ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/6c43ba2b/attachment.htm From gbrandon at gmail.com Wed Jun 4 19:12:35 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 19:12:39 2008 Subject: [sldev] RevokePermissions In-Reply-To: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> References: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> Message-ID: In some cases, I think it'd be good enough to just have a menu option like Tools > Revoke Permissions (or Advanced?) for now. Like if you gave someone's attachment permission to play animations and they abused it, you could just select it and then hit that menu option The server-side list is an interesting idea, wonder if that's perhaps what it was waiting on? On Wed, Jun 4, 2008 at 3:12 PM, Frans wrote: > I suspect that there isn't a list kept on the servers to what you have > given permission_debit. So it would only be usefull for things you do know > of, which in most cases you can revoke by reseting the script anyway. > > On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby > wrote: > >> Hey all, just wanted to ask if there's been any discussion as to why the >> RevokePermissions message hasn't been implemented in the official viewer. >> It seems to be in working order all this time from what I can tell. But the >> official viewer even goes so far as to warn that you "can't revoke this" in >> the PERMISSION_DEBIT dialog. Is there some issue with it that noone is >> aware of? >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/3033e7a6/attachment.htm From secret.argent at gmail.com Wed Jun 4 19:24:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 19:23:14 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FAB3.1060009@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <4846FAB3.1060009@gmail.com> Message-ID: <42DFFCF9-0BFB-480F-B26F-0D40D562382A@gmail.com> On 2008-06-04, at 15:27, Robin Cornelius wrote: > Robin Cornelius wrote: >> Well for the 1st digit there is a 1/16 chance of a hit, for 2 >> digits its >> 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your >> specific question its 1/4294967296 (1 in about 4.2 billion). > > Oh assuming a perfect random (white) distribution of cause, any error, > grouping, bais or offset throws this to the dogs. Of course the next question is... what's the consequences of a false positive? If it's "you compare the whole thing", it doesn't matter. A common trick in C is something like this: if(*s == *t && strcmp(s, t)==0) { ... } If *s and *t are uniformly distributed, you save 255/256 calls. If they're both letters, you save 25 out of 26. If that's in a tight loop, it's worth doing. From secret.argent at gmail.com Wed Jun 4 19:29:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 19:28:17 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> > Anyway, to cut a long story short we (myself and Robla) thought > about it and said "Well, if they can't, maybe the SLDev crew can do > something with this" and with that we decided to publish the code > to you guys. What I'd like to do with this would require server-side access. I don't want to drag my hand with my mouse, I want to tell my hand "track this prim". And I want to do it from a script. Why? Well, how about so I can walk along holding someone's hand, because they're wearing the prim I'm tracking... not because we're both riding a vehicle that's animating walks for both of us. So when I'm riding a vehicle, it can make my hands hold onto the handlebars, without my having to change the animation based on the avatar size. Automated puppetteering. From me at signpostmarv.name Wed Jun 4 21:28:06 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Jun 4 21:28:12 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <48476B56.6040004@signpostmarv.name> Argent Stonecutter wrote: >> Anyway, to cut a long story short we (myself and Robla) thought about >> it and said "Well, if they can't, maybe the SLDev crew can do >> something with this" and with that we decided to publish the code to >> you guys. > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand > "track this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's hand, > because they're wearing the prim I'm tracking... not because we're > both riding a vehicle that's animating walks for both of us. > > So when I'm riding a vehicle, it can make my hands hold onto the > handlebars, without my having to change the animation based on the > avatar size. > > Automated puppetteering. something along those lines ? : http://jira.secondlife.com/browse/SVC-2478 http://jira.secondlife.com/browse/SVC-2479 ~ Marv -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/dbe32273/smime.bin From gbrandon at gmail.com Wed Jun 4 21:53:48 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 21:53:51 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: Assuming LL doesn't write a simulator for you, might I suggest the possiblity of using slproxy to emulate the server-side behaviors? :D On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter wrote: > Anyway, to cut a long story short we (myself and Robla) thought about it >> and said "Well, if they can't, maybe the SLDev crew can do something with >> this" and with that we decided to publish the code to you guys. >> > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand "track > this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's hand, because > they're wearing the prim I'm tracking... not because we're both riding a > vehicle that's animating walks for both of us. > > So when I'm riding a vehicle, it can make my hands hold onto the > handlebars, without my having to change the animation based on the avatar > size. > > Automated puppetteering. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/d9225109/attachment.htm From kf6kjg at gmail.com Wed Jun 4 22:30:45 2008 From: kf6kjg at gmail.com (Ricky) Date: Wed Jun 4 22:30:49 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error Message-ID: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> Ok, I am trying to compile the latest from SVN in a 32 bit chroot on my 64 bit Gentoo desktop. I was able to compile the cmake-8 branch a while ago (with a patch I made to one of the files) so I think I have all the requirements in place... Maybe. This chroot is the first I have ever made! :D Here is the error thrown: Linking CXX executable linux-crash-logger /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Realloc' /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Alloc' /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Free' collect2: ld returned 1 exit status make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] Error 2 make: *** [all] Error 2 Any ideas on what I am missing? I looked through JIRA to see if anythign had been reported, and I've been monitoring this list and heard nothing, so it very well might just be me... :) If there is a missing dependency, could the cmake script check for it? Or would that be better done by the person/script doing the compiling? Thanks for the info! Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/45e01306/attachment.htm From danteferret at gmail.com Wed Jun 4 23:15:37 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Jun 4 23:15:45 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> Out of curiosity how is this client used? I compiled, went to the sim on aditi, and I see no aditional functionality from the standard client. (sorry for the double mail Brandon) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/dedcf07f/attachment.htm From kfa at gmx.net Wed Jun 4 23:18:01 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 23:20:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <48478519.2080106@gmx.net> Argent Stonecutter wrote: >> Anyway, to cut a long story short we (myself and Robla) thought about >> it and said "Well, if they can't, maybe the SLDev crew can do >> something with this" and with that we decided to publish the code to >> you guys. > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand > "track this prim". > Has anyone thought of this... well I'm sure many have before! Teaching in SL is already a big thing, and it could be much much bigger if we had better tools to simulate a real classroom situation. Better control of an avatar's hand would be a hinge for a ton of enhancements. I've taken some language courses in SL and it always was glaringly obvious that we missed a pointing device. A laser pointer or just a stick. It should be possible to translate the mouse position over a certain prim (the white/black board) into the target of a "look at" function to rotate the avatar's hand (or what it's holding) accordingly. More sophisticated, I'd like to use one of those graphics pads, capture what I'm drawing into a video stream (Gimp + CamStudio ?) and let that appear on the said white board, and together with the positional information from the same graphics pad (it's functionally the same as a mouse) simulate my avatar drawing it live there before everyone's eyes. Is that code going in a direction to enable such a thing? Felix PS: Actually, to me this sounds like a worthy project for a dedicated group even more than - forgive me - the NAV project. Immersion and realism would get a quantum leap forward and there is business in this. From robin.cornelius at gmail.com Wed Jun 4 23:22:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 23:22:37 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> Message-ID: <4847862B.7060509@gmail.com> Ricky wrote: > Linking CXX executable linux-crash-logger > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Realloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Alloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Free' > collect2: ld returned 1 exit status > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] > Error 2 > make: *** [all] Error 2 > > > Any ideas on what I am missing? I looked through JIRA to see if > anythign had been reported, and I've been monitoring this list and heard > nothing, so it very well might just be me... :) Free type library (libfreetype), There is a right mix of building methods being used so unless you are building the offical linden version in a chroot no one would spot this kind of thing. I only ever build standalone versions on linux so i have to supply my own libpango anyway which has a hard dependency of libfreetype, and many others probably have libfreetype-dev installed (or what ever you do on gentoo) so it just worked for them. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/19b53b3a/signature.pgp From kf6kjg at gmail.com Wed Jun 4 23:55:19 2008 From: kf6kjg at gmail.com (Ricky) Date: Wed Jun 4 23:55:21 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <4847862B.7060509@gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> Message-ID: <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> hmm... According to portage (the package management system for Gentoo) I already have freetype 2.3.5-r2 installed in the chroot. (For those who speak emerge:) # emerge -pv media-libs/freetype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/freetype-2.3.5-r2 USE="X -bindist -debug -doc -utils" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB On Wed, Jun 4, 2008 at 11:22 PM, Robin Cornelius wrote: > Ricky wrote: > > Linking CXX executable linux-crash-logger > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Realloc' > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Alloc' > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Free' > > collect2: ld returned 1 exit status > > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > > make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] > > Error 2 > > make: *** [all] Error 2 > > > > > > Any ideas on what I am missing? I looked through JIRA to see if > > anythign had been reported, and I've been monitoring this list and heard > > nothing, so it very well might just be me... :) > > Free type library (libfreetype), > > There is a right mix of building methods being used so unless you are > building the offical linden version in a chroot no one would spot this > kind of thing. I only ever build standalone versions on linux so i have > to supply my own libpango anyway which has a hard dependency of > libfreetype, and many others probably have libfreetype-dev installed (or > what ever you do on gentoo) so it just worked for them. > > Robin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/da623854/attachment-0001.htm From sldev at bitparts.org Thu Jun 5 00:10:49 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Thu Jun 5 00:11:02 2008 Subject: [sldev] Error (misspelling) in lltexturefetch.cpp Message-ID: <48479179.6090309@bitparts.org> So after all this cache discussion, I decided to download the source and see if I could find some way to cache files decoded. Unfortunately, while I'm a C Guru, I'm yet again slapping my hands for not seriously learning C++. However, while I stumbled around, I came across this - lltexturefetch.cpp, line 228 (from slviewer-src-Branch_1-20-7-Viewer-r88152.zip): void relese() { --mActiveCount; } I searched the rest of the entire project, and found no other occurrences of "relese" - could this be a problem? Is something searching for "release" and not finding it, or has the function been deprecated? From danteferret at gmail.com Thu Jun 5 00:45:52 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 5 00:45:56 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> Message-ID: <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: puppetter.png Type: image/png Size: 502697 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/6fc8d045/puppetter-0001.png From robin.cornelius at gmail.com Thu Jun 5 00:54:45 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 00:54:49 2008 Subject: [sldev] Error (misspelling) in lltexturefetch.cpp In-Reply-To: <48479179.6090309@bitparts.org> References: <48479179.6090309@bitparts.org> Message-ID: > void relese() { --mActiveCount; } > > I searched the rest of the entire project, and found no other occurrences of > "relese" - could this be a problem? Is something searching for "release" and > not finding it, or has the function been deprecated? Looks like a dead function, certainly nothing is trying to call it or it would be a compile/link error. Greping through the code mActiveCount does not appear to do anything either, looks like it was trying to count the number of active texture worker threads, it may be part of the "enable multiple threads" plan which works to a point but some report deadlocks. As for the caching of decoded files, my inital gut feeling is that you can cache them in the WRITE_TO_CACHE state of the state machine, by swapping out the mFormattedImage->getData() to the buffer that was retrieved in DECODE_IMAGE and the reverse operation in LOAD_FROM_TEXTURE_CACHE needs to load them into the raw image buffer not the mFormattedImage, the recall will probably be a little harder as you need to ensure the buffers are big enough and you will have to rig the states so it can jump stright over to DONE after that and make sure there are no mFormattedImage memory allocations left around. Discard will just be ignored for a cache hit. I've started looking but as usual time is the limiting factor. Robin From robin.cornelius at gmail.com Thu Jun 5 01:10:30 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 01:10:33 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 7:55 AM, Ricky wrote: > hmm... According to portage (the package management system for Gentoo) I > already have freetype 2.3.5-r2 installed in the chroot. > And i am being stupid at the same time, its complaining of missing symbols not a missing library so its not even attempting to link against freetype. But it must have found the freetype headers. STANDALONE uses pkgconfig in indra/Freetype.cmake which will set the CFLAGS and LDFLAGS correctly, something is missing somewhere then in the standard build? Has it detected you are on 64bit and changed the library location to libraries/x86_64-linux which i presume there are no prebuild libs for? From evolutie at gmail.com Thu Jun 5 01:50:34 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 01:50:37 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <5fb4b1fa0806050150i628f9118v226c768be07ad6a1@mail.gmail.com> ohhh! i'm so happy about this!! thanks!! Evo On Thu, Jun 5, 2008 at 2:15 AM, Jake Simpson wrote: > Some of you may have noticed there's a new build package on S3 named > "Puppeteering". The link to it is here - > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset > urls is > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) > > I wanted to give you some background on what it is, why it's there and what > it can do. > > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one even > quit over it) but it was deemed necessary for focus on stability to be the > main issue. Also, using a mouse to actually generate animation is less > instinctual than we had originally imagined and that was another nail in the > coffin. > > The basic idea of the project was to enable real time animation of the > avatar, via mouse so that you can animate on the fly and other people can > see you doing it. Therefore there is (obviously) some simulator side code > that's not being released and which is not in our current simulator > releases, nor is there much intent to really make it so. However, the client > side code works fine without the simulator data passing code - it's just > that no one else logged in can see you when you do the puppeteering > animation. > > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this code > - basically we've given it to them, said "see if you can make something > compelling with it, and if you can, we may reconsider finishing up the > simulator code and pushing it through". > > Anyway, to cut a long story short we (myself and Robla) thought about it and > said "Well, if they can't, maybe the SLDev crew can do something with this" > and with that we decided to publish the code to you guys. > > The code itself is somewhat complete - there are definitely some things we > would do differently and there are still definitely bugs in there, but right > now it's pretty unlikely that we will return to this to complete it or > refactor that which we would want to change with the code and intent as it > stands. > > So, this is unsupported code, lets be clear, but it's out there and if you > guys can do cool things with it then we would definitely love to see it. > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > > Enjoy. > > Jake Simpson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- http://www.creativemachinery.org From secret.argent at gmail.com Thu Jun 5 04:12:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 5 04:11:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48476B56.6040004@signpostmarv.name> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <48476B56.6040004@signpostmarv.name> Message-ID: <318BF2E8-017D-4481-BF09-78D5BFED2ED4@gmail.com> On 2008-06-04, at 23:28, SignpostMarv Martin wrote: > something along those lines ? : > > http://jira.secondlife.com/browse/SVC-2478 > http://jira.secondlife.com/browse/SVC-2479 Except for being immensely simpler to specify and implement, yes. SL already has code to track prims with attachment points, your left hand uses them every time you edit an object. And by tracking a prim you're not restricted to tracking avatars, but you get that for free. From secret.argent at gmail.com Thu Jun 5 04:19:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 5 04:17:50 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> On 2008-06-04, at 23:53, Brandon Lockaby wrote: > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D I'm not sure how SLProxy would help... the important bit would be scripted. llTrackPrim(integer joint, key prim, integer distance, integer strictness, integer follow_rotation); While prim is in range of motion of joint, joint is constrained to remain in distance meters of the center of prim. Strictness indicates how quickly it would track the prim, and follow_rotation whether it should try and rotate the joint to match the angle of the prim. It would apply to the owner or the avatar for which the script has appropriate permissions. From blindwanderer at gmail.com Thu Jun 5 07:09:18 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Thu Jun 5 07:09:21 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <89ca6da00806050709v7f6e585ekf393bb9e51f86941@mail.gmail.com> Hey jake, just noticed a bug in SVN-616 (R88154). There is a collision in /indra/llmessage/llregionflags.h between REGION_FLAGS_BLOCK_PUPPETEERING and REGION_FLAGS_BLOCK_PARCEL_SEARCH. I've posted a patch on Jira. https://jira.secondlife.com/browse/VWR-7606 On Wed, Jun 4, 2008 at 8:15 PM, Jake Simpson wrote: > Some of you may have noticed there's a new build package on S3 named > "Puppeteering". The link to it is here - > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset > urls is > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) > > I wanted to give you some background on what it is, why it's there and what > it can do. > > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one even > quit over it) but it was deemed necessary for focus on stability to be the > main issue. Also, using a mouse to actually generate animation is less > instinctual than we had originally imagined and that was another nail in the > coffin. > > The basic idea of the project was to enable real time animation of the > avatar, via mouse so that you can animate on the fly and other people can > see you doing it. Therefore there is (obviously) some simulator side code > that's not being released and which is not in our current simulator > releases, nor is there much intent to really make it so. However, the client > side code works fine without the simulator data passing code - it's just > that no one else logged in can see you when you do the puppeteering > animation. > > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this code > - basically we've given it to them, said "see if you can make something > compelling with it, and if you can, we may reconsider finishing up the > simulator code and pushing it through". > > Anyway, to cut a long story short we (myself and Robla) thought about it and > said "Well, if they can't, maybe the SLDev crew can do something with this" > and with that we decided to publish the code to you guys. > > The code itself is somewhat complete - there are definitely some things we > would do differently and there are still definitely bugs in there, but right > now it's pretty unlikely that we will return to this to complete it or > refactor that which we would want to change with the code and intent as it > stands. > > So, this is unsupported code, lets be clear, but it's out there and if you > guys can do cool things with it then we would definitely love to see it. > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > > Enjoy. > > Jake Simpson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Thu Jun 5 08:09:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 08:09:24 2008 Subject: [sldev] Re: Open source meeting, call for items Thursday 2PM In-Reply-To: References: Message-ID: Open source meeting - Thursday, 2pm PT in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Last weeks minutes are at :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/2008-05-29 I've added a few issues that i think may be worth discussing, but please if you have anything better thats burning a hole, please add to the wiki page and replace some of my rubbish if it gets too full ;-) # Texture caching, follow up from SLDEV, can we store some kind of uncompressed data etc # VWR-7531 - Dynamic grid loading to the login panel # Puppettering - Jake gave us the source code to discuss and play.. so Discuss! (seriously, not sure if there is much if better items turn up last minute then please replace) # cmake - Hows everyone finding it, build issues, other issues etc From monkowsk at watson.ibm.com Thu Jun 5 08:35:59 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 08:37:46 2008 Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <484807DF.2070806@watson.ibm.com> Was voice moderation and morphing another of the projects that was dropped? (I did see the puppet master's name in the voice code ;-) ) If so, can we have the code for that too? If not, when do you think we might see it? Mike Jake Simpson wrote: > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one > even quit over it) but it was deemed necessary for focus on stability to > be the main issue. From sarah at aucreativegroup.com Thu Jun 5 08:37:46 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 08:37:51 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> Message-ID: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Hello all! Thank you so much for your feedback and comments on the Landmarks & Navigation project. My name is Kippie Friedkin and I'm a member of the Vectorform team. The team has been watching the threads and taking into consideration all of your input. We're excited that there has been so much interest in this project! Working on an open source project is a great learning experience for us, so we've been careful to respond with accuracy. Now we'll work on responding with a little more speed. As we have begun to define the design and functionality, we're better positioned to understand and discuss the technical issues. I thought I'd begin this note with an update on the project - where we've been, where we are, and where we're going. *Where we've been *The project began with a massive research phase that encompassed Office Hours discussions, interviews with Residents (both new and veteran), scouring Second Life blogs, researching resident-created tools, reviewing other Viewers and a host of web apps. During this phase, it was our goal to learn how Residents navigate in-world and how they create, use, and manage Landmarks. We solicited feedback on their pain points, ideas, and general comments that touched on Inventory, Landmarks, navigation, and User Picks. At the end of this research phase, we presented our finding to Linden Lab as well as some initial mockups and wireframes that would satisfy some of the project goals (as stated on the WIKI) as: - *To create a history of locations visited*, presented in some visual fashion, which may include: - Back & forward buttons for teleporting through location history - Prominent on-screen affordance for accessing/adding Landmarks - *To improve the existing, or create a new, system for managing Landmarks*, which should support the following: - Sorting, re-ordering - Organizing into folders or similar - Renaming - Sharing - Tagging - *To create a new navigation panel* (ie. the visual container for the new UI components) - To provide the ability to hide/show this panel. A few other things were investigated and discussed at the project's onset: 1. Removing Landmarks from Inventory, in favor of a new system for managing Landmarks. 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Discussions with Residents quickly removed these two items from the scope of this project. Removing Landmarks from the Inventory is an extremely difficult thing from to do from an implementation perspective. It also means that one of our project requirements - that of backwards compatibility - was broken. So it was determined that Landmarks were best left a part of the Inventory. As noted, there are many ways a Landmark can end up in one's Inventory, and the pros of Landmarks being left where they are, very quickly outweighed any cons that currently exist. With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is. *Where we are today *The Vectorform team has spent the past few weeks working on wireframes and designs for the newly proposed features. Based on our research, Resident feedback, and meetings with Linden Lab, we are building the following features in the Viewer: 1. *Navigation Panel* The Navigation panel will include forward, back, home and history buttons, as well as an address/location text box and 'go' button. The designs are being revised and updated to fit more into the new Dazzle style with insight and feedback from Residents and Lindens. The Navigation Panel can be able to be shown or hidden using both a small toggle at the top-left of the Viewer as well a keyboard shortcut - "/". (We are still determining if this will work as a shortcut key, but an initial review indicated it was not being used by another UI element - so this is TBD). In between the back and forward buttons will be a small, history button which will allow a Resident to view the list of places he/she has visited during that session. The number of places stored in this history and whether it persists between sessions can be set in ones User Preferences. The name of the parcel and region will be shown in the location history. Mousing over an item in the list will reveal additional info (SLURL? How long ago you were there?) Clicking the back or forward button will automatically teleport the Resident back/foward in their location history. Clicking the home button will teleport the Resident back to his/her home location. Address Bar - The address bar will display a SLURL by default. Users can enter a SLURL, or Region name in their Inventory. If the Resident types in a Region name that is not in their Inventory, we will go a global search to find the location. If the location cannot be found, the Search floater will open. 2. *User Preferences *We are introducing a new tab to the User Preferences floater that will providing users the ability to: - Set the number of days to store location history - Set the number of days to store address bar history - Clear the history of either of the above two items - Export Landmarks in HTML, TXT, or XML formats 3. *Create/Edit Landmarks UI* Residents will now be able to add a custom name and stores notes when creating or editing a Landmark. There will also be the option to select or create a folder when creating/editing Landmarks. All Landmarks and their folders will be will be placed into the Landmarks folder in the Inventory floater. To clear up any confusion, the following circumstances will still apply: - Landmarks received from purchased objects will remain with the object/folder as they are created. - Landmarks received view Inventory transfer will be placed into a Received Landmarks folder by default, but also allow for the Resident to edit and select a folder in which to place the Landmark. - Landmarks received via automatic givers will also be placed into the Received Landmarks folder, by default. Still TBD in terms of scoping, but we'd also like to include functionality that allows the Resident to edit and select a folder in which to place the Landmark. - Landmarks embedded in Notecards will not see any change in functionality. The landmark will remain embedded in the Notecard and not accessible except through Notecard access. 4. *Landmarks Menu* A new 'Landmarks' menu will be added to the top menu of the Viewer. The options for this menu are as follows: - Create Landmark - Manage Landmarks - Set Home to Current Location - Teleport Home - Received Landmarks - A sub-folder in the Landmarks folder in Inventory where all received Landmarks are stored by default. - Recent Places - Displays a list of Landmarks a Resident has recented used. - Access to Landmarks located in the Inventory Floater - Residents will now have access to Landmarks stored in the Landmarks folder of their Inventory via this menu. Any sub-folders of the main Landmarks folder will appear in this Landmarks menu and be navigable via this menu. 5. *Manage Landmarks UI* This new UI element is meant to allow residents a filtered via of the Inventory, in which to organize and manage (edit/delete) Landmarks. It consists of a small floater which will almost look like a filter viewed of the Inventory Floater. The Manage Landmarks floater will allow Residents to filter Landmarks, create/edit/delete folders easily, and provide a place (without having to weed through the rest of the Inventory) to edit Landmarks. If you've had a chance to look at the wireframe posted on NAV-28, there are two approaches to the Manage Landmarks UI. At present, we have been asked to proceed with the separated floaters approach (Solution 2). Also, an advanced feature proposed for the Manage Landmarks UI was a Data Sort View which would allow Residents to view, sort, and manage Landmarks from a column set approach (like iTunes). However, at this time, we have been asked to put that feature on hold since it's real benefit has not been clear for all project stakeholders. When editing a Landmarks, Residents will have the ability to specify a custom name, add their own notes to each Landmark. Residents will also have the ability to specify a picture they want to use for a particular Landmark. Our technical team is also reviewing the possibility of allowing a Resident the option of using/reverting back to the default image for this location (as specified by the Land Owner). It is as of yet undetermined if this feature will be in scope. The Edit Landmarks Floater will include small icons for 'Show on Map' and 'Copy SLURL' to provide additional functionality. Finally, we intend to display additional metadata about the Landmark from the Edit Landmark floater - date acquired, last teleport date, and last updated date. *Shared Landmarks & Tagging *One of our original ideas (and a common suggestion from Residents) has been to include tagging of Landmarks and other Inventory assets. We investigated a couple of ways to create a folksonomy use with Landmarks in Second Life during the first phase of our project. However, it became clear that tagging functionality would be useful for many other areas and could touch many other areas including search, the web, User Picks, and most Inventory items. Rather than build a small one-off tagging system just for Landmarks, it was decided that creating a true folksonomy that could be used throughout Second Life (For searching, sharing landmarks, creating more a social network, etc.) was a much bigger project than our timeline or project goals would allow for. So tagging functionality was deemed out of scope for this project. *Where we're going! Issues, Risks, Reviews, and Builds! * The design team is working closely with Linden Lab and soliciting Resident feedback on new designs revisions. We hope to have design approachs for the new Nav bar solidifed by the end of this week. In the meantime, our technical team have been working on laying the foundation for the new Navigation bar, as well as spending time researching the items which many of you have spoken about on this list. A few items for which we're actively researching: - Understanding more about SLURLs and their relation to the Agni grid and how they come into play with the beta grid(s). - How the introduction of a new top-left UI element will affect Resident-created HUDs. - How the introduction of forward/back button teleport functionality will affect grid stability. In addition to researching open issues, our tech team is also working on wrapping up a Viewer build (minus approved creative). We will be testing that and reviewing it with Linden Lab over the next week. I would encourage all of you to continue sharing your thoughts and feedback. As I stated at the beginning of this message, the Vectorform team will be much more actively engaged with this list moving forward. Best, Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/1ebaedab/attachment-0001.htm From missannotoole at yahoo.com Thu Jun 5 08:41:02 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 08:41:03 2008 Subject: [sldev] Voice moderation and morphing; was: Voice moderation and morphing; was: [sldev] Puppettering Branch Message-ID: <507402.50528.qm@web59108.mail.re1.yahoo.com> Please put [sldev] as a prefix so these messages won't so easily be flagged and deleted as spam. Thanks. ----- Original Message ---- From: Mike Monkowski To: Jake Simpson Cc: sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:35:59 AM Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch Was voice moderation and morphing another of the projects that was dropped? (I did see the puppet master's name in the voice code ;-) ) If so, can we have the code for that too? If not, when do you think we might see it? Mike Jake Simpson wrote: > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one > even quit over it) but it was deemed necessary for focus on stability to > be the main issue. _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/b047cb64/attachment.htm From missannotoole at yahoo.com Thu Jun 5 08:49:31 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 08:49:34 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <328748.69828.qm@web59112.mail.re1.yahoo.com> I previously requested someone look into how this project can impact search and there were no replies so I will reiterate: Profile Picks are part of the new search relevancy. Messing with this breaks search. An external non LL contracted team cannot be allowed to work on things that will result in devastation of the economy. How this can even happen is interesting. Great work and all but who decided to allow you to potentially erase the SL economy? Landmarks were initially listed in the SL blog as being a search relevance factor. The entire discussion of removing landmarks should have never happened without a discussion of this factor first. My recommendation is for the LL search related team to pay more attention to protecting their turf and communicating with this community to ensure everyone understands how this work will or will not impact the new search. ----- Original Message ---- From: Sarah Hutchinson To: sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:37:46 AM Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Hello all! Thank you so much for your feedback and comments on the Landmarks & Navigation project. My name is Kippie Friedkin and I'm a member of the Vectorform team. The team has been watching the threads and taking into consideration all of your input. We're excited that there has been so much interest in this project! Working on an open source project is a great learning experience for us, so we've been careful to respond with accuracy. Now we'll work on responding with a little more speed. As we have begun to define the design and functionality, we're better positioned to understand and discuss the technical issues. I thought I'd begin this note with an update on the project - where we've been, where we are, and where we're going. Where we've been The project began with a massive research phase that encompassed Office Hours discussions, interviews with Residents (both new and veteran), scouring Second Life blogs, researching resident-created tools, reviewing other Viewers and a host of web apps. During this phase, it was our goal to learn how Residents navigate in-world and how they create, use, and manage Landmarks. We solicited feedback on their pain points, ideas, and general comments that touched on Inventory, Landmarks, navigation, and User Picks. At the end of this research phase, we presented our finding to Linden Lab as well as some initial mockups and wireframes that would satisfy some of the project goals (as stated on the WIKI) as: * To create a history of locations visited, presented in some visual fashion, which may include: * Back & forward buttons for teleporting through location history * Prominent on-screen affordance for accessing/adding Landmarks * To improve the existing, or create a new, system for managing Landmarks, which should support the following: * Sorting, re-ordering * Organizing into folders or similar * Renaming * Sharing * Tagging * To create a new navigation panel (ie. the visual container for the new UI components) * To provide the ability to hide/show this panel. A few other things were investigated and discussed at the project's onset: 1. Removing Landmarks from Inventory, in favor of a new system for managing Landmarks. 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Discussions with Residents quickly removed these two items from the scope of this project. Removing Landmarks from the Inventory is an extremely difficult thing from to do from an implementation perspective. It also means that one of our project requirements - that of backwards compatibility - was broken. So it was determined that Landmarks were best left a part of the Inventory. As noted, there are many ways a Landmark can end up in one's Inventory, and the pros of Landmarks being left where they are, very quickly outweighed any cons that currently exist. With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is. Where we are today The Vectorform team has spent the past few weeks working on wireframes and designs for the newly proposed features. Based on our research, Resident feedback, and meetings with Linden Lab, we are building the following features in the Viewer: 1. Navigation Panel The Navigation panel will include forward, back, home and history buttons, as well as an address/location text box and 'go' button. The designs are being revised and updated to fit more into the new Dazzle style with insight and feedback from Residents and Lindens. The Navigation Panel can be able to be shown or hidden using both a small toggle at the top-left of the Viewer as well a keyboard shortcut - "/". (We are still determining if this will work as a shortcut key, but an initial review indicated it was not being used by another UI element - so this is TBD). In between the back and forward buttons will be a small, history button which will allow a Resident to view the list of places he/she has visited during that session. The number of places stored in this history and whether it persists between sessions can be set in ones User Preferences. The name of the parcel and region will be shown in the location history. Mousing over an item in the list will reveal additional info (SLURL? How long ago you were there?) Clicking the back or forward button will automatically teleport the Resident back/foward in their location history. Clicking the home button will teleport the Resident back to his/her home location. Address Bar - The address bar will display a SLURL by default. Users can enter a SLURL, or Region name in their Inventory. If the Resident types in a Region name that is not in their Inventory, we will go a global search to find the location. If the location cannot be found, the Search floater will open. 2. User Preferences We are introducing a new tab to the User Preferences floater that will providing users the ability to: * Set the number of days to store location history * Set the number of days to store address bar history * Clear the history of either of the above two items * Export Landmarks in HTML, TXT, or XML formats 3. Create/Edit Landmarks UI Residents will now be able to add a custom name and stores notes when creating or editing a Landmark. There will also be the option to select or create a folder when creating/editing Landmarks. All Landmarks and their folders will be will be placed into the Landmarks folder in the Inventory floater. To clear up any confusion, the following circumstances will still apply: * Landmarks received from purchased objects will remain with the object/folder as they are created. * Landmarks received view Inventory transfer will be placed into a Received Landmarks folder by default, but also allow for the Resident to edit and select a folder in which to place the Landmark. * Landmarks received via automatic givers will also be placed into the Received Landmarks folder, by default. Still TBD in terms of scoping, but we'd also like to include functionality that allows the Resident to edit and select a folder in which to place the Landmark. * Landmarks embedded in Notecards will not see any change in functionality. The landmark will remain embedded in the Notecard and not accessible except through Notecard access. 4. Landmarks Menu A new 'Landmarks' menu will be added to the top menu of the Viewer. The options for this menu are as follows: * Create Landmark * Manage Landmarks * Set Home to Current Location * Teleport Home * Received Landmarks - A sub-folder in the Landmarks folder in Inventory where all received Landmarks are stored by default. * Recent Places - Displays a list of Landmarks a Resident has recented used. * Access to Landmarks located in the Inventory Floater - Residents will now have access to Landmarks stored in the Landmarks folder of their Inventory via this menu. Any sub-folders of the main Landmarks folder will appear in this Landmarks menu and be navigable via this menu. 5. Manage Landmarks UI This new UI element is meant to allow residents a filtered via of the Inventory, in which to organize and manage (edit/delete) Landmarks. It consists of a small floater which will almost look like a filter viewed of the Inventory Floater. The Manage Landmarks floater will allow Residents to filter Landmarks, create/edit/delete folders easily, and provide a place (without having to weed through the rest of the Inventory) to edit Landmarks. If you've had a chance to look at the wireframe posted on NAV-28, there are two approaches to the Manage Landmarks UI. At present, we have been asked to proceed with the separated floaters approach (Solution 2). Also, an advanced feature proposed for the Manage Landmarks UI was a Data Sort View which would allow Residents to view, sort, and manage Landmarks from a column set approach (like iTunes). However, at this time, we have been asked to put that feature on hold since it's real benefit has not been clear for all project stakeholders. When editing a Landmarks, Residents will have the ability to specify a custom name, add their own notes to each Landmark. Residents will also have the ability to specify a picture they want to use for a particular Landmark. Our technical team is also reviewing the possibility of allowing a Resident the option of using/reverting back to the default image for this location (as specified by the Land Owner). It is as of yet undetermined if this feature will be in scope. The Edit Landmarks Floater will include small icons for 'Show on Map' and 'Copy SLURL' to provide additional functionality. Finally, we intend to display additional metadata about the Landmark from the Edit Landmark floater - date acquired, last teleport date, and last updated date. Shared Landmarks & Tagging One of our original ideas (and a common suggestion from Residents) has been to include tagging of Landmarks and other Inventory assets. We investigated a couple of ways to create a folksonomy use with Landmarks in Second Life during the first phase of our project. However, it became clear that tagging functionality would be useful for many other areas and could touch many other areas including search, the web, User Picks, and most Inventory items. Rather than build a small one-off tagging system just for Landmarks, it was decided that creating a true folksonomy that could be used throughout Second Life (For searching, sharing landmarks, creating more a social network, etc.) was a much bigger project than our timeline or project goals would allow for. So tagging functionality was deemed out of scope for this project. Where we're going! Issues, Risks, Reviews, and Builds! The design team is working closely with Linden Lab and soliciting Resident feedback on new designs revisions. We hope to have design approachs for the new Nav bar solidifed by the end of this week. In the meantime, our technical team have been working on laying the foundation for the new Navigation bar, as well as spending time researching the items which many of you have spoken about on this list. A few items for which we're actively researching: * Understanding more about SLURLs and their relation to the Agni grid and how they come into play with the beta grid(s). * How the introduction of a new top-left UI element will affect Resident-created HUDs. * How the introduction of forward/back button teleport functionality will affect grid stability.In addition to researching open issues, our tech team is also working on wrapping up a Viewer build (minus approved creative). We will be testing that and reviewing it with Linden Lab over the next week. I would encourage all of you to continue sharing your thoughts and feedback. As I stated at the beginning of this message, the Vectorform team will be much more actively engaged with this list moving forward. Best, Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/487b236b/attachment-0001.htm From dahliatrimble at gmail.com Thu Jun 5 09:01:40 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Jun 5 09:01:43 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: Does (or could) the puppeteering code implement inverse kinematics? On Thu, Jun 5, 2008 at 4:19 AM, Argent Stonecutter wrote: > On 2008-06-04, at 23:53, Brandon Lockaby wrote: > >> Assuming LL doesn't write a simulator for you, might I suggest the >> possiblity of using slproxy to emulate the server-side behaviors? :D >> > > I'm not sure how SLProxy would help... the important bit would be scripted. > > llTrackPrim(integer joint, key prim, integer distance, integer strictness, > integer follow_rotation); > > While prim is in range of motion of joint, joint is constrained to remain > in distance meters of the center of prim. Strictness indicates how quickly > it would track the prim, and follow_rotation whether it should try and > rotate the joint to match the angle of the prim. > > It would apply to the owner or the avatar for which the script has > appropriate permissions. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/7a8ca6fb/attachment.htm From tateru.nino at gmail.com Thu Jun 5 09:04:31 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 09:05:15 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <328748.69828.qm@web59112.mail.re1.yahoo.com> References: <328748.69828.qm@web59112.mail.re1.yahoo.com> Message-ID: <48480E8F.2040805@weblogsinc.com> I thought they /were/ a contracted team. Ann Otoole wrote: > I previously requested someone look into how this project can impact > search and there were no replies so I will reiterate: > > Profile Picks are part of the new search relevancy. Messing with this > breaks search. An external non LL contracted team cannot be allowed to > work on things that will result in devastation of the economy. How > this can even happen is interesting. Great work and all but who > decided to allow you to potentially erase the SL economy? > > Landmarks were initially listed in the SL blog as being a search > relevance factor. The entire discussion of removing landmarks should > have never happened without a discussion of this factor first. > > My recommendation is for the LL search related team to pay more > attention to protecting their turf and communicating with this > community to ensure everyone understands how this work will or will > not impact the new search. > > > ----- Original Message ---- > From: Sarah Hutchinson > To: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:37:46 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking > into consideration all of your input. We're excited that there has > been so much interest in this project! Working on an open source > project is a great learning experience for us, so we've been careful > to respond with accuracy. Now we'll work on responding with a little > more speed. As we have begun to define the design and functionality, > we're better positioned to understand and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where > we've been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed > Office Hours discussions, interviews with Residents (both new and > veteran), scouring Second Life blogs, researching resident-created > tools, reviewing other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate > in-world and how they create, use, and manage Landmarks. We solicited > feedback on their pain points, ideas, and general comments that > touched on Inventory, Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden > Lab as well as some initial mockups and wireframes that would satisfy > some of the project goals (as stated on the WIKI) as: > > * > > *To create a history of locations visited*, presented in some > visual fashion, which may include: > > o > > Back & forward buttons for teleporting through location > history > > o > > Prominent on-screen affordance for accessing/adding Landmarks > > * > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > > o > > Sorting, re-ordering > > o > > Organizing into folders or similar > > o > > Renaming > > o > > Sharing > > o > > Tagging > > * > > *To create a new navigation panel* (ie. the visual container for > the new UI components) > > o > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > > 2. > > Deprecating Picks or finding some way to make sharing Landmarks > easier. > > Discussions with Residents quickly removed these two items from the > scope of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing > from to do from an implementation perspective. It also means that one > of our project requirements - that of backwards compatibility - was > broken. So it was determined that Landmarks were best left a part of > the Inventory. As noted, there are many ways a Landmark can end up in > one's Inventory, and the pros of Landmarks being left where they are, > very quickly outweighed any cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved > into, that it should be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on > wireframes and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden > Lab, we are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and > history buttons, as well as an address/location text box and > 'go' button. > > The designs are being revised and updated to fit more into the > new Dazzle style with insight and feedback from Residents and > Lindens. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > In between the back and forward buttons will be a small, history > button which will allow a Resident to view the list of places > he/she has visited during that session. The number of places > stored in this history and whether it persists between sessions > can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional > info (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport > the Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to > his/her home location. > > Address Bar - The address bar will display a SLURL by default. > Users can enter a SLURL, or Region name in their Inventory. If > the Resident types in a Region name that is not in their > Inventory, we will go a global search to find the location. If > the location cannot be found, the Search floater will open. > > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater > that will providing users the ability to: > > * > > Set the number of days to store location history > > * > > Set the number of days to store address bar history > > * > > Clear the history of either of the above two items > > * > > Export Landmarks in HTML, TXT, or XML formats > > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes > when creating or editing a Landmark. There will also be the > option to select or create a folder when creating/editing > Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will > still apply: > > * > > Landmarks received from purchased objects will remain with > the object/folder as they are created. > > * > > Landmarks received view Inventory transfer will be placed > into a Received Landmarks folder by default, but also > allow for the Resident to edit and select a folder in > which to place the Landmark. > > * > > Landmarks received via automatic givers will also be > placed into the Received Landmarks folder, by default. > Still TBD in terms of scoping, but we'd also like to > include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > > * > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the > Notecard and not accessible except through Notecard access. > > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the > Viewer. The options for this menu are as follows: > > * > > Create Landmark > > * > > Manage Landmarks > > * > > Set Home to Current Location > > * > > Teleport Home > > * > > Received Landmarks - A sub-folder in the Landmarks folder > in Inventory where all received Landmarks are stored by > default. > > * > > Recent Places - Displays a list of Landmarks a Resident > has recented used. > > * > > Access to Landmarks located in the Inventory Floater - > Residents will now have access to Landmarks stored in the > Landmarks folder of their Inventory via this menu. Any > sub-folders of the main Landmarks folder will appear in > this Landmarks menu and be navigable via this menu. > > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via > of the Inventory, in which to organize and manage (edit/delete) > Landmarks. It consists of a small floater which will almost look > like a filter viewed of the Inventory Floater. The Manage > Landmarks floater will allow Residents to filter Landmarks, > create/edit/delete folders easily, and provide a place (without > having to weed through the rest of the Inventory) to edit Landmarks. > > If you've had a chance to look at the wireframe posted on > NAV-28, there are two approaches to the Manage Landmarks UI. At > present, we have been asked to proceed with the separated > floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI > was a Data Sort View which would allow Residents to view, sort, > and manage Landmarks from a column set approach (like iTunes > ). However, at this time, we have > been asked to put that feature on hold since it's real benefit > has not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to > specify a custom name, add their own notes to each Landmark. > Residents will also have the ability to specify a picture they > want to use for a particular Landmark. Our technical team is > also reviewing the possibility of allowing a Resident the option > of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined > if this feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on > Map' and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the > Landmark from the Edit Landmark floater - date acquired, last > teleport date, and last updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) > has been to include tagging of Landmarks and other Inventory assets. > We investigated a couple of ways to create a folksonomy use with > Landmarks in Second Life during the first phase of our project. > However, it became clear that tagging functionality would be useful > for many other areas and could touch many other areas including > search, the web, User Picks, and most Inventory items. Rather than > build a small one-off tagging system just for Landmarks, it was > decided that creating a true folksonomy that could be used throughout > Second Life (For searching, sharing landmarks, creating more a social > network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of > scope for this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting > Resident feedback on new designs revisions. We hope to have design > approachs for the new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time > researching the items which many of you have spoken about on this > list. A few items for which we're actively researching: > > * > > Understanding more about SLURLs and their relation to the Agni > grid and how they come into play with the beta grid(s). > > * > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > > * > > How the introduction of forward/back button teleport > functionality will affect grid stability. > > In addition to researching open issues, our tech team is also working > on wrapping up a Viewer build (minus approved creative). We will be > testing that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform > team will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From evolutie at gmail.com Thu Jun 5 09:08:15 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 09:08:17 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> yes, that's what it does! this is so great! the UI actually works quite well, I think. But script functions would be very nice.. really would love to connect a mocap suit to it... chrz, evo On Thu, Jun 5, 2008 at 6:01 PM, Dahlia Trimble wrote: > Does (or could) the puppeteering code implement inverse kinematics? > > > On Thu, Jun 5, 2008 at 4:19 AM, Argent Stonecutter > wrote: >> >> On 2008-06-04, at 23:53, Brandon Lockaby wrote: >>> >>> Assuming LL doesn't write a simulator for you, might I suggest the >>> possiblity of using slproxy to emulate the server-side behaviors? :D >> >> I'm not sure how SLProxy would help... the important bit would be >> scripted. >> >> llTrackPrim(integer joint, key prim, integer distance, integer strictness, >> integer follow_rotation); >> >> While prim is in range of motion of joint, joint is constrained to remain >> in distance meters of the center of prim. Strictness indicates how quickly >> it would track the prim, and follow_rotation whether it should try and >> rotate the joint to match the angle of the prim. >> >> It would apply to the owner or the avatar for which the script has >> appropriate permissions. >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- http://www.creativemachinery.org From sean at lindenlab.com Thu Jun 5 09:09:13 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 09:09:15 2008 Subject: [sldev] Voice moderation and morphing; was: Voice moderation and morphing; was: [sldev] Puppettering Branch In-Reply-To: <507402.50528.qm@web59108.mail.re1.yahoo.com> References: <507402.50528.qm@web59108.mail.re1.yahoo.com> Message-ID: <3736d47a0806050909g2e270206mb1410576f11a83ad@mail.gmail.com> The reason [sldev] wasn't at the beginning of the subject is that mailman checks to see if [sldev] exists *anywhere* in the subject to make sure it doesn't have [sldev] more than once. You should be looking for [sldev] anywhere in the subject rather than just at the beginning. As it is, replies will regularly end up as Re: [sldev] blah blah blah. On Thu, Jun 5, 2008 at 8:41 AM, Ann Otoole wrote: > Please put [sldev] as a prefix so these messages won't so easily be flagged > and deleted as spam. > > Thanks. > > ----- Original Message ---- > From: Mike Monkowski > To: Jake Simpson > Cc: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:35:59 AM > Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch > > Was voice moderation and morphing another of the projects that was > dropped? (I did see the puppet master's name in the voice code ;-) ) > If so, can we have the code for that too? If not, when do you think we > might see it? > > Mike > > Jake Simpson wrote: > > Puppeteering is a project that we had going last year that we dropped in > > order to focus on stability issues. Note, at the time this was a pretty > > contentious move, some internal people were fairly upset about it (one > > even quit over it) but it was deemed necessary for focus on stability to > > be the main issue. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/d698bc74/attachment-0001.htm From missannotoole at yahoo.com Thu Jun 5 09:11:52 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 09:11:56 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <193533.8360.qm@web59104.mail.re1.yahoo.com> My point is simple. This work can impact search and the impact on search needs to be explained. Or if it is going to negatively impact something then why use time discussing things that will not be allowed to happen? More communication is needed. And how this effort can enhance search would be a great thing. (I.e.; I suspect everything is converted to html urls for google appliance indexing anyway so how can this new navigation work help? will the history of teleports finally be counted as a form of real traffic into and out of a sim? etc. etc.) Don't confuse emotionless straight direct talk with negativism. Thanks. ----- Original Message ---- From: Drew Dwi To: Ann Otoole Cc: Sarah Hutchinson ; sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:54:52 AM Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Hi, Hate to poke my head in, but careful reading is required before harsh feedback. Per Kippie's post (you don't get your own email? the name says Sarah fyi): "With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is." I don't see how any of the changes listed below affect search. -Drew Ann Otoole wrote: > I previously requested someone look into how this project can impact > search and there were no replies so I will reiterate: > > Profile Picks are part of the new search relevancy. Messing with this > breaks search. An external non LL contracted team cannot be allowed to > work on things that will result in devastation of the economy. How > this can even happen is interesting. Great work and all but who > decided to allow you to potentially erase the SL economy? > > Landmarks were initially listed in the SL blog as being a search > relevance factor. The entire discussion of removing landmarks should > have never happened without a discussion of this factor first. > > My recommendation is for the LL search related team to pay more > attention to protecting their turf and communicating with this > community to ensure everyone understands how this work will or will > not impact the new search. > > > ----- Original Message ---- > From: Sarah Hutchinson > To: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:37:46 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking > into consideration all of your input. We're excited that there has > been so much interest in this project! Working on an open source > project is a great learning experience for us, so we've been careful > to respond with accuracy. Now we'll work on responding with a little > more speed. As we have begun to define the design and functionality, > we're better positioned to understand and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where > we've been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed > Office Hours discussions, interviews with Residents (both new and > veteran), scouring Second Life blogs, researching resident-created > tools, reviewing other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate > in-world and how they create, use, and manage Landmarks. We solicited > feedback on their pain points, ideas, and general comments that > touched on Inventory, Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden > Lab as well as some initial mockups and wireframes that would satisfy > some of the project goals (as stated on the WIKI) as: > > * > > *To create a history of locations visited*, presented in some > visual fashion, which may include: > > o > > Back & forward buttons for teleporting through location > history > > o > > Prominent on-screen affordance for accessing/adding Landmarks > > * > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > > o > > Sorting, re-ordering > > o > > Organizing into folders or similar > > o > > Renaming > > o > > Sharing > > o > > Tagging > > * > > *To create a new navigation panel* (ie. the visual container for > the new UI components) > > o > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > > 2. > > Deprecating Picks or finding some way to make sharing Landmarks > easier. > > Discussions with Residents quickly removed these two items from the > scope of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing > from to do from an implementation perspective. It also means that one > of our project requirements - that of backwards compatibility - was > broken. So it was determined that Landmarks were best left a part of > the Inventory. As noted, there are many ways a Landmark can end up in > one's Inventory, and the pros of Landmarks being left where they are, > very quickly outweighed any cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved > into, that it should be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on > wireframes and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden > Lab, we are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and > history buttons, as well as an address/location text box and > 'go' button. > > The designs are being revised and updated to fit more into the > new Dazzle style with insight and feedback from Residents and > Lindens. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > In between the back and forward buttons will be a small, history > button which will allow a Resident to view the list of places > he/she has visited during that session. The number of places > stored in this history and whether it persists between sessions > can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional > info (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport > the Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to > his/her home location. > > Address Bar - The address bar will display a SLURL by default. > Users can enter a SLURL, or Region name in their Inventory. If > the Resident types in a Region name that is not in their > Inventory, we will go a global search to find the location. If > the location cannot be found, the Search floater will open. > > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater > that will providing users the ability to: > > * > > Set the number of days to store location history > > * > > Set the number of days to store address bar history > > * > > Clear the history of either of the above two items > > * > > Export Landmarks in HTML, TXT, or XML formats > > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes > when creating or editing a Landmark. There will also be the > option to select or create a folder when creating/editing > Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will > still apply: > > * > > Landmarks received from purchased objects will remain with > the object/folder as they are created. > > * > > Landmarks received view Inventory transfer will be placed > into a Received Landmarks folder by default, but also > allow for the Resident to edit and select a folder in > which to place the Landmark. > > * > > Landmarks received via automatic givers will also be > placed into the Received Landmarks folder, by default. > Still TBD in terms of scoping, but we'd also like to > include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > > * > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the > Notecard and not accessible except through Notecard access. > > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the > Viewer. The options for this menu are as follows: > > * > > Create Landmark > > * > > Manage Landmarks > > * > > Set Home to Current Location > > * > > Teleport Home > > * > > Received Landmarks - A sub-folder in the Landmarks folder > in Inventory where all received Landmarks are stored by > default. > > * > > Recent Places - Displays a list of Landmarks a Resident > has recented used. > > * > > Access to Landmarks located in the Inventory Floater - > Residents will now have access to Landmarks stored in the > Landmarks folder of their Inventory via this menu. Any > sub-folders of the main Landmarks folder will appear in > this Landmarks menu and be navigable via this menu. > > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via > of the Inventory, in which to organize and manage (edit/delete) > Landmarks. It consists of a small floater which will almost look > like a filter viewed of the Inventory Floater. The Manage > Landmarks floater will allow Residents to filter Landmarks, > create/edit/delete folders easily, and provide a place (without > having to weed through the rest of the Inventory) to edit Landmarks. > > If you've had a chance to look at the wireframe posted on > NAV-28, there are two approaches to the Manage Landmarks UI. At > present, we have been asked to proceed with the separated > floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI > was a Data Sort View which would allow Residents to view, sort, > and manage Landmarks from a column set approach (like iTunes > ). However, at this time, we have > been asked to put that feature on hold since it's real benefit > has not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to > specify a custom name, add their own notes to each Landmark. > Residents will also have the ability to specify a picture they > want to use for a particular Landmark. Our technical team is > also reviewing the possibility of allowing a Resident the option > of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined > if this feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on > Map' and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the > Landmark from the Edit Landmark floater - date acquired, last > teleport date, and last updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) > has been to include tagging of Landmarks and other Inventory assets. > We investigated a couple of ways to create a folksonomy use with > Landmarks in Second Life during the first phase of our project. > However, it became clear that tagging functionality would be useful > for many other areas and could touch many other areas including > search, the web, User Picks, and most Inventory items. Rather than > build a small one-off tagging system just for Landmarks, it was > decided that creating a true folksonomy that could be used throughout > Second Life (For searching, sharing landmarks, creating more a social > network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of > scope for this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting > Resident feedback on new designs revisions. We hope to have design > approachs for the new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time > researching the items which many of you have spoken about on this > list. A few items for which we're actively researching: > > * > > Understanding more about SLURLs and their relation to the Agni > grid and how they come into play with the beta grid(s). > > * > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > > * > > How the introduction of forward/back button teleport > functionality will affect grid stability. > > In addition to researching open issues, our tech team is also working > on wrapping up a Viewer build (minus approved creative). We will be > testing that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform > team will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/968d705d/attachment-0001.htm From sean at lindenlab.com Thu Jun 5 09:16:12 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 09:16:15 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> For development purposes, why not just hold all the state in the viewer and send the state to other viewers in the region via some message that's routed directly to other viewers? Just be careful with this, since you should assume any such messages are from untrusted sources. On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby wrote: > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D > > > On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter < > secret.argent@gmail.com> wrote: > >> Anyway, to cut a long story short we (myself and Robla) thought about it >>> and said "Well, if they can't, maybe the SLDev crew can do something with >>> this" and with that we decided to publish the code to you guys. >>> >> >> What I'd like to do with this would require server-side access. >> >> I don't want to drag my hand with my mouse, I want to tell my hand "track >> this prim". >> >> And I want to do it from a script. >> >> Why? Well, how about so I can walk along holding someone's hand, because >> they're wearing the prim I'm tracking... not because we're both riding a >> vehicle that's animating walks for both of us. >> >> So when I'm riding a vehicle, it can make my hands hold onto the >> handlebars, without my having to change the animation based on the avatar >> size. >> >> Automated puppetteering. >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/b47cd258/attachment.htm From tateru.nino at gmail.com Thu Jun 5 09:18:00 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 09:18:42 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> Message-ID: <484811B8.1070308@gmail.com> Most viewers would be behind either firewalls or NAT layers, I should think - that would seem to preclude peer-to-peer communications in most cases, unless the receiver is competent and able to allow it. Sean Lynch wrote: > For development purposes, why not just hold all the state in the > viewer and send the state to other viewers in the region via some > message that's routed directly to other viewers? Just be careful with > this, since you should assume any such messages are from untrusted > sources. > > On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby > wrote: > > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D > > > On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter > > wrote: > > Anyway, to cut a long story short we (myself and Robla) > thought about it and said "Well, if they can't, maybe the > SLDev crew can do something with this" and with that we > decided to publish the code to you guys. > > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my > hand "track this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's > hand, because they're wearing the prim I'm tracking... not > because we're both riding a vehicle that's animating walks for > both of us. > > So when I'm riding a vehicle, it can make my hands hold onto > the handlebars, without my having to change the animation > based on the avatar size. > > Automated puppetteering. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From monkowsk at watson.ibm.com Thu Jun 5 08:11:19 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 09:33:08 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <48480217.8080107@watson.ibm.com> Jake Simpson wrote: > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this > code - basically we've given it to them, said "see if you can make > something compelling with it, and if you can, we may reconsider > finishing up the simulator code and pushing it through". Will this parther code become part of the open source distribution or is it being done under a different license agreement? > Anyway, to cut a long story short we (myself and Robla) thought about it > and said "Well, if they can't, maybe the SLDev crew can do something > with this" and with that we decided to publish the code to you guys. I don't imagine you'd have any documentation. Would you? > The code itself is somewhat complete - there are definitely some things > we would do differently and there are still definitely bugs in there, > but right now it's pretty unlikely that we will return to this to > complete it or refactor that which we would want to change with the code > and intent as it stands. What are the "some things we would do differently"? How would you want to refactor it? Mike From evolutie at gmail.com Thu Jun 5 09:38:28 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 09:38:31 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48480217.8080107@watson.ibm.com> References: <48473027.9090101@lindenlab.com> <48480217.8080107@watson.ibm.com> Message-ID: <5fb4b1fa0806050938x5cd21714ib2703d9c5455c23c@mail.gmail.com> this should be helpful for some of the documentation part... http://avatarpuppeteering.com/ chrz, evo On Thu, Jun 5, 2008 at 5:11 PM, Mike Monkowski wrote: > Jake Simpson wrote: >> >> Now we recently resurrected this code and have distributed it to various >> partners who have items in the works that might well end up using this code >> - basically we've given it to them, said "see if you can make something >> compelling with it, and if you can, we may reconsider finishing up the >> simulator code and pushing it through". > > Will this parther code become part of the open source distribution or is it > being done under a different license agreement? > >> Anyway, to cut a long story short we (myself and Robla) thought about it >> and said "Well, if they can't, maybe the SLDev crew can do something with >> this" and with that we decided to publish the code to you guys. > > I don't imagine you'd have any documentation. Would you? > >> The code itself is somewhat complete - there are definitely some things we >> would do differently and there are still definitely bugs in there, but right >> now it's pretty unlikely that we will return to this to complete it or >> refactor that which we would want to change with the code and intent as it >> stands. > > What are the "some things we would do differently"? How would you want to > refactor it? > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- http://www.creativemachinery.org From cenji.neutra at gmail.com Thu Jun 5 10:01:27 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Thu Jun 5 10:01:30 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 Message-ID: Thanks for the good overview Sarah. Just wanted to chime in to mention that the SL client is increasingly being used to login to 3rd-party grids in addition to SL - a trend that will continue to gain momentum, especially with work underway to make user selection of which 'grid' to connect to part of the UI (see VWR-7531 for example). While currently an avatar's identity and inventory (i.e. landmarks) and the grid they're logged into are tied together, in the new Architecture LL & the AWG is proposing, they are not (see http://wiki.secondlife.com/wiki/AWG). So it will be possible in future for an avatar (belonging to a particular 'agent domain') to login to a number of independent 'grids' (e.g. region domains). That obviously has implications for landmarks, since the landmark information would need to be associated with the region domain in which it was created. For example, if I created a landmark in SL to a region named "Island1" and then quit and reconnected to a different agent domain - say osgrid.org or centralgrid.com - *with my SL avatar and inventory* (which isn't yet technically possible, but will be), then when I select that landmark and click 'teleport' I would expect the SL client to know it isn't a location in the grid I'm currently in (even if that grid also has a region named "Island1".). Perhaps it should display an error, or maybe even re-connect me to SL to TP there. Just wanted this to be 'on your radar' so perhaps you can build-in appropriate 'grid identifiers' into your data design which will aid the transition to the new agent/region domain architecture in the future. Regards. -Cenji. From lenglish5 at cox.net Thu Jun 5 10:06:58 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:07:01 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> Message-ID: <48481D32.40604@cox.net> Dante Tucker wrote: > Aha, I got it nevermind. Though the interface is less then usable I > managed to get a feel for it. Only problem is the second you interact > with your characters skeleton it goes into crazy convulsions. > For the fun of it I have attached an image of two views of the > convulsions and one view of my attempt to put my avatar into a decent > standing pose. I think a mouse-only interface is not really an option. However, I could see this being used with suitable controls, as an in-viewer animation generator. With scripting, you could add custom animations in near-realtime. With suitable interfaces (and not just dual Wii controllers or 3D webcams, but hot keys, voice control MIDI keyboard, etc) you could certainly have realtime animation. Lawson From lenglish5 at cox.net Thu Jun 5 10:18:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:18:07 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> Message-ID: <48481FCC.2050408@cox.net> evolutie wrote: > yes, that's what it does! > this is so great! > the UI actually works quite well, I think. > But script functions would be very nice.. > > really would love to connect a mocap suit to it... > Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam controller for SL. I imagine his people have a copy to work with since his stuff is really prmitive mocap and the camera's resolution scales with extra modules added. Lawson From danteferret at gmail.com Thu Jun 5 10:18:42 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 5 10:18:44 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481D32.40604@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> Message-ID: <4d211a610806051018o4492f2dfwa1b69be91e91be47@mail.gmail.com> Unfortunately I think the biggest downside of all the tools in sl at the moment is the lack of multiple views. Compare this to other programs that have multiple views from different angles at the same time. On Thu, Jun 5, 2008 at 1:06 PM, Lawson English wrote: > Dante Tucker wrote: > >> Aha, I got it nevermind. Though the interface is less then usable I >> managed to get a feel for it. Only problem is the second you interact with >> your characters skeleton it goes into crazy convulsions. >> For the fun of it I have attached an image of two views of the convulsions >> and one view of my attempt to put my avatar into a decent standing pose. >> > I think a mouse-only interface is not really an option. However, I could > see this being used with suitable controls, as an in-viewer animation > generator. With scripting, you could add custom animations in near-realtime. > With suitable interfaces (and not just dual Wii controllers or 3D webcams, > but hot keys, voice control MIDI keyboard, etc) you could certainly have > realtime animation. > > > Lawson > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/59f59ba8/attachment-0001.htm From lenglish5 at cox.net Thu Jun 5 10:20:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:20:45 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484811B8.1070308@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> Message-ID: <4848206A.4030804@cox.net> Tateru Nino wrote: > Most viewers would be behind either firewalls or NAT layers, I should > think - that would seem to preclude peer-to-peer communications in > most cases, unless the receiver is competent and able to allow it. Reverese http allows P2P for anyone if they want to bother with it. Lawson From lenglish5 at cox.net Thu Jun 5 10:19:48 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:31:28 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> Message-ID: <48482034.7030802@cox.net> Sean Lynch wrote: > For development purposes, why not just hold all the state in the > viewer and send the state to other viewers in the region via some > message that's routed directly to other viewers? Just be careful with > this, since you should assume any such messages are from untrusted > sources. > No provision in he LL design for P2P. AWG has discussed adding a protocol to announce that P2P is available in a given region domain (grid), but its not high on anyone's list. Lawson From sldev at bitparts.org Thu Jun 5 11:28:26 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Thu Jun 5 11:28:42 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <4848304A.1080402@bitparts.org> Sarah Hutchinson wrote: > > 1. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > So, minor thing compared with the whole "why bother" question - "/" will currently open the local chat entry line if it is closed. So, yeah - might want to double-check the work of whoever decided it wasn't in use already. From sarah77 at gmail.com Thu Jun 5 11:57:07 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Thu Jun 5 11:57:08 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4848304A.1080402@bitparts.org> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <4848304A.1080402@bitparts.org> Message-ID: <9010c35c0806051157m239ca5cbjfa6598d1471897bd@mail.gmail.com> My apologies. That was a typo on my part. The character should be "\". Unless I am mistaken, it is not currently in use for another Viewer shortcuts. Thanks for catching that! Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/51c24fc5/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 12:03:40 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 12:03:44 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: Message-ID: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Hi Cenji, I'll make sure our technical team is aware of this. I'm not as familiar with how the Viewer is used for other grids. I'll take a look at VWR-7531 right now and the sites you referenced. Thanks, Kippie On Thu, Jun 5, 2008 at 1:01 PM, Cenji Neutra wrote: > Thanks for the good overview Sarah. > Just wanted to chime in to mention that the SL client is increasingly > being used to login to 3rd-party grids in addition to SL - a trend > that will continue to gain momentum, especially with work underway to > make user selection of which 'grid' to connect to part of the UI (see > VWR-7531 for example). > > While currently an avatar's identity and inventory (i.e. landmarks) > and the grid they're logged into are tied together, in the new > Architecture LL & the AWG is proposing, they are not (see > http://wiki.secondlife.com/wiki/AWG). So it will be possible in > future for an avatar (belonging to a particular 'agent domain') to > login to a number of independent 'grids' (e.g. region domains). > > That obviously has implications for landmarks, since the landmark > information would need to be associated with the region domain in > which it was created. For example, if I created a landmark in SL to a > region named "Island1" and then quit and reconnected to a different > agent domain - say osgrid.org or centralgrid.com - *with my SL avatar > and inventory* (which isn't yet technically possible, but will be), > then when I select that landmark and click 'teleport' I would expect > the SL client to know it isn't a location in the grid I'm currently in > (even if that grid also has a region named "Island1".). Perhaps it > should display an error, or maybe even re-connect me to SL to TP > there. > > Just wanted this to be 'on your radar' so perhaps you can build-in > appropriate 'grid identifiers' into your data design which will aid > the transition to the new agent/region domain architecture in the > future. > Regards. > -Cenji. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/12e78675/attachment.htm From labrat.hb at gmail.com Thu Jun 5 12:37:27 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jun 5 12:37:30 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Message-ID: I'm not sure I like this item: > 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Picks have become much more then a "Hey I like this place come take a look. They are a social bookmark, used to show more information about who and what residents find, think and believe about the Second Life world. I would hate to lose this non-landmark / navigation functionality because the "Picks" were being deprecated. From evolutie at gmail.com Thu Jun 5 12:46:29 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 12:46:32 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481FCC.2050408@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> <48481FCC.2050408@cox.net> Message-ID: <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> > Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam > controller for SL. I imagine his people have a copy to work with since his > stuff is really prmitive mocap and the camera's resolution scales with extra > modules added. > > > Lawson > > oh! that sounds very interesting! Do you know where I could get more information on this? thnx, evo -- http://www.creativemachinery.org From kelly at lindenlab.com Thu Jun 5 12:47:31 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Thu Jun 5 12:47:34 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Message-ID: <484842D3.6000406@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/5ef08d2d/attachment.htm From labrat.hb at gmail.com Thu Jun 5 12:53:55 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jun 5 12:53:57 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <484842D3.6000406@lindenlab.com> References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> <484842D3.6000406@lindenlab.com> Message-ID: I caught that after I pressed send. *sweeps the previous reply under the rug and stomps it down nice and flat* On Thu, Jun 5, 2008 at 12:47 PM, Kelly Linden wrote: > > Please! Read what you reply to! The above quote, in context reads: From monkowsk at watson.ibm.com Thu Jun 5 12:34:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 13:00:00 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481D32.40604@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> Message-ID: <48483FBE.8070206@watson.ibm.com> Here's an idea. The problem I see with gestures is that they have a fixed time sequence. They play exactly the same way every time. Not very cinematic. Now suppose there was a HUD that had at its disposal the puppeteering equivalents of these gestures and a way to gang them together (master - slave controls) so that you could select a gesture or gang of gestures and use the mouse to move a slider as if it were scrubbing the timeline for the animation. So, for example, if I had a hand-waving animation I could wave a little very slowly "Yes, I'm a princess." by slowly scrubbing the middle of the timeline or I could give a vigorous "Hey I'm over here! Pick me!" wave by scrubbing the entire timeline quickly. You'd have to plan ahead and gang gestures appropriately since you can only control one timeline, but switching between gestures might not be too difficult. Putting this in a HUD would mean that a lot of customization could be done quickly. But, I've never built a HUD in SL, so I really don't know how much is possible. Mike Lawson English wrote: > I think a mouse-only interface is not really an option. However, I could > see this being used with suitable controls, as an in-viewer animation > generator. With scripting, you could add custom animations in > near-realtime. With suitable interfaces (and not just dual Wii > controllers or 3D webcams, but hot keys, voice control MIDI keyboard, > etc) you could certainly have realtime animation. From lenglish5 at cox.net Thu Jun 5 13:36:51 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 13:36:53 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> <48481FCC.2050408@cox.net> <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> Message-ID: <48484E63.6050304@cox.net> evolutie wrote: >> Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam >> controller for SL. I imagine his people have a copy to work with since his >> stuff is really prmitive mocap and the camera's resolution scales with extra >> modules added. >> >> >> Lawson >> >> >> > > oh! that sounds very interesting! > Do you know where I could get more information on this? > > Oops. Mitch Kapor, not Kaplan. http://news.cnet.com/8301-10784_3-9916946-7.html Lawson From gbrandon at gmail.com Thu Jun 5 14:05:18 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Jun 5 14:05:21 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: Would one be able to look through the location history and decide to bookmark any of the items? Also I want to put in a few words about back & forward buttons: remember, Second Life has teleport problems and much like the web you don't always know where the back button is going to take you. Can you imagine hitting the back button rapidly trying to find something? So, with a web browser, you have something like drop-down box buttons next to those back and forward buttons showing a quick history you can choose from, that comes in handy. Oh! What's the internal opinion on having the widget in the menu bar instead of a floater? Thanks, Brandon Lockaby On Thu, Jun 5, 2008 at 11:37 AM, Sarah Hutchinson wrote: > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking into > consideration all of your input. We're excited that there has been so much > interest in this project! Working on an open source project is a great > learning experience for us, so we've been careful to respond with accuracy. > Now we'll work on responding with a little more speed. As we have begun to > define the design and functionality, we're better positioned to understand > and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where we've > been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed Office > Hours discussions, interviews with Residents (both new and veteran), > scouring Second Life blogs, researching resident-created tools, reviewing > other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate in-world > and how they create, use, and manage Landmarks. We solicited feedback on > their pain points, ideas, and general comments that touched on Inventory, > Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden Lab > as well as some initial mockups and wireframes that would satisfy some of > the project goals (as stated on the WIKI) as: > > - > > *To create a history of locations visited*, presented in some visual > fashion, which may include: > - > > Back & forward buttons for teleporting through location history > - > > Prominent on-screen affordance for accessing/adding Landmarks > - > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > - > > Sorting, re-ordering > - > > Organizing into folders or similar > - > > Renaming > - > > Sharing > - > > Tagging > - > > *To create a new navigation panel* (ie. the visual container for the > new UI components) > - > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > 2. > > Deprecating Picks or finding some way to make sharing Landmarks easier. > > Discussions with Residents quickly removed these two items from the scope > of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing from > to do from an implementation perspective. It also means that one of our > project requirements - that of backwards compatibility - was broken. So it > was determined that Landmarks were best left a part of the Inventory. As > noted, there are many ways a Landmark can end up in one's Inventory, and the > pros of Landmarks being left where they are, very quickly outweighed any > cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot more > than just sharing of favorite places. It was decided that until Second Life > offer the more social features that Picks have evolved into, that it should > be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on wireframes > and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden Lab, we > are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and history > buttons, as well as an address/location text box and 'go' button. > > The designs are being revised and updated to fit more into the new > Dazzle style with insight and feedback from Residents and Lindens. > > The Navigation Panel can be able to be shown or hidden using both a > small toggle at the top-left of the Viewer as well a keyboard shortcut - > "/". (We are still determining if this will work as a shortcut key, but an > initial review indicated it was not being used by another UI element - so > this is TBD). > > In between the back and forward buttons will be a small, history button > which will allow a Resident to view the list of places he/she has visited > during that session. The number of places stored in this history and whether > it persists between sessions can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional info > (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport the > Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to his/her > home location. > > Address Bar - The address bar will display a SLURL by default. Users > can enter a SLURL, or Region name in their Inventory. If the Resident types > in a Region name that is not in their Inventory, we will go a global search > to find the location. If the location cannot be found, the Search floater > will open. > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater that will > providing users the ability to: > - > > Set the number of days to store location history > - > > Set the number of days to store address bar history > - > > Clear the history of either of the above two items > - > > Export Landmarks in HTML, TXT, or XML formats > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes when > creating or editing a Landmark. There will also be the option to select or > create a folder when creating/editing Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will still > apply: > - > > Landmarks received from purchased objects will remain with the > object/folder as they are created. > - > > Landmarks received view Inventory transfer will be placed into a > Received Landmarks folder by default, but also allow for the Resident to > edit and select a folder in which to place the Landmark. > - > > Landmarks received via automatic givers will also be placed into the > Received Landmarks folder, by default. Still TBD in terms of scoping, but > we'd also like to include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > - > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the Notecard and not > accessible except through Notecard access. > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the Viewer. The > options for this menu are as follows: > - > > Create Landmark > - > > Manage Landmarks > - > > Set Home to Current Location > - > > Teleport Home > - > > Received Landmarks - A sub-folder in the Landmarks folder in > Inventory where all received Landmarks are stored by default. > - > > Recent Places - Displays a list of Landmarks a Resident has recented > used. > - > > Access to Landmarks located in the Inventory Floater - Residents > will now have access to Landmarks stored in the Landmarks folder of their > Inventory via this menu. Any sub-folders of the main Landmarks folder will > appear in this Landmarks menu and be navigable via this menu. > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via of the > Inventory, in which to organize and manage (edit/delete) Landmarks. It > consists of a small floater which will almost look like a filter viewed of > the Inventory Floater. The Manage Landmarks floater will allow Residents to > filter Landmarks, create/edit/delete folders easily, and provide a place > (without having to weed through the rest of the Inventory) to edit > Landmarks. > > If you've had a chance to look at the wireframe posted on NAV-28, there > are two approaches to the Manage Landmarks UI. At present, we have been > asked to proceed with the separated floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI was a > Data Sort View which would allow Residents to view, sort, and manage > Landmarks from a column set approach (like iTunes). However, at this time, > we have been asked to put that feature on hold since it's real benefit has > not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to specify a > custom name, add their own notes to each Landmark. Residents will also have > the ability to specify a picture they want to use for a particular Landmark. > Our technical team is also reviewing the possibility of allowing a Resident > the option of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined if this > feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on Map' > and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the Landmark > from the Edit Landmark floater - date acquired, last teleport date, and last > updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) has > been to include tagging of Landmarks and other Inventory assets. We > investigated a couple of ways to create a folksonomy use with Landmarks in > Second Life during the first phase of our project. However, it became clear > that tagging functionality would be useful for many other areas and could > touch many other areas including search, the web, User Picks, and most > Inventory items. Rather than build a small one-off tagging system just for > Landmarks, it was decided that creating a true folksonomy that could be used > throughout Second Life (For searching, sharing landmarks, creating more a > social network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of scope for > this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting Resident > feedback on new designs revisions. We hope to have design approachs for the > new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time researching > the items which many of you have spoken about on this list. A few items for > which we're actively researching: > > - > > Understanding more about SLURLs and their relation to the Agni grid and > how they come into play with the beta grid(s). > - > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > - > > How the introduction of forward/back button teleport functionality will > affect grid stability. > > In addition to researching open issues, our tech team is also working on > wrapping up a Viewer build (minus approved creative). We will be testing > that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform team > will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/6af6b8fb/attachment-0001.htm From sean at lindenlab.com Thu Jun 5 14:12:06 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 14:12:10 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484811B8.1070308@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> Message-ID: <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> Sorry, I phrased that confusingly. By "routed directly to other viewers" I meant the message is routed by the simulator to any viewers that can see the agent. There are some messages that work this way, but I don't know what they are off the top of my head. On Thu, Jun 5, 2008 at 9:18 AM, Tateru Nino wrote: > Most viewers would be behind either firewalls or NAT layers, I should think > - that would seem to preclude peer-to-peer communications in most cases, > unless the receiver is competent and able to allow it. > > Sean Lynch wrote: > >> For development purposes, why not just hold all the state in the viewer >> and send the state to other viewers in the region via some message that's >> routed directly to other viewers? Just be careful with this, since you >> should assume any such messages are from untrusted sources. >> >> On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby > gbrandon@gmail.com>> wrote: >> >> Assuming LL doesn't write a simulator for you, might I suggest the >> possiblity of using slproxy to emulate the server-side behaviors? :D >> >> >> On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter >> > wrote: >> >> Anyway, to cut a long story short we (myself and Robla) >> thought about it and said "Well, if they can't, maybe the >> SLDev crew can do something with this" and with that we >> decided to publish the code to you guys. >> >> >> What I'd like to do with this would require server-side access. >> >> I don't want to drag my hand with my mouse, I want to tell my >> hand "track this prim". >> >> And I want to do it from a script. >> >> Why? Well, how about so I can walk along holding someone's >> hand, because they're wearing the prim I'm tracking... not >> because we're both riding a vehicle that's animating walks for >> both of us. >> >> So when I'm riding a vehicle, it can make my hands hold onto >> the handlebars, without my having to change the animation >> based on the avatar size. >> >> Automated puppetteering. >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/17f26a06/attachment.htm From sldev at catznip.com Thu Jun 5 14:53:17 2008 From: sldev at catznip.com (Kitty) Date: Thu Jun 5 14:50:42 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com><105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com><48432D25.7020300@lindenlab.com><32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com><7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> >* To create a history of locations visited, presented in some visual fashion I looked through the PDFs and the emails and I only found a reference to "teleport history" so it would seem that the history is populated only from point-to-point teleporting and nothing else? The analogy between SL and a web browser breaks down because you only really have one way of navigating the web which is to click links. In SL that translates to tp'ing, but you can also simply wander around without tp'ing. As an illustrative example: someone hears about the new Bay City sims and decides to go have a look. They use a landmark or the map to teleport over and some time (potentially hours) after that they tp away again. They could find a lot of places they might want to visit again and forgot to landmark - or didn't realize they wanted to visit again - in between those two tp's. Parcel-to-parcel tracking (probably would have to based on a "user definable time spent on that parcel" to avoid clutter) would seem a lot more useful than only tracking tp's. We already have a crude teleport history right now and I don't find it very useful since it offers no history of where I went, only the place I tp'ed away from. The web analogy would be browsing pictures on Flickr and instead of having a history of each picture you looked at, it would just tell you "you looked at the Flickr site" with nothing more specific than that. What I would love as a history would be a trajectory overlayed on a sim map, with points where I stopped for several minutes highlighted as potential reference points. Having only a SLURL to Bliss Gardens isn't that useful for instance since it's a dozen connected sims consisting of sim sized parcels and it would take forever to wander and find what you saw the day before; being able to literally retrace your steps visually would be invaluable in finding things again easily. >Clicking the back or forward button will automatically >teleport the Resident back/forward in their location history. We have a setting that determines whether double clicking a landmark automatically teleports you or whether it pops up a confirmation dialog. I personally like having the confirmation since misclicks do happen. >Address Bar - The address bar will display a SLURL by default. >Users can enter a SLURL, or Region name in their Inventory. Is "region name in inventory" a typo for "landmark name in inventory"? If the browser analogy has to be made, I would expect to be able to type "Shiny Things" there and have it fetch the location from the recent history or landmarks with an auto-complete drop down. --- I'm not sure if I missed it, but where is all the extra metadata stored? --- I don't mean to sound all negative :|. It's obvious a lot of work and effort went into planning this and working all of it out and creating prototypes and it'll undoubtably to useful to some people, but overall the new management UI seems rather complicated and clumsy to me compared to ordering landmarks in inventory which is something that everyone in SL already knows how to do and I hope it's something that can be turned off. From jacek.antonelli at gmail.com Thu Jun 5 14:59:08 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Jun 5 14:59:11 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <105c09f0806051459x21df0821qeaeaaafe212acc9b@mail.gmail.com> On Thu, Jun 5, 2008 at 4:05 PM, Brandon Lockaby wrote: > Would one be able to look through the location history and decide to > bookmark any of the items? Great idea! Maybe have a star icon (like on Twitter) or similar, that you can press to make a landmark out of it (which would put it in the menu and your inventory). > Also I want to put in a few words about back & forward buttons: remember, > Second Life has teleport problems and much like the web you don't always > know where the back button is going to take you. Can you imagine hitting > the back button rapidly trying to find something? So, with a web browser, > you have something like drop-down box buttons next to those back and forward > buttons showing a quick history you can choose from, that comes in handy. _Emphatically_ agreed. Teleports are costly -- they take a long time, they're not easily undo-able, and they can sometimes crash your client! There is a drop-down history planned (a little down arrow button near the back button), but I would argue that a better solution is to have pressing the back button pop up the menu, _not_ automatically teleport. The only cost of popping up the menu is that it takes one extra click to teleport. The cost of automatically teleporting is much higher: it's not hard to imagine accidently teleporting out of an important meeting because you made one stray click. From open at autistici.org Thu Jun 5 15:12:54 2008 From: open at autistici.org (Opensource Obscure) Date: Thu Jun 5 15:12:57 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <807cdf5117351cc6f7bf88c9685ed871@localhost> I can't build this on Linux (Ubuntu 8.04). (I understand this code is unsupported, so please stop me if asking help here about is unappropriate) I managed to work around three errors using these patches: https://jira.secondlife.com/browse/VWR-5414 https://jira.secondlife.com/browse/VWR-5412 https://jira.secondlife.com/browse/VWR-4456 but then I stumbled into LLPhysicalAvatar, and I couldn't find anything on google about it, so I didn't find any patch or PJIRA page. error output follows, slightly longer version here: http://www.pastebin.ca/raw/1039869 In file included from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatartool.h:44, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llvoavatar.h:61, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llfloatercustomize.h:43, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llagent.cpp:73: /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:192: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:193: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:207: error: ISO C++ forbids declaration of 'LLPhysicalAvatar' with no type /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:207: error: expected ';' before '*' token /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:222: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:223: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:229: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:230: error: expected `)' before '*' token cc1plus: warnings being treated as errors /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llsky.h:45: warning: 'NIGHTTIME_ELEVATION_COS' defined but not used scons: *** [/tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llagent.o] Error 1 scons: building terminated because of errors. bye :) Opensource Obscure From jacek.antonelli at gmail.com Thu Jun 5 15:37:44 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Jun 5 15:37:46 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> On Thu, Jun 5, 2008 at 10:37 AM, Sarah Hutchinson wrote: > Address Bar - The address bar will display a SLURL by default. Users can > enter a SLURL, or Region name in their Inventory. Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont (152,166,46)" -- depending on how specific I feel like being. Why force people to type in all that needless boilerplate and punctuation? It would also be really useful to be able to type in a landmark, with name completion, just as it is in the Map floater. Type in "Ben's house" (the name of the landmark in my inventory), press Enter or click Go, and off I go to Ben's house. > If the Resident types in > a Region name that is not in their Inventory, we will go a global search to > find the location. If the location cannot be found, the Search floater will > open. I'm fond of the way Firefox's search bar will make suggestions if you type something in and pause for a little bit. It would be great to have region name suggestions pop up in a similar way, after a delay. (It might be tricky to integrate that with landmark name completion, though.) > Set the number of days to store location history > > Set the number of days to store address bar history Another suggestion: number of locations to store. So, store the last 10, 20, 50, etc. items, rather than days. This could be a number entry with a drop-down box or radio buttons next to it, e.g. "Remember the last [_10_] (_) days (o) items" > Received Landmarks - A sub-folder in the Landmarks folder in Inventory where > all received Landmarks are stored by default. I love this idea. Would especially love to see this generalized into an "Inbox" / "Received" folder for all inventory. I know I'm not alone in this wish. :-D But that is probably outside the scope of the project. From richard at lindenlab.com Thu Jun 5 16:12:48 2008 From: richard at lindenlab.com (Richard Nelson) Date: Thu Jun 5 16:12:50 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C@gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-431F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> Message-ID: On Sat, 31 May 2008 07:14:03 -0700, Argent Stonecutter wrote: > On 2008-05-30, at 09:10, Felix Duesenburg wrote: >> Argent Stonecutter wrote: >>> ... >>> I would rather the texture picker just be a filtered inventory view... >> > >> From what I can see in the source code, that's exactly what it already >> is... not? > > I mean, I want to be able to open the inventory and click on a texture > and have it previewed the way the texture picker does it, without having > to be in the texture picker. > Felix is right, the texture picker uses an embedded inventory panel with the filter rules set to only show textures. If I understand you correctly, you want the preview portion of the texture picker to be part of the inventory window as well. I think you might get something similar with the proposed inventory item thumbnail project. >>> That's why I want the "landmarks" dropdown in the world map to ONLY >>> show landmarks in my "Landmarks" folder. In fact I'd like to select >>> which subfolder of the Landmarks folder the map looks at. That way >>> landmarks in boxes and landmark givers don't clutter up the map view. >> > >> Then why not just preserve the folders as they are, just omitting those >> that don't contain any landmarks. That way you know exactly where to >> look. > > Clutter. When I'm on the map, I'm looking for my favorite landmarks. > I think the first step is to add the concept of selectable root folder(s) to the inventory item filter, which would allow you to only show contents of the specified folders. Once that is done, it would be much easier to show restricted views of your inventory items for special cases like these. > In SL, having the map view only pull down one folder's worth of > bookmarks instead of groveling through the whole inventory looking for > them should have an even bigger effect on improving performance. > There are several operations which require a full inventory search...I don't remember them all. The working assumption right now is that any time you run the client you will need your entire inventory contents in short order. I think we still have some bugs around inventory caching to fix, though. Richard From sarah at aucreativegroup.com Thu Jun 5 16:47:53 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 16:47:55 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> * **On Thu, Jun 5, 2008 at 5:05 PM, Brandon Lockaby wrote: * > > *Would one be able to look through the location history and decide to > bookmark any of the items? > * The ability to bookmark a location history item hasn't been scoped, but that's a cool idea. I've made a note of it and will share it with the team. If it's not a feature than can be integrated in the scope of this project, it's a great feature idea for a future enhancement. > Also I want to put in a few words about back & forward buttons: remember, > Second Life has teleport problems and much like the web you don't always > know where the back button is going to take you. Can you imagine hitting > the back button rapidly trying to find something? So, with a web browser, > you have something like drop-down box buttons next to those back and forward > buttons showing a quick history you can choose from, that comes in handy. > Our implementation of a nav bar also includes a history drop-down just like a web browser. If you take a look in NAV-28, there should be a few designs and wireframes that show this feature. > Oh! What's the internal opinion on having the widget in the menu bar > instead of a floater? > We discussed the idea of integrating the nav bar into the menu bar, but felt it made the menu bar far too cluttered. There's just so much happening in that area of the UI already. As long as you run Second Life in a full screen window on a large monitor, it can work out great - but for those running Second Life on a smaller display or window, it was just too crowded. - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/e9319624/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 16:56:34 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 16:56:36 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> Message-ID: <9010c35c0806051656i46f403e9p10a81a1f839caf05@mail.gmail.com> On Thu, Jun 5, 2008 at 5:53 PM, Kitty wrote: > so it would seem that the history is populated only from > point-to-point teleporting and nothing else? > ... > Parcel-to-parcel tracking (probably would have to based on a "user > definable > time spent on that parcel" to avoid clutter) would seem a lot more useful > than only tracking tp's. This is great feedback. Due to time constraints in our specific project, the baseline functionality to be introduced is teleport history. However, the team is actively investigating a better heuristic for how the history is populated. In the research phase of the project, we talked with Residents about the qualifications for an item being added to history - and it seems to boil down down time spent within a given Parcel. I completely agree that this would make the history feature a lot more useful. I know the Development team at Vectorform is continuing to investigate the feasibility of this functionality and once I have more information, I'll certainly pass it along. > What I would love as a history would be a trajectory overlayed on a sim > map, > with points where I stopped for several minutes highlighted as potential > reference points. Great idea! I'll note this as a future enhancement idea. It ties into another idea we discussed which is that of a travelogue where you can record information about your travels in Second Life and post that information on the web. Being able to see a map overlay would be awesome. > We have a setting that determines whether double clicking a landmark > automatically teleports you or whether it pops up a confirmation dialog. I > personally like having the confirmation since misclicks do happen. I've made a note of this and will bring it up during our next status. It seems that a confirmation that the first time (that you may dismiss if you wish) is a very good idea in this case. > If the browser analogy has to be made, I would expect to be able to type > "Shiny Things" there and have it fetch the location from the recent history > or landmarks with an auto-complete drop down. > --- > I'm not sure if I missed it, but where is all the extra metadata stored? > I'll check in with the team on the auto-complete and extra metadata and get back to you! I want to make sure I don't misquote the developers! :) - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/c4de0c04/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 17:01:30 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 17:01:34 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> Message-ID: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> On Thu, Jun 5, 2008 at 6:37 PM, Jacek Antonelli wrote: > Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing > "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just > be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont > (152,166,46)" -- depending on how specific I feel like being. Why > force people to type in all that needless boilerplate and punctuation? > I apologize for the confusion - while the SLURL has been discussed as the default, you will also be able to type a Region name. I'll check in with the development team to get some more specifics. It would also be really useful to be able to type in a landmark, with > name completion, just as it is in the Map floater. Type in "Ben's > house" (the name of the landmark in my inventory), press Enter or > click Go, and off I go to Ben's house. I agree. I'd like to have this functionality too. When I name a Landmark, 'My build hideaway', I'd like to be able to type that into the address bar. I will follow up on that as well. - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3fdb60cd/attachment.htm From gbrandon at gmail.com Thu Jun 5 17:21:31 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Jun 5 17:21:36 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: Attaching link to article about FireFox 3's "smart bar" since I keep thinking of it here http://ed.agadak.net/2007/11/smartbar-to-awesomebar On Thu, Jun 5, 2008 at 8:01 PM, Sarah Hutchinson wrote: > On Thu, Jun 5, 2008 at 6:37 PM, Jacek Antonelli > wrote: > >> Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing >> "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just >> be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont >> (152,166,46)" -- depending on how specific I feel like being. Why >> force people to type in all that needless boilerplate and punctuation? >> > > I apologize for the confusion - while the SLURL has been discussed as the > default, you will also be able to type a Region name. I'll check in with the > development team to get some more specifics. > > It would also be really useful to be able to type in a landmark, with >> name completion, just as it is in the Map floater. Type in "Ben's >> house" (the name of the landmark in my inventory), press Enter or >> click Go, and off I go to Ben's house. > > > I agree. I'd like to have this functionality too. When I name a Landmark, > 'My build hideaway', I'd like to be able to type that into the address bar. > I will follow up on that as well. > > - Kippie > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/c1ce7192/attachment.htm From tongb at ohio.edu Thu Jun 5 17:47:18 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 5 17:47:23 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> Message-ID: <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> I attempted to build using cmake for the first time. I seem to have encountered something similar to what Michelle2 Zenovka mentioned in VWR-6794. I guess that's fitting since I was following her nice summary found at... http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake I was using the sources from... slviewer-src-maint-viewer-7-r88903 $ ./develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DUNATTENDED:BOOl=FALSE -DSTANDALONE:BO OL=FALSE "" "c:/ZZTong/SLDev/linden/indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works -- Building with FMOD audio support -- Building with FMOD audio support -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in '/cygdrive/c/ZZTong/SLDev/linden/i ndra' sh: toolsvstoolVSTool.exe: command not found Traceback (most recent call last): File "./develop.py", line 631, in main(sys.argv[1:]) File "./develop.py", line 604, in main setup.run_cmake() File "./develop.py", line 493, in run_cmake self.run(vstool_cmd) File "./develop.py", line 481, in run (name, ret)) __main__.CommandError: the command 'tools\\vstool\\VSTool.exe' exited with 32512 One thing I found that wasn't mentioned was this message from develop.py: The C compiler "c1" is not able to compile a simple test program. It fails with the following output: The requested operation requires elevation Generator: execution of make failed. Make command was: C:\PROGRA~1\MICROS~2\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debu g /project cmTryCompileExec I figured this was refering to ... C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VCExpress.exe ... and I resolved it by... Control Panel -> User Accounts Turn Account Control OFF ... I'm not used to developing on Windows, plus this is my first exposure to Windows Vista. I was expecting somebody to knock on the door and say "Hi, I'm a Mac", but that didn't happen. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Thu Jun 5 17:50:02 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 5 17:50:04 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: > I attempted to build using cmake for the first time. I seem to have > encountered something similar to what Michelle2 Zenovka mentioned in > VWR-6794. I guess that's fitting since I was following her nice > summary found at... > > http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake > > I was using the sources from... slviewer-src-maint-viewer-7-r88903 > > $ ./develop.py -G VC80 >From the $ prompt, are you attempting this with cygwin? What happens if you try it from a command shell without cygwin in your path? From secret.argent at gmail.com Thu Jun 5 19:54:43 2008 From: secret.argent at gmail.com (Argent) Date: Thu Jun 5 19:54:45 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C@gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-431F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> Message-ID: <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> On Thu, Jun 5, 2008 at 6:12 PM, Richard Nelson wrote: > If I understand you correctly, you want the preview portion of the texture picker to > be part of the inventory window as well. Close. I want it available as a view of the inventory. > There are several operations which require a full inventory search...I don't remember > them all. I don't think pulling in landmarks is, because when I open a folder in the inventory it will open, but other folders in the inventory may still be in the downloading state... and teh landmarks folder is no exception. > The working assumption right now is that any time you run the client you will need > your entire inventory contents in short order. I don't know that's a safe assumption. Usually the first thing I do when I log in is look up a landmark to get to the first place I want to go to. I do this long before I hit the inventory for anything else. Bringing up the inventory menu in the map is MUCH slower than opening the inventory, opening landmarks, and working from there, but it's also more convenient. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3d2eb10e/attachment.htm From kf6kjg at gmail.com Thu Jun 5 19:55:29 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Jun 5 19:55:32 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> Message-ID: <3bb9647e0806051955s3f38273bm68db1bda4d7207c9@mail.gmail.com> I just did a reverse-dependency check for my installed programs thinking that I might have some problems there, and I did, but fixing those problems didn't fix the build. Still trying to figure it out. Anything I might want to look at? Here is what I do: $ cd ./linden/indra $ ./develop.py cmake $ cd viewer-linux-i686 $ make Cron On Thu, Jun 5, 2008 at 1:10 AM, Robin Cornelius wrote: > On Thu, Jun 5, 2008 at 7:55 AM, Ricky wrote: > > hmm... According to portage (the package management system for Gentoo) I > > already have freetype 2.3.5-r2 installed in the chroot. > > > > And i am being stupid at the same time, its complaining of missing > symbols not a missing library so its not even attempting to link > against freetype. But it must have found the freetype headers. > > STANDALONE uses pkgconfig in indra/Freetype.cmake which will set the > CFLAGS and LDFLAGS correctly, something is missing somewhere then in > the standard build? Has it detected you are on 64bit and changed the > library location to libraries/x86_64-linux which i presume there are > no prebuild libs for? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/c278db31/attachment.htm From tongb at ohio.edu Thu Jun 5 21:12:43 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 5 21:12:48 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> Message-ID: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Yes, I was running that within a bash shell from cygwin. I'm not sure why, now that I think about it. Some part of the process had me install it. I like bash and I guess it must have been wishful thinking on my part, or something. If I try it from a windows command prompt, I get... C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' -- Building with FMOD audio support -- Building with FMOD audio support -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' Opening solution: build-VC80\SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, now opening new VisualStudio instance... Reading .sln file version... Opening VS version: VC80... Value cannot be null. Parameter name: type Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl n On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: > On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >> I attempted to build using cmake for the first time. I seem to have >> encountered something similar to what Michelle2 Zenovka mentioned in >> VWR-6794. I guess that's fitting since I was following her nice >> summary found at... >> >> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >> >> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >> >> $ ./develop.py -G VC80 > > >From the $ prompt, are you attempting this with cygwin? What happens > if you try it from a command shell without cygwin in your path? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Thu Jun 5 21:24:11 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 5 21:24:13 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Message-ID: Thanks, passing this straight to the cmake guys in case they're not reading On Thu, Jun 5, 2008 at 11:12 PM, Bruce Tong wrote: > Yes, I was running that within a bash shell from cygwin. I'm not sure > why, now that I think about it. Some part of the process had me > install it. I like bash and I guess it must have been wishful thinking > on my part, or something. > > If I try it from a windows command prompt, I get... > > C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 > Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' > -- Building with FMOD audio support > -- Building with FMOD audio support > -- Version of viewer is 1.20.6.0 > -- Configuring done > -- Generating done > -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 > Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi > g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' > > Opening solution: build-VC80\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC80... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl > n > > On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> I attempted to build using cmake for the first time. I seem to have >>> encountered something similar to what Michelle2 Zenovka mentioned in >>> VWR-6794. I guess that's fitting since I was following her nice >>> summary found at... >>> >>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>> >>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>> >>> $ ./develop.py -G VC80 >> >> >From the $ prompt, are you attempting this with cygwin? What happens >> if you try it from a command shell without cygwin in your path? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > From gigstaggart at gmail.com Thu Jun 5 22:46:28 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 5 22:46:31 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> Message-ID: <4848CF34.604@gmail.com> Argent Stonecutter wrote: > On 2008-06-04, at 00:04, Jason Giglio wrote: >> I'm all for metered bandwidth. > > I don't think "metered bandwidth" is a good term. Bandwidth is "how > much you can transmit per unit of time", and is metered in units of > bits-per-second. My bandwidth is capped to 256 kilobits per second, > for example. This is good enough to play SL, but not enough to stream > HD movies (or stream anything while I'm playing SL). > > What we're talking about here needs a different term. It's not a > bandwidth cap, it's a total traffic cap. I don't know what you are talking about, but what I'm talking about is metered bandwidth. I.e. 0.1 cents per meg + $5/month as an example. Like every other utility service known to man, in other words. Your water company does not turn off your water if you use over a certain amount, they just charge you more. Internet service should be no different. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/8fc901d1/smime-0001.bin From tateru.nino at gmail.com Thu Jun 5 22:51:35 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 22:52:19 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: <4848D067.5000704@gmail.com> Jason Giglio wrote: > Argent Stonecutter wrote: > >> On 2008-06-04, at 00:04, Jason Giglio wrote: >> >>> I'm all for metered bandwidth. >>> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. >> > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. > > I.e. 0.1 cents per meg + $5/month as an example. Like every other > utility service known to man, in other words. > > Your water company does not turn off your water if you use over a > certain amount, they just charge you more. Internet service should be > no different. > > Most countries either cut it off - or charge you extra. US$0.115 is a common amount to charge per million bytes (not per meg). From lcc1967 at gmail.com Thu Jun 5 23:37:54 2008 From: lcc1967 at gmail.com (laurent cezanne) Date: Thu Jun 5 23:37:57 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> Message-ID: about LM navigation: Is there a way to show a LM has changed like a sim owner change or coordonate ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/33a51086/attachment.htm From ordinal.malaprop at fastmail.fm Fri Jun 6 02:01:28 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Jun 6 02:01:33 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: On 6 Jun 2008, at 06:46, Jason Giglio wrote: > Argent Stonecutter wrote: >> On 2008-06-04, at 00:04, Jason Giglio wrote: >>> I'm all for metered bandwidth. >> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. > > I.e. 0.1 cents per meg + $5/month as an example. Like every other > utility service known to man, in other words. > > Your water company does not turn off your water if you use over a > certain amount, they just charge you more. Internet service should be > no different. I think that what he is talking about is that what is being referred to here and elsewhere as "bandwidth" is not bandwidth, but quantity of data transferred. (Incidentally my water is not metered, but that's by the by.) From kfa at gmx.net Fri Jun 6 02:32:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 02:32:16 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> Message-ID: <48490413.8050708@gmx.net> laurent cezanne wrote: > about LM navigation: Is there a way to show a LM has changed like a sim > owner change or coordonate ? > > Great point! No, currently not. When taking a landmark, you only conserve a piece of information from that time which afterwards has no more connection with its source. Having a way to poll for an update would constitute a significant improvement in the value of landmarks. This would be a great item for the NAV project, if someone with the permission to post there felt inclined to include it. Also, it involves doing something on the server side, so it's not something that the OS crowd currently could take up. Not sure if Vectorform is granted access beyond the viewer? Cheers, Felix From robin.cornelius at gmail.com Fri Jun 6 02:38:12 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jun 6 02:38:19 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed Message-ID: Hi everyone, We had some more discussion at Rob's hours yesterday and the basic problem is there are multiple issues here and we seem to be going over the same topics in circles without really achieving very much. (In fact Rob believes this sounds like the March 2007 discussion all over again). Rob proposed we create a bof[1] Working Group, and to me this sounds like it needs some wiki pages to lay out the issues. I am happy to try to pull some stuff together, but without sounding like a complete moron, where should we put these pages on the wiki? What i propose is that we firstly try to subdivide these issues and although they are related there seems to be some funtimental top level categories that are :- * Performance * Amount of downloaded data May be more and sub issues of those too. The original discussion was purely a performance due to decoding of cached j2k textures. But other very valid sub points have cropped up including issues of the amount of downloaded data. Various suggestions have been made about storing more data, uncompressed data etc all of which many have consequences .Other things include not using the separate texture headers and files, storing in alternative formats We could also do with defining what we could do and methods of measuring its effects in quantitative terms NOT qualitative for performance/data download amounts etc. But we also have to factor in to account political views (the angry villagers with pitchforks analogy). So what i would like to do is :- * Define issues with the texture caching system (with the scope also including download amounts due to textures) * Define and discuss possible solutions, alternatives etc. * Get some linden input on what they are doing internally, is the texture cache being rewritten? or planning to be as part of the new texture pipeline, is this worth wile and will it provide decent feedback to the lindens? * If anyone has time, play with some possible solutions and measure performance. * if we are to measure performance, define how on earth to do this. Regards Robin [1] http://en.wikipedia.org/wiki/Birds_of_a_Feather_(computing) From kfa at gmx.net Fri Jun 6 02:49:33 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 02:49:47 2008 Subject: [sldev] More ideas for NAV - was: Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: <48490413.8050708@gmx.net> References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> <48490413.8050708@gmx.net> Message-ID: <4849082D.5010701@gmx.net> Felix Duesenburg wrote: > laurent cezanne wrote: >> about LM navigation: Is there a way to show a LM has changed like a >> sim owner change or coordonate ? >> >> > > Great point! No, currently not. When taking a landmark, you only > conserve a piece of information from that time which afterwards has no > more connection with its source. Having a way to poll for an update > would constitute a significant improvement in the value of landmarks. > > This would be a great item for the NAV project, if someone with the > permission to post there felt inclined to include it. Also, it involves > doing something on the server side, so it's not something that the OS > crowd currently could take up. ... Maybe I spoke too quickly... why could we not? It should be possible to do a search for the geocoordinates of a landmark and retrieve current information about its owner, name, even parcel content when I look at how the places search recently works. This could be run as a background task when inventory is refreshed. Only thing, I'm not sure what that would do to the database load if it was a standard feature... Another idea for NAV: The landmark preview floater could include all the information that you find with the places search. Maybe vendors would like the idea that this way the list of objects for sale at that location would be visible to the client just by a double click. Does that make sense? Felix From robin.cornelius at gmail.com Fri Jun 6 04:17:26 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jun 6 04:17:30 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: On Fri, Jun 6, 2008 at 11:57 AM, Dale Mahalko wrote: > Is there some particular reason the caching is limited to just > textures? It appears that most everything else also has the potential > to also be cached. Sounds, primitive shapes, notecards, linksets, and > the terrain shape should also apparently be locally cachable. No technical reason, that i know of anyway for things like animations and sounds, even notecards and things that have an asset server LLUID. The current system does cache sounds, animations etc for a single session but they are deleted when the viewer closes. This is something i will be changing on my private viewer just for the reason "why the **** am i downloading the same sound/animation etc again and again" Now objects shapes and things that are not static are more troublesome as i suppose you need a way of re synchronizing. I don't know the message handshakes in enough detail to know how well this could work. I think some is done now? But i would have thought that the basic object position/details is fairly low bandwidth information compared to textures/sounds and the like and the additional overhead may outweigh the simple waiting for the object update packets, i don't know. Robin From dmahalko at gmail.com Fri Jun 6 03:57:29 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 6 04:22:03 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: Is there some particular reason the caching is limited to just textures? It appears that most everything else also has the potential to also be cached. Sounds, primitive shapes, notecards, linksets, and the terrain shape should also apparently be locally cachable. Regarding the angry pitchforks, I suppose you could do something fast and stupid like (rot13 + some offset) on everything, and then slap the DMCA against anyone who "decodes" that "encryption" system. Other than that, it has been stated over and over that nothing can done to absolutely protect any asset data from copying, other than server-side compiled scripts. I fully accept that there may be strong political views against developing a robust and comprehensive local cache because that make it easy to "rip" the sounds, images, and objects created by other people. I see this as no defense against doing good local caching because those with the programming skill to do so are already ripping content from asset system using the client source code and wrappers. And even if there is strong resistance to having a large and easily rippable cache on the local user's machine, this should not stop the development of a "commercial grade" proxy cache for use by an ISP, school, or business which must support many users all trying to access the same super-high bandwidth SL system. The likelihood of someone at an ISP or university ripping someone's skirt texture from their local 10 TB SL asset-proxy/cache is pretty darn low, compared to the massive benefits of being able to taking the asset download strain off their Internet bandwidth. - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 4:38 AM, Robin Cornelius wrote: > What i propose is that we firstly try to subdivide these issues and > although they are related there seems to be some funtimental top level > categories that are :- > > * Performance > * Amount of downloaded data From tateru.nino at gmail.com Fri Jun 6 04:21:45 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 04:22:30 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: <48491DC9.3000908@gmail.com> ordinal.malaprop@fastmail.fm wrote: > > On 6 Jun 2008, at 06:46, Jason Giglio wrote: > >> Argent Stonecutter wrote: >>> On 2008-06-04, at 00:04, Jason Giglio wrote: >>>> I'm all for metered bandwidth. >>> >>> I don't think "metered bandwidth" is a good term. Bandwidth is "how >>> much you can transmit per unit of time", and is metered in units of >>> bits-per-second. My bandwidth is capped to 256 kilobits per second, >>> for example. This is good enough to play SL, but not enough to stream >>> HD movies (or stream anything while I'm playing SL). >>> >>> What we're talking about here needs a different term. It's not a >>> bandwidth cap, it's a total traffic cap. >> >> >> I don't know what you are talking about, but what I'm talking about is >> metered bandwidth. >> >> I.e. 0.1 cents per meg + $5/month as an example. Like every other >> utility service known to man, in other words. >> >> Your water company does not turn off your water if you use over a >> certain amount, they just charge you more. Internet service should be >> no different. > > I think that what he is talking about is that what is being referred > to here and elsewhere as "bandwidth" is not bandwidth, but quantity of > data transferred. > "Bandwidth" is confusingly used to mean "bandwidth consumption" which, I believe, is what is actually being referred to in this discussion. From tateru.nino at gmail.com Fri Jun 6 04:25:12 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 04:25:58 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <48491E98.3@gmail.com> Robin Cornelius wrote: > On Fri, Jun 6, 2008 at 11:57 AM, Dale Mahalko wrote: > >> Is there some particular reason the caching is limited to just >> textures? It appears that most everything else also has the potential >> to also be cached. Sounds, primitive shapes, notecards, linksets, and >> the terrain shape should also apparently be locally cachable. >> > > No technical reason, that i know of anyway for things like animations > and sounds, even notecards and things that have an asset server LLUID. > > The current system does cache sounds, animations etc for a single > session but they are deleted when the viewer closes. This is > something i will be changing on my private viewer just for the reason > "why the **** am i downloading the same sound/animation etc again and > again" > Animations sometimes seem to get corrupted. I've certainly seen broken animations get cached, where they annoy you for the rest of a session. I've heard anecdotal accounts of the viewer caching silences when it comes to sounds, but I'm less certain of that. From secret.argent at gmail.com Fri Jun 6 04:40:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:39:24 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: <6E97248F-39D3-457F-B1B9-19FC91EEE117@gmail.com> Added SVC-2482. From me at signpostmarv.name Fri Jun 6 04:41:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jun 6 04:41:13 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <48492253.9050308@signpostmarv.name> Dale Mahalko wrote: > Is there some particular reason the caching is limited to just > textures? It appears that most everything else also has the potential > to also be cached. Sounds, primitive shapes, notecards, linksets, and > the terrain shape should also apparently be locally cachable. > > Regarding the angry pitchforks, I suppose you could do something fast > and stupid like (rot13 + some offset) on everything, and then slap the > DMCA against anyone who "decodes" that "encryption" system. Other than > that, it has been stated over and over that nothing can done to > absolutely protect any asset data from copying, other than server-side > compiled scripts. > > > I fully accept that there may be strong political views against > developing a robust and comprehensive local cache because that make it > easy to "rip" the sounds, images, and objects created by other people. > I see this as no defense against doing good local caching because > those with the programming skill to do so are already ripping content > from asset system using the client source code and wrappers. In order to get appease the pitchfork carrying mob, since textures are being fetched over HTTP (and one assumes other assets may be sent over HTTP ?), why not just have the remote tool that spits out the asset examine permissions and send appropriate caching headers ? I'd not advocate borking the existing permissions system to figure out which headers to send, I'd prefer adding an additional "allow client caching" flag, where it sends appropriate Cache-Control headers ? http://www.mnot.net/cache_docs/#CACHE-CONTROL ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/5aebb865/smime.bin From gigstaggart at gmail.com Fri Jun 6 04:48:13 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 04:48:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> Message-ID: <484923FD.2020807@gmail.com> Sean Lynch wrote: > Sorry, I phrased that confusingly. By "routed directly to other viewers" I > meant the message is routed by the simulator to any viewers that can see the > agent. There are some messages that work this way, but I don't know what > they are off the top of my head. LookAt, Typing Animation, maybe fidgits? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/1b014e5d/smime.bin From secret.argent at gmail.com Fri Jun 6 04:50:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:48:53 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4848206A.4030804@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> Message-ID: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> I don't think P2P is an option from a privacy perspective anyway. From gigstaggart at gmail.com Fri Jun 6 04:52:06 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 04:52:11 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> Message-ID: <484924E6.8080607@gmail.com> Argent Stonecutter wrote: > I don't think P2P is an option from a privacy perspective anyway. What do you mean, 70-140-36-186.lightspeed.hstntx.sbcglobal.net? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/ca3e100f/smime-0001.bin From secret.argent at gmail.com Fri Jun 6 04:59:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:58:38 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48483FBE.8070206@watson.ibm.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> <48483FBE.8070206@watson.ibm.com> Message-ID: On 2008-06-05, at 14:34, Mike Monkowski wrote: > The problem I see with gestures is that they have a fixed time > sequence. They play exactly the same way every time. Not very > cinematic. I have wanted an extended llStartAnimation() with a few extra options: llStartAnimationExt(string anim, float rate, vector offset, integer priority, integer bonemask, ...); Alas, scrubbing in a HUD would require fixing a number of JIRAs regarding llDetectedGrab() and similar. From secret.argent at gmail.com Fri Jun 6 05:06:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:05:37 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> Message-ID: On 2008-06-05, at 18:47, Sarah Hutchinson wrote: > We discussed the idea of integrating the nav bar into the menu bar, > but felt it made the menu bar far too cluttered. There's just so > much happening in that area of the UI already. What about making the region name in the menu bar, something that's already there, into a menu dropdown? The existing action (land properties) would be in the menu, along with navigation options... From secret.argent at gmail.com Fri Jun 6 05:11:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:09:53 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: <95DD712A-52D3-456D-8123-9F040D56BA6C@gmail.com> On 2008-06-05, at 19:01, Sarah Hutchinson wrote: > I apologize for the confusion - while the SLURL has been discussed > as the default, you will also be able to type a Region name. I'll > check in with the development team to get some more specifics. I don't want to see the SLURL displayed, either. What is wrong with "secondlife://region/x/y/z" by the way? Why the switch to the external SLURLs inside the game? It seems inconsistent, plus it makes it hard to pass someone an extern link on the slurl site... From secret.argent at gmail.com Fri Jun 6 05:24:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:23:04 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: On 2008-06-06, at 00:46, Jason Giglio wrote: > Argent Stonecutter wrote: >> On 2008-06-04, at 00:04, Jason Giglio wrote: >>> I'm all for metered bandwidth. >> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. I know what you're talking about. I'm saying that it's the wrong term. Your bandwidth (the amount of data you can transfer per second) is not metered in the scheme you are talking about, the total traffic (the total amount of data you are allowed to transfer) is. I have actual metered bandwidth at home. If I want higher transfer speeds, I pay more. I currently have it set to 256k per second. 256k per second is a *bandwidth* measurement. 5GB per month isn't... that 5GB can be a small number of high bandwidth transfers, or a long period with much lower bandwidth. From secret.argent at gmail.com Fri Jun 6 05:29:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:27:41 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48491DC9.3000908@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> Message-ID: <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> On 2008-06-06, at 06:21, Tateru Nino wrote: > "Bandwidth" is confusingly used to mean "bandwidth consumption" > which, I believe, is what is actually being referred to in this > discussion. I have no idea what "bandwidth consumption" means. Bandwidth isn't consumed, like power or water. It's a speed limit. What would "speed limit consumption" mean? From secret.argent at gmail.com Fri Jun 6 05:32:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:32:31 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484924E6.8080607@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> Message-ID: <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> On 2008-06-06, at 06:52, Jason Giglio wrote: > Argent Stonecutter wrote: >> I don't think P2P is an option from a privacy perspective anyway. > > What do you mean, 70-140-36-186.lightspeed.hstntx.sbcglobal.net? Email doesn't happen inside SL. There is currently no way for you to get that information about me *within second life* and use it to determine that any member of my family is using SL from the same IP address and figure out who they are in SL. None. Zippo. Zero. That SHOULD NOT change. From bboomslang at googlemail.com Fri Jun 6 05:45:25 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Fri Jun 6 05:45:29 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> Message-ID: <347b550f0806060545m6ef5389bk16232e6463254ca5@mail.gmail.com> Hey, yep, I run that option enabled for as long as I know about it's existance - and yep, it does help definitely. I have a dual-core machine, so it actually enhances FPS since part of the code is offloaded to the other core. And I never had any problems that were linked to that option - or to put differently, everytime I had problems I thought might be related to it, they didn't improve by switching it off and usually where solved by one of Nicholaz' patches ;) bye, Barney On 6/4/08, Nexeus Fatale wrote: > I wonder if anyone has tested the run multiple threads and have found > any improvements > > > - Nexeus > > > On Tue, Jun 3, 2008 at 9:11 PM, Matthew Underwood wrote: > > On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: > >> If the goal were to improve seek time in a cache, how about keeping the > >> cache on one of those readyboost-capable usb flash drives? They can have > >> seek times as low as 1 ms or better, although the transfer rate and write > >> times arent all that fast. > >> > >> Then again it's probably moot if the bottleneck is the decoding :/ > >> > >> On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: > >>> > >>> Dale Mahalko wrote: > >>>> > >>>> ... > >>>> Windows isn't good at dealing with directories containing tens of > >>>> thousands of files. Ever tried opening a folder containing 20,000 > >>>> files? There is a delay of several seconds trying to do this in > >>>> Windows. Also the hidden MFT and directory structures can become > >>>> ridiculously fragmented, also leading to slowdowns. > >>>> > >>> > >>> Reiser4 is excellent with exactly these requirements. It's not mature > >>> enough to be considered reliable for critical systems, but for a cache? It > >>> doesn't help that Reiser himself is removed from the development process, > >>> but it's still there and the source available. Shouldn't that be possible to > >>> be included as a virtual filesystem even under Windows? > >>> > >>> I also always thought it must be a good way to boost performance if the > >>> cache lived on its own partition, like a Linux swap partition. For the Linux > >>> version of SL this would even sound like the most natural way to do it. > >>> Setting such a thing up on an existing Windows machine has a slight fear > >>> factor attached and is not for everyone, but if a savvy user can handle it, > >>> why not offer. I'm speculating, but the difference could be dramatic, > >>> especially if we had a better file system than NTFS on that partition. > >>> > >>> > > >>> > A proper local database engine would likely deal with these huge > >>> > numbers of tiny files more efficiently than the local operating > >>> > system. > >>> > >>> Yes, but the usual architecture with the database running as a localhost > >>> server is not ideal for our situation since everything is squeezed back and > >>> forth through the network system, plus SQL parsing, unnecessarily. With > >>> MySQL you could build directly on top of the storage engine though, even > >>> bypassing the parsing with direct API calls. It would just serve as a > >>> virtual file system the same way as suggested above. I still believe that > >>> Reiser4 would be even faster. And according to the description on its (now > >>> defunct) website, they claimed reaching 94% package density with small > >>> files. > >>> > >>> Felix > > > > SQLite in a single user environment is incredibly fast so long as you > > don't let the database grow too large. Of course you have to figure > > out how efficiently textures can be stored and retrieved in SQL > > compared to the current caching system. > > > > On a side note: Does anyone know where it defines the polygon meshes > > for rendering cubes. I really want to try forcing untwisted, un-holed > > cubes down to 1-2 polygons per side and see if that will help out with > > the frame rate. I tried looking through the source but it is lacking > > in [helpful] comments. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From me at signpostmarv.name Fri Jun 6 05:54:29 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jun 6 05:54:33 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> Message-ID: <48493385.4050008@signpostmarv.name> Aside from llParcelMediaCommandList() with the PARCEL_MEDIA_COMMAND_AGENT flag set. Argent Stonecutter wrote: > Email doesn't happen inside SL. There is currently no way for you to > get that information about me *within second life* and use it to > determine that any member of my family is using SL from the same IP > address and figure out who they are in SL. None. Zippo. Zero. That > SHOULD NOT change. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/aa114734/smime.bin From gigstaggart at gmail.com Fri Jun 6 06:39:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 06:39:11 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> Message-ID: <48493DF8.4040003@gmail.com> Argent Stonecutter wrote: > On 2008-06-06, at 06:21, Tateru Nino wrote: >> "Bandwidth" is confusingly used to mean "bandwidth consumption" >> which, I believe, is what is actually being referred to in this >> discussion. > > I have no idea what "bandwidth consumption" means. Bandwidth isn't > consumed, like power or water. It's a speed limit. What would "speed > limit consumption" mean? Don't get all nitpicky. The use of the term "bandwidth" to mean "speed limit" is already an abuse of an engineering term that had a specific, mostly unrelated meaning. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/4ea979b4/smime.bin From alissa_sabre at yahoo.co.jp Thu Jun 5 21:11:08 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jun 6 06:48:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <4846FA40.4010102@gmail.com> Message-ID: <1L2cG27ei4facewdds4mhwkw.alissa_sabre@yahoo.co.jp> > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). No. It is the probability of one particuar UUID hits with another. Since you have a lot of UUIDs in your cache, the probability that you find two (or more) having the same prefix in your cache is much larger than that. Search for "birthday paradox" with your favorite search engine for details. Alissa Sabre -------------------------------------- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ From kfa at gmx.net Fri Jun 6 06:49:44 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 06:49:54 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> Message-ID: <48494078.5090801@gmx.net> Sarah Hutchinson wrote: > > > We discussed the idea of integrating the nav bar into the menu bar, but > felt it made the menu bar far too cluttered. There's just so much > happening in that area of the UI already. As long as you run Second Life > in a full screen window on a large monitor, it can work out great - but > for those running Second Life on a smaller display or window, it was > just too crowded. > > - Kippie > > We'll probably find that there are different tastes, habits and opinions here. I usually run SL not in fullscreen mode, but in a window that is maximized. That way I still have all functionality available, be it SL or outside, but maximum viewing angle. I like my 3D view into the world uncluttered and unfettered, and everything else pushed out of the way, marginalized. I even use HUD's only sparingly. For me, the big main menu is where these things should go and stay. I wonder, what speaks against leaving it that way since we can tear off submenus? I'd say all it takes is preserving the state and position of a torn off menu across sessions to accomodate different usage patterns. Felix From danteferret at gmail.com Fri Jun 6 07:27:24 2008 From: danteferret at gmail.com (Dante Tucker) Date: Fri Jun 6 07:27:25 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <48494078.5090801@gmx.net> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> Message-ID: <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> Really, my main personal concern when this project is over is "Can I hide it? Can I make it go away?" It's not negativity against this project, It's just how I like my UI. There should be nothing more then the bottom bar, menu bar and the world. Actualy this is a major concern for many people here. So, can we hide these new navigation features if we don't want them? On Fri, Jun 6, 2008 at 9:49 AM, Felix Duesenburg wrote: > >> > We'll probably find that there are different tastes, habits and opinions > here. I usually run SL not in fullscreen mode, but in a window that is > maximized. That way I still have all functionality available, be it SL or > outside, but maximum viewing angle. I like my 3D view into the world > uncluttered and unfettered, and everything else pushed out of the way, > marginalized. I even use HUD's only sparingly. For me, the big main menu is > where these things should go and stay. I wonder, what speaks against leaving > it that way since we can tear off submenus? I'd say all it takes is > preserving the state and position of a torn off menu across sessions to > accomodate different usage patterns. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/3fde6bf1/attachment.htm From sarah at aucreativegroup.com Fri Jun 6 08:25:31 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Fri Jun 6 08:25:37 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> Message-ID: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> There is a tiny toggle that will be in the top left of the Viewer which will allow you to show and hide the nav bar as you want. Likewise, with the Landmarks Management UI, if you don't want to use it, you won't have to. You'll see be able to see and work with your Landmarks via the Inventory floater. I believe the latest creative posted to NAV-28 ( https://jira.secondlife.com/browse/NAV-28). That should show the toggle and the different states. So in the event that you have the nav bar hidden, you'd just have a small little toggle button at the top left. Does that help? Best, Kippie/Sarah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/fd7ca04b/attachment-0001.htm From kfa at gmx.net Fri Jun 6 09:26:19 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 09:26:27 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <4849652B.608@gmx.net> Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer which > will allow you to show and hide the nav bar as you want. > > Likewise, with the Landmarks Management UI, if you don't want to use it, > you won't have to. You'll see be able to see and work with your > Landmarks via the Inventory floater. > > I believe the latest creative posted to NAV-28 > (https://jira.secondlife.com/browse/NAV-28). That should show the toggle > and the different states. So in the event that you have the nav bar > hidden, you'd just have a small little toggle button at the top left. > Does that help? > > Best, > Kippie/Sarah > > Why not a menu item for the toggle thingy, possibly connected with a keyboard shortcut. Resistance is futile ;) From phoenix at secondlife.com Fri Jun 6 09:28:04 2008 From: phoenix at secondlife.com (Phoenix) Date: Fri Jun 6 09:28:22 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com><61a5f47b10aafc4ff71eb929813bd563@localhost>< 4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Message-ID: <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> The attached patch appears to solve the vstool problem, but I don't think microsoft tools like to be run from cygwin. VC71 usually worked under cygwin but: * /cyg/path/to/Program Files/CMake 2.4/bin must be in your path * vstool occasionally crashed -- deleting the generated directory and trying again always worked. * VC80 was unable to load the generated project file * I did not try VC90. I'm sneaking this patch into trunk, but you can try it out now. Index: develop.py =================================================================== --- develop.py (revision 89110) +++ develop.py (working copy) @@ -485,10 +485,11 @@ PlatformSetup.run_cmake(self, args) if self.unattended == 'FALSE': for build_dir in self.build_dirs(): - vstool_cmd = ('tools\\vstool\\VSTool.exe' - ' --solution %s\\SecondLife.sln' - ' --config RelWithDebInfo' - ' --startup secondlife-bin' % build_dir) + vstool_cmd = os.path.join ('tools','vstool','VSTool.exe') \ + + ' --solution ' \ + + os.path.join (build_dir,'SecondLife.sln') \ + + ' --config RelWithDebInfo' \ + + ' --startup secondlife-bin' print 'Running %r in %r' % (vstool_cmd, os.getcwd()) self.run(vstool_cmd) @@ -619,7 +620,7 @@ raise CommandError('clean takes no arguments') setup.cleanup() else: - print >> sys.stderr, 'Error: unknown command', repr(arg) + print >> sys.stderr, 'Error: unknown command', repr(cmd) print >> sys.stderr, "(run 'develop.py --help' for help)" sys.exit(1) except CommandError, err: On 2008-06-05, at 21:12, Bruce Tong wrote: > Yes, I was running that within a bash shell from cygwin. I'm not sure > why, now that I think about it. Some part of the process had me > install it. I like bash and I guess it must have been wishful thinking > on my part, or something. > > If I try it from a windows command prompt, I get... > > C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 > Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' > -- Building with FMOD audio support > -- Building with FMOD audio support > -- Version of viewer is 1.20.6.0 > -- Configuring done > -- Generating done > -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/ > build-VC80 > Running 'tools\\vstool\\VSTool.exe --solution build-VC80\ > \SecondLife.sln --confi > g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\ > \linden\\indra' > > Opening solution: build-VC80\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC80... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80 > \SecondLife.sl > n > > On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> I attempted to build using cmake for the first time. I seem to have >>> encountered something similar to what Michelle2 Zenovka mentioned in >>> VWR-6794. I guess that's fitting since I was following her nice >>> summary found at... >>> >>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>> >>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>> >>> $ ./develop.py -G VC80 >> >>> From the $ prompt, are you attempting this with cygwin? What happens >> if you try it from a command shell without cygwin in your path? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/e6f59446/PGP.pgp From richard at lindenlab.com Fri Jun 6 09:31:50 2008 From: richard at lindenlab.com (Richard Nelson) Date: Fri Jun 6 09:31:53 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> Message-ID: On Thu, 05 Jun 2008 19:54:43 -0700, Argent wrote: > On Thu, Jun 5, 2008 at 6:12 PM, Richard Nelson > wrote: >> There are several operations which require a full inventory search...I > don't remember >> them all. > > I don't think pulling in landmarks is, because when I open a folder in > the > inventory it will open, but other folders in the inventory may still be > in > the downloading state... and teh landmarks folder is no exception. > The inventory fetch is scheduled one folder at a time. Any time you explicitly open a folder, the request for the contents of that folder are put at the top of the queue, so you should see the contents appear quickly. But as long as you see the number of fetched items being reported at the top of the inventory window, then the entire thing is being downloaded. >> The working assumption right now is that any time you run the client you > will need >> your entire inventory contents in short order. > > I don't know that's a safe assumption. Usually the first thing I do when > I > log in is > look up a landmark to get to the first place I want to go to. I do this > long > before I > hit the inventory for anything else. Bringing up the inventory menu in > the > map is > MUCH slower than opening the inventory, opening landmarks, and working > from > there, but > it's also more convenient. I'm not saying that the fetch occurs immediately, or even for everyone. Just that, with average usage, you will generally end up fetching your entire inventory whenever you log in. It puts too many constraints on our feature set if we have to delicately step around having your inventory available. Richard From mrallen1 at yahoo.com Fri Jun 6 11:02:13 2008 From: mrallen1 at yahoo.com (Mark Allen) Date: Fri Jun 6 11:02:16 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: Message-ID: <711493.29841.qm@web34303.mail.mud.yahoo.com> --- On Fri, 6/6/08, Dale Mahalko wrote: [...] > the development of a "commercial grade" proxy cache for use by an ISP, > school, or business which must support many users all trying to access > the same super-high bandwidth SL system. +1 Love this idea. It's like squid for Second Life content... Would SLProxy be a starting point for construction? Mark Allen http://www.linkedin.com/in/markrallen From aimee at ama-zing.co.uk Fri Jun 6 11:09:26 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jun 6 11:09:30 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> On Jun 6, 2008, at 16:25, Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer > which will allow you to show and hide the nav bar as you want. When not in use there should be _nothing_ visible in the main content area. I don't want to sound defeatist, but that looks far more like unnecessary clutter than simply making the information that's _already_ in the menu bar active. Yes, we already have a cluttered UI, but adding more clutter doesn't seem like an answer to me, it's just side stepping the problem. Did it get as far as mock-ups of an active menu bar? Maybe overflow the navigation into a hideable second line of the menu area (similar to what's being proposed for the nav bar) if the window is too small; that could be the best of both worlds? The main world view is what SL is all about, and it needs to be protected. For any new fixed UI element to be allowed as a permanent intrusion into that, no matter how small, there has to an absolutely compelling reason, and I just don't see it when there's a perfectly good menu bar. I know complaining about one tiny little toggle might seem a bit over the top, but these things have a habit of setting precedents which then allow other things to creep in in the future by eroding the boundary. Living in dreamland for a minute, ideally I'd like to to see the UI made up of dockable (and closeable) toolbar sections, so the user can decide the arrangement that best fits their window size, workflow, interest priority etc. and lose the bits they don't need. Think Adobe Photoshop CS3 etc., with saveable workspaces. Though I know that's way outside the scope of what's being discussed here, and there's an awful lot of work that would have to take place to make it possible, I'd like to see that as a long term aim for the UI. Something to work towards, even in baby steps. To me the Nav project should be seized as an opportunity to start the ground work for that. Rather than just adding another disjointed mismatched UI element, create the generic framework in code using this as a prototype, for a more versatile well structured system, for other parts of the UI to migrate to in future. Aimee. From kfa at gmx.net Fri Jun 6 11:23:32 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 11:23:47 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> Message-ID: <484980A4.1020708@gmx.net> Aimee Walton wrote: > ... > Though I know that's way outside the scope of what's being discussed > here, and there's an awful lot of work that would have to take place to > make it possible, I'd like to see that as a long term aim for the UI. > Something to work towards, even in baby steps. To me the Nav project > should be seized as an opportunity to start the ground work for that. > Rather than just adding another disjointed mismatched UI element, create > the generic framework in code using this as a prototype, for a more > versatile well structured system, for other parts of the UI to migrate > to in future. > That may be just a matter of interpretation whether it's outside the scope or not... what if one sees 'navigation' as navigation of the user interface as a whole. A holistic approach, yes. That sounds better for a project with its own JIRA namespace, doesn't it? Did anyone take a closer look at Blender's UI beyond an initial "Hoooo!" and shying away? Fully ingenious, fully customizable, and fully OpenGL. Takes a while to learn, but so does SL. Felix From jacek.antonelli at gmail.com Fri Jun 6 11:35:20 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Fri Jun 6 11:35:23 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> Message-ID: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> On Fri, Jun 6, 2008 at 1:09 PM, Aimee Walton wrote: > When not in use there should be _nothing_ visible in the main content area. > I don't want to sound defeatist, but that looks far more like unnecessary > clutter than simply making the information that's _already_ in the menu bar > active. Yes, we already have a cluttered UI, but adding more clutter doesn't > seem like an answer to me, it's just side stepping the problem. I think having the small button visible by default is important from a usability standpoint. I'm thinking particularly of "discoverability" -- users see the button, click it to find out what it does, and thus discover that the functionality exists. Otherwise, the majority of users wouldn't even know about it, which dampens the usefulness of the project. That said, I think there definitely should be a toggle item in the View menu to turn it off or on, just like there is for the bottom button bar (Fly, Snapshot, etc.). It would only take about 10 minutes to add such a thing, and it would soothe the nay-sayers. ;-) > Living in dreamland for a minute, ideally I'd like to to see the UI made up > of dockable (and closeable) toolbar sections, so the user can decide the > arrangement that best fits their window size, workflow, interest priority > etc. and lose the bits they don't need. Think Adobe Photoshop CS3 etc., with > saveable workspaces. Happily, that's a long term UI goal. :-) http://wiki.secondlife.com/wiki/User_Interface_Improvements From lenglish5 at cox.net Fri Jun 6 11:53:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jun 6 11:53:22 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> Message-ID: <4849879D.5000602@cox.net> Argent Stonecutter wrote: > I don't think P2P is an option from a privacy perspective anyway. > _______________________________________________ Sure, not for most purposes, but there could be use-cases where P2P was useful, hence the long-standing proposal that the protocol support informing the viewer that P2P is available in a given sim/grid and *how* to establish contact with other participating viewers. This is obviously not a SL-specific thing, but a private OpenSim grid might be running all sorts of simulation software, or collaboration software, etc., where P2P makes sense. Lawson From jhurliman at jhurliman.org Fri Jun 6 12:00:43 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri Jun 6 12:00:50 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> Message-ID: I had to change: + os.path.join(build_dir,'SecondLife.sln') \ to: + 'SecondLife.sln' \ to get this working. Before I would get "Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln ..." so I hacked it to get "Running 'tools\\vstool\\VSTool.exe --solution SecondLife.sln ..." and everything worked after that. John On Fri, Jun 6, 2008 at 9:28 AM, Phoenix wrote: > The attached patch appears to solve the vstool problem, but I don't think > microsoft tools like to be run from cygwin. VC71 usually worked under cygwin > but: > * /cyg/path/to/Program Files/CMake 2.4/bin must be in your path > * vstool occasionally crashed -- deleting the generated directory and > trying again always worked. > * VC80 was unable to load the generated project file > * I did not try VC90. > > I'm sneaking this patch into trunk, but you can try it out now. > > > Index: develop.py > =================================================================== > --- develop.py (revision 89110) > +++ develop.py (working copy) > @@ -485,10 +485,11 @@ > PlatformSetup.run_cmake(self, args) > if self.unattended == 'FALSE': > for build_dir in self.build_dirs(): > - vstool_cmd = ('tools\\vstool\\VSTool.exe' > - ' --solution %s\\SecondLife.sln' > - ' --config RelWithDebInfo' > - ' --startup secondlife-bin' % build_dir) > + vstool_cmd = os.path.join('tools','vstool','VSTool.exe') \ > + + ' --solution ' \ > + + os.path.join(build_dir,'SecondLife.sln') \ > + + ' --config RelWithDebInfo' \ > + + ' --startup secondlife-bin' > print 'Running %r in %r' % (vstool_cmd, os.getcwd()) > self.run(vstool_cmd) > > @@ -619,7 +620,7 @@ > raise CommandError('clean takes no arguments') > setup.cleanup() > else: > - print >> sys.stderr, 'Error: unknown command', repr(arg) > + print >> sys.stderr, 'Error: unknown command', repr(cmd) > print >> sys.stderr, "(run 'develop.py --help' for help)" > sys.exit(1) > except CommandError, err: > > > > > On 2008-06-05, at 21:12, Bruce Tong wrote: > >> Yes, I was running that within a bash shell from cygwin. I'm not sure >> why, now that I think about it. Some part of the process had me >> install it. I like bash and I guess it must have been wishful thinking >> on my part, or something. >> >> If I try it from a windows command prompt, I get... >> >> C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 >> Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' >> -- Building with FMOD audio support >> -- Building with FMOD audio support >> -- Version of viewer is 1.20.6.0 >> -- Configuring done >> -- Generating done >> -- Build files have been written to: >> C:/ZZTong/SLDev/linden/indra/build-VC80 >> Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln >> --confi >> g RelWithDebInfo --startup secondlife-bin' in >> 'C:\\ZZTong\\SLDev\\linden\\indra' >> >> Opening solution: build-VC80\SecondLife.sln >> Looking for existing VisualStudio instance... >> Didn't find open solution, now opening new VisualStudio instance... >> Reading .sln file version... >> Opening VS version: VC80... >> Value cannot be null. >> Parameter name: type >> Quitting do error opening: >> C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl >> n >> >> On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> >>> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> >>>> I attempted to build using cmake for the first time. I seem to have >>>> encountered something similar to what Michelle2 Zenovka mentioned in >>>> VWR-6794. I guess that's fitting since I was following her nice >>>> summary found at... >>>> >>>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>>> >>>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>>> >>>> $ ./develop.py -G VC80 >>>> >>> >>> From the $ prompt, are you attempting this with cygwin? What happens >>>> >>> if you try it from a command shell without cygwin in your path? >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> >> >> -- >> Bruce Tong >> Software Engineer >> Office of Information Technology >> Ohio University >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/97273e0c/attachment.htm From dmahalko at gmail.com Fri Jun 6 12:04:18 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 6 12:04:20 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <711493.29841.qm@web34303.mail.mud.yahoo.com> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: It does not look like anyone has ever tried modifying the client to allow the local cache to just grow indefinitely. If unlimited growth of a user's local cache could be tracked, I generally expect that the cache grows in small spurts when a new area is visited, but then growth is either flat or slowly linear once the "hangouts" in the world are established. These growth spurts will be the largest for a new cache just beginning to grow...... but for an established user visiting a new area, the "spurt" might only be a tiny blip since the difference between the new place and all others will be small. While LL must store the entire world, the user only needs to store those very few areas that they visit frequently, plus occasional trips off into new and unusual areas. So even if unlimited cache growth is permitted for testing purposes, the local user's asset storage is only ever going to be a minuscule fraction of LL's asset storage. Also, generally I would expect the client performance to improve by disabling the size limiting and garbage collection. If the only task is inserting new objects into the cache without limit, there is no need to be doing histograms and so forth to try to find the "oldest" content to remove. But of course, I just don't know at what size this local leveling-off will occur, because no one has tried testing any of this yet. This all appears to be trivially easy to start testing, since it just comes down to a few file-delete commands here and there in the source, plus some size limiter tests. So comment out all the deletion and garbage collection procedures, and force the limiters to always permit caching, and we shall see just how big the local cache can grow. Alas I am not a programmer by trade, so I don't have Visual Studio installed, nor am I familiar with subversion. But it looks very easy to do this cache hacking and testing using the existing code, so I may just have to suffer the steep learning curve of compiling to try it myself. I have a brand-new 750 gig SATA drive sitting here, still in the antistatic bag, that has no particular purpose right now (it'll be a backup drive eventually). I suppose I could set it up as my unlimited SL test cache.. :-) - Scalar Tardis / Dale Mahalko From evolutie at gmail.com Fri Jun 6 12:26:46 2008 From: evolutie at gmail.com (evolutie) Date: Fri Jun 6 12:26:50 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4849879D.5000602@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> Message-ID: <5fb4b1fa0806061226j407e6b9bn2b265b99f56d8fab@mail.gmail.com> I would love to see the verse protocol supported somehow... Though I really don't know enough of it to see the implications.. but would be wonderful to work on a texture in gimp or a model in blender and see it updated in SL.. "Verse is a network protocol that lets multiple applications act together as one large application by sharing data over a network. If one application makes a change to shared data, the change is distributed instantly to all the other interested clients. The protocol and associated data format are both heavily optimized for sharing data suitable for 3D graphics. " http://verse.blender.org/ evo On Fri, Jun 6, 2008 at 8:53 PM, Lawson English wrote: > Argent Stonecutter wrote: >> >> I don't think P2P is an option from a privacy perspective anyway. >> _______________________________________________ > > Sure, not for most purposes, but there could be use-cases where P2P was > useful, hence the long-standing proposal that the protocol support informing > the viewer that P2P is available in a given sim/grid and *how* to establish > contact with other participating viewers. This is obviously not a > SL-specific thing, but a private OpenSim grid might be running all sorts of > simulation software, or collaboration software, etc., where P2P makes sense. > From soft at lindenlab.com Fri Jun 6 12:40:23 2008 From: soft at lindenlab.com (Soft) Date: Fri Jun 6 12:40:25 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: > It does not look like anyone has ever tried modifying the client to > allow the local cache to just grow indefinitely. > [...] > > This all appears to be trivially easy to start testing, since it just > comes down to a few file-delete commands here and there in the source, > plus some size limiter tests. So comment out all the deletion and > garbage collection procedures, and force the limiters to always permit > caching, and we shall see just how big the local cache can grow. You may be overthinking this. Simply raising the limit from 1 gig to a much larger number would be sufficient. I wouldn't be surprised if that number were in the xml for the network preferences panel, not the viewer source, even. From Celierra at gmail.com Fri Jun 6 13:05:27 2008 From: Celierra at gmail.com (Celierra Darling) Date: Fri Jun 6 13:05:32 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: > It does not look like anyone has ever tried modifying the client to > allow the local cache to just grow indefinitely. > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the release notes said that that was found to be counterproductive and it was reduced to 1 GB. I can't find that specific release note, but the 1.14 notes do say "unlimited texture cache size". ~Alex and Cel From kfa at gmx.net Fri Jun 6 13:22:59 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 13:23:08 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <48499CA3.203@gmx.net> Celierra Darling wrote: > On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: >> It does not look like anyone has ever tried modifying the client to >> allow the local cache to just grow indefinitely. >> > > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the > release notes said that that was found to be counterproductive and it > was reduced to 1 GB. I can't find that specific release note, but the > 1.14 notes do say "unlimited texture cache size". > > ~Alex and Cel > Counterproductive... hm, we don't know what the poet wanted to tell us with that line. But before there's more speculation, here is where to strike it out (as Soft hinted): panel_preferences_network.xml line 32 - between ' References: <193533.8360.qm@web59104.mail.re1.yahoo.com> Message-ID: <4849ADD8.6010202@lindenlab.com> Hi everyone, I'm sorry I couldn't reply sooner to this thread. I am a member of the search team at LL. The landmarks project will not affect search (technically) at all. This is because landmarks are stored as assets (and not in the database) and because asset storage does not touch the Google Search Appliances (GSAs). The GSAs are physically separate from where assets live. It's possible that the proposed landmarks changes could, for example, affect residents' willingness to use Top Picks. Top Picks is, at present, the most important vote for a place and traffic is a strong second. If residents were to stop or change their usage behavior of Top Picks, for example, then the change in behavior would by extension change search results. This would be true even if the landmarks project weren't happening, of course - it's just that landmarks changes could inspire some residents to change behavior. Down the road, I think landmarks *could* serve as a potential new resource for search - but, to be clear, in the current project they are NOT designed to do this. Later on, though, let's say we have some sort of "favorites designation." We *could possibly* mine that data as a high-quality designation of what residents think is interesting and use it for search results. Again, this is NOT part of the current project plan. We do NOT think this project will lead to different or better search results. Cheers, Stephany Ann Otoole wrote: > My point is simple. > > This work can impact search and the impact on search needs to be > explained. > Or if it is going to negatively impact something then why use time > discussing things that will not be allowed to happen? > > More communication is needed. And how this effort can enhance search > would be a great thing. (I.e.; I suspect everything is converted to > html urls for google appliance indexing anyway so how can this new > navigation work help? will the history of teleports finally be counted > as a form of real traffic into and out of a sim? etc. etc.) > > Don't confuse emotionless straight direct talk with negativism. > > Thanks. > > ----- Original Message ---- > From: Drew Dwi > To: Ann Otoole > Cc: Sarah Hutchinson ; > sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:54:52 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hi, > > Hate to poke my head in, but careful reading is required before harsh > feedback. > > Per Kippie's post (you don't get your own email? the name says Sarah fyi): > > "With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved into, > that it should be left as is." > > I don't see how any of the changes listed below affect search. > > -Drew > > Ann Otoole wrote: > > I previously requested someone look into how this project can impact > > search and there were no replies so I will reiterate: > > > > Profile Picks are part of the new search relevancy. Messing with this > > breaks search. An external non LL contracted team cannot be allowed to > > work on things that will result in devastation of the economy. How > > this can even happen is interesting. Great work and all but who > > decided to allow you to potentially erase the SL economy? > > > > Landmarks were initially listed in the SL blog as being a search > > relevance factor. The entire discussion of removing landmarks should > > have never happened without a discussion of this factor first. > > > > My recommendation is for the LL search related team to pay more > > attention to protecting their turf and communicating with this > > community to ensure everyone understands how this work will or will > > not impact the new search. > > > > > > ----- Original Message ---- > > From: Sarah Hutchinson > > > To: sldev@lists.secondlife.com > > Sent: Thursday, June 5, 2008 11:37:46 AM > > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > > > Hello all! > > > > Thank you so much for your feedback and comments on the Landmarks & > > Navigation project. My name is Kippie Friedkin and I'm a member of the > > Vectorform team. The team has been watching the threads and taking > > into consideration all of your input. We're excited that there has > > been so much interest in this project! Working on an open source > > project is a great learning experience for us, so we've been careful > > to respond with accuracy. Now we'll work on responding with a little > > more speed. As we have begun to define the design and functionality, > > we're better positioned to understand and discuss the technical issues. > > > > I thought I'd begin this note with an update on the project - where > > we've been, where we are, and where we're going. > > > > *Where we've been > > *The project began with a massive research phase that encompassed > > Office Hours discussions, interviews with Residents (both new and > > veteran), scouring Second Life blogs, researching resident-created > > tools, reviewing other Viewers and a host of web apps. > > > > During this phase, it was our goal to learn how Residents navigate > > in-world and how they create, use, and manage Landmarks. We solicited > > feedback on their pain points, ideas, and general comments that > > touched on Inventory, Landmarks, navigation, and User Picks. > > > > At the end of this research phase, we presented our finding to Linden > > Lab as well as some initial mockups and wireframes that would satisfy > > some of the project goals (as stated on the WIKI) as: > > > > * > > > > *To create a history of locations visited*, presented in some > > visual fashion, which may include: > > > > o > > > > Back & forward buttons for teleporting through location > > history > > > > o > > > > Prominent on-screen affordance for accessing/adding Landmarks > > > > * > > > > *To improve the existing, or create a new, system for managing > > Landmarks*, which should support the following: > > > > o > > > > Sorting, re-ordering > > > > o > > > > Organizing into folders or similar > > > > o > > > > Renaming > > > > o > > > > Sharing > > > > o > > > > Tagging > > > > * > > > > *To create a new navigation panel* (ie. the visual container for > > the new UI components) > > > > o > > > > To provide the ability to hide/show this panel. > > > > A few other things were investigated and discussed at the project's > onset: > > > > 1. > > > > Removing Landmarks from Inventory, in favor of a new system for > > managing Landmarks. > > > > 2. > > > > Deprecating Picks or finding some way to make sharing Landmarks > > easier. > > > > Discussions with Residents quickly removed these two items from the > > scope of this project. > > > > Removing Landmarks from the Inventory is an extremely difficult thing > > from to do from an implementation perspective. It also means that one > > of our project requirements - that of backwards compatibility - was > > broken. So it was determined that Landmarks were best left a part of > > the Inventory. As noted, there are many ways a Landmark can end up in > > one's Inventory, and the pros of Landmarks being left where they are, > > very quickly outweighed any cons that currently exist. > > > > With regards to User Picks, we learned that Picks are used for a lot > > more than just sharing of favorite places. It was decided that until > > Second Life offer the more social features that Picks have evolved > > into, that it should be left as is. > > > > *Where we are today > > *The Vectorform team has spent the past few weeks working on > > wireframes and designs for the newly proposed features. > > > > Based on our research, Resident feedback, and meetings with Linden > > Lab, we are building the following features in the Viewer: > > > > 1. > > > > *Navigation Panel* > > The Navigation panel will include forward, back, home and > > history buttons, as well as an address/location text box and > > 'go' button. > > > > The designs are being revised and updated to fit more into the > > new Dazzle style with insight and feedback from Residents and > > Lindens. > > > > The Navigation Panel can be able to be shown or hidden using > > both a small toggle at the top-left of the Viewer as well a > > keyboard shortcut - "/". (We are still determining if this will > > work as a shortcut key, but an initial review indicated it was > > not being used by another UI element - so this is TBD). > > > > In between the back and forward buttons will be a small, history > > button which will allow a Resident to view the list of places > > he/she has visited during that session. The number of places > > stored in this history and whether it persists between sessions > > can be set in ones User Preferences. > > > > The name of the parcel and region will be shown in the location > > history. Mousing over an item in the list will reveal additional > > info (SLURL? How long ago you were there?) > > > > Clicking the back or forward button will automatically teleport > > the Resident back/foward in their location history. > > > > Clicking the home button will teleport the Resident back to > > his/her home location. > > > > Address Bar - The address bar will display a SLURL by default. > > Users can enter a SLURL, or Region name in their Inventory. If > > the Resident types in a Region name that is not in their > > Inventory, we will go a global search to find the location. If > > the location cannot be found, the Search floater will open. > > > > 2. > > > > *User Preferences > > *We are introducing a new tab to the User Preferences floater > > that will providing users the ability to: > > > > * > > > > Set the number of days to store location history > > > > * > > > > Set the number of days to store address bar history > > > > * > > > > Clear the history of either of the above two items > > > > * > > > > Export Landmarks in HTML, TXT, or XML formats > > > > 3. > > > > *Create/Edit Landmarks UI* > > Residents will now be able to add a custom name and stores notes > > when creating or editing a Landmark. There will also be the > > option to select or create a folder when creating/editing > > Landmarks. > > > > All Landmarks and their folders will be will be placed into the > > Landmarks folder in the Inventory floater. > > > > To clear up any confusion, the following circumstances will > > still apply: > > > > * > > > > Landmarks received from purchased objects will remain with > > the object/folder as they are created. > > > > * > > > > Landmarks received view Inventory transfer will be placed > > into a Received Landmarks folder by default, but also > > allow for the Resident to edit and select a folder in > > which to place the Landmark. > > > > * > > > > Landmarks received via automatic givers will also be > > placed into the Received Landmarks folder, by default. > > Still TBD in terms of scoping, but we'd also like to > > include functionality that allows the Resident to edit and > > select a folder in which to place the Landmark. > > > > * > > > > Landmarks embedded in Notecards will not see any change in > > functionality. The landmark will remain embedded in the > > Notecard and not accessible except through Notecard access. > > > > 4. > > > > *Landmarks Menu* > > A new 'Landmarks' menu will be added to the top menu of the > > Viewer. The options for this menu are as follows: > > > > * > > > > Create Landmark > > > > * > > > > Manage Landmarks > > > > * > > > > Set Home to Current Location > > > > * > > > > Teleport Home > > > > * > > > > Received Landmarks - A sub-folder in the Landmarks folder > > in Inventory where all received Landmarks are stored by > > default. > > > > * > > > > Recent Places - Displays a list of Landmarks a Resident > > has recented used. > > > > * > > > > Access to Landmarks located in the Inventory Floater - > > Residents will now have access to Landmarks stored in the > > Landmarks folder of their Inventory via this menu. Any > > sub-folders of the main Landmarks folder will appear in > > this Landmarks menu and be navigable via this menu. > > > > 5. > > > > *Manage Landmarks UI* > > This new UI element is meant to allow residents a filtered via > > of the Inventory, in which to organize and manage (edit/delete) > > Landmarks. It consists of a small floater which will almost look > > like a filter viewed of the Inventory Floater. The Manage > > Landmarks floater will allow Residents to filter Landmarks, > > create/edit/delete folders easily, and provide a place (without > > having to weed through the rest of the Inventory) to edit > Landmarks. > > > > If you've had a chance to look at the wireframe posted on > > NAV-28, there are two approaches to the Manage Landmarks UI. At > > present, we have been asked to proceed with the separated > > floaters approach (Solution 2). > > > > Also, an advanced feature proposed for the Manage Landmarks UI > > was a Data Sort View which would allow Residents to view, sort, > > and manage Landmarks from a column set approach (like iTunes > > > ). However, at this time, we have > > been asked to put that feature on hold since it's real benefit > > has not been clear for all project stakeholders. > > > > When editing a Landmarks, Residents will have the ability to > > specify a custom name, add their own notes to each Landmark. > > Residents will also have the ability to specify a picture they > > want to use for a particular Landmark. Our technical team is > > also reviewing the possibility of allowing a Resident the option > > of using/reverting back to the default image for this location > > (as specified by the Land Owner). It is as of yet undetermined > > if this feature will be in scope. > > > > The Edit Landmarks Floater will include small icons for 'Show on > > Map' and 'Copy SLURL' to provide additional functionality. > > > > Finally, we intend to display additional metadata about the > > Landmark from the Edit Landmark floater - date acquired, last > > teleport date, and last updated date. > > > > *Shared Landmarks & Tagging > > *One of our original ideas (and a common suggestion from Residents) > > has been to include tagging of Landmarks and other Inventory assets. > > We investigated a couple of ways to create a folksonomy use with > > Landmarks in Second Life during the first phase of our project. > > However, it became clear that tagging functionality would be useful > > for many other areas and could touch many other areas including > > search, the web, User Picks, and most Inventory items. Rather than > > build a small one-off tagging system just for Landmarks, it was > > decided that creating a true folksonomy that could be used throughout > > Second Life (For searching, sharing landmarks, creating more a social > > network, etc.) was a much bigger project than our timeline or project > > goals would allow for. So tagging functionality was deemed out of > > scope for this project. > > > > *Where we're going! Issues, Risks, Reviews, and Builds! > > * > > The design team is working closely with Linden Lab and soliciting > > Resident feedback on new designs revisions. We hope to have design > > approachs for the new Nav bar solidifed by the end of this week. > > > > In the meantime, our technical team have been working on laying the > > foundation for the new Navigation bar, as well as spending time > > researching the items which many of you have spoken about on this > > list. A few items for which we're actively researching: > > > > * > > > > Understanding more about SLURLs and their relation to the Agni > > grid and how they come into play with the beta grid(s). > > > > * > > > > How the introduction of a new top-left UI element will affect > > Resident-created HUDs. > > > > * > > > > How the introduction of forward/back button teleport > > functionality will affect grid stability. > > > > In addition to researching open issues, our tech team is also working > > on wrapping up a Viewer build (minus approved creative). We will be > > testing that and reviewing it with Linden Lab over the next week. > > > > I would encourage all of you to continue sharing your thoughts and > > feedback. As I stated at the beginning of this message, the Vectorform > > team will be much more actively engaged with this list moving forward. > > > > Best, > > Kippie Friedkin > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/b1984e7a/attachment-0001.htm From sldev at bitparts.org Fri Jun 6 16:35:57 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Fri Jun 6 16:35:58 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <4849C9DD.9090904@bitparts.org> I really regret missing this meeting - had planned on it, went early & got a LM, and then got too busy at RL work to attend. Further thoughts, after trapesing my way through the source - it /appears/ as though the cache code already supports reading TGA files from the cache - am I correct? Does the cache writing code support writing in TGA? If so, it's just a matter of telling the image fetching code to write out the decompressed version - although I get the feeling that this could be done much more gracefully with a larger rewrite. Alas, I lack the C++ skills for it. Damn LL for not coding in plain C (*snort). Right now, I've bumped the limit on my texture cache size (a la the xml hack posted on another thread), but we're still dealing with the decode delay. I think that's the thing that really needs to be addressed, before further discussion about discard algorithms etc. -Buckaroo From teravus at gmail.com Fri Jun 6 17:24:34 2008 From: teravus at gmail.com (Teravus Ovares) Date: Fri Jun 6 17:24:36 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <34cc66250806061724h4d275d2n5c20033ba0e6d619@mail.gmail.com> Does anyone remember AT&T Worldnet? No? (tried to go back to metered dialup connections back in the day) Best Regards Teravus On 6/3/08, Ann Otoole wrote: > > Time Warner is going to try forcing metered bandwith on the cable modem > community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once > again. > (Presumably because of those few horrid torrent/movie downloaders messing > everything up for the rest of the planet. Yes thats right, instead of > closing off the pipes used by the abusers they choose to make more money by > harming the community in general. Typical Time Warner choice as opposed to > upgrading their antiquated copper wire infrastructure eh? anyway i worry > that heavy SL users (such as content creators) may be about to lose any > further incentive for bothering with virtual worlds...) > > Has anyone measured actual bandwith utilization to the point people can > predict their usage per month before they get slapped with killer bills? > > The reason I mention this is because, although I am also a fan of reduced > compression overhead, there will no doubt be trade offs required. Perhaps > there is a way to make compression/decompression more efficient? > > > ----- Original Message ---- > From: Tateru Nino > To: Dante Tucker > Cc: Second Life Developer Mailing List > Sent: Tuesday, June 3, 2008 1:08:43 PM > Subject: Re: [sldev] Cache speed experiment & results... > > Compromise? A lighterweight compressed cache format? Admittedly, yes, > the textures would still be coming down as jpeg2000 - which means they > would have to be decoded and recompressed before they went in the cache > - which is wasteful. But it's wasteful once per texture transfer, not > once per texture fetched from the cache. > > Use a PNG or vanilla jpg compressor to save space on disk (and let the > user set the compression quality with a slider to let them decide how > much bang-for-the-buck they want out of their chosen megabytes of > storage), then you've got far less work to do decoding than the jpeg2000 > decompressor -- or so I presume. If I got all that fatally wrong, just > whack me with a rolled up man page. > > Dante Tucker wrote: > > I definatly second this as an option. Provided there is no technical > > reason this can't be done :) > > > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > > wrote: > > > > > > > > Given the dirt-cheap price of HD space these days, why bother > > compressing the cache, given that the decode is so expensive > > time-wise? Enlarge the cache maximum size, and toss out the > > compression - at least give us an option to try it, and see. A > > simple checkbox or debug option "UseCompressedCache" or somesuch > > defaulted to yes - then those of us with plenty of space can try > > it out. People are screaming about texture load times - I can't > > imagine they wouldn't sacrifice some disk space for a large boost > > in performance. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/495cc05d/attachment.htm From kerdezixe at gmail.com Fri Jun 6 18:05:38 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jun 6 18:05:41 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <48499CA3.203@gmx.net> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <48499CA3.203@gmx.net> Message-ID: <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> 2008/6/6 Felix Duesenburg : > > panel_preferences_network.xml line 32 > - between ' - there is 'max_val="1000"' > which is the maximum by the slider settable cache size in MB. > i found : Advanced->Debug Setting->CacheSize There is an option "CacheValidateCounter" too but i have no idea of the meaning so i won't touch it :) used in void LLTextureCache::purgeTextures(bool validate) Since ... a long time ago ... i cry for texture saved as TGA (see the wiki about texture cache) and the ability to store texture cache on a separated and optimized server using squid or similar. Overkill for "random user", awesome for company, cybercafe and technonerdogeeky. -- F4FQM Kerunix Flan Laurent Laborde From tateru.nino at gmail.com Fri Jun 6 20:06:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 20:07:25 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4849ADD8.6010202@lindenlab.com> References: <193533.8360.qm@web59104.mail.re1.yahoo.com> <4849ADD8.6010202@lindenlab.com> Message-ID: <4849FB3F.3070604@weblogsinc.com> Was it not said that the landmarks and navigation project would deprecate, then eliminate Top Picks? Stephany Filimon wrote: > Hi everyone, > > I'm sorry I couldn't reply sooner to this thread. > > I am a member of the search team at LL. The landmarks project will > not affect search (technically) at all. This is because landmarks are > stored as assets (and not in the database) and because asset storage > does not touch the Google Search Appliances (GSAs). The GSAs are > physically separate from where assets live. > > It's possible that the proposed landmarks changes could, for example, > affect residents' willingness to use Top Picks. Top Picks is, at > present, the most important vote for a place and traffic is a strong > second. If residents were to stop or change their usage behavior of > Top Picks, for example, then the change in behavior would by extension > change search results. This would be true even if the landmarks > project weren't happening, of course - it's just that landmarks > changes could inspire some residents to change behavior. > > Down the road, I think landmarks *could* serve as a potential new > resource for search - but, to be clear, in the current project they > are NOT designed to do this. Later on, though, let's say we have some > sort of "favorites designation." We *could possibly* mine that data > as a high-quality designation of what residents think is interesting > and use it for search results. > Again, this is NOT part of the current project plan. We do NOT think > this project will lead to different or better search results. > > Cheers, > > Stephany > > Ann Otoole wrote: >> My point is simple. >> >> This work can impact search and the impact on search needs to be >> explained. >> Or if it is going to negatively impact something then why use time >> discussing things that will not be allowed to happen? >> >> More communication is needed. And how this effort can enhance search >> would be a great thing. (I.e.; I suspect everything is converted to >> html urls for google appliance indexing anyway so how can this new >> navigation work help? will the history of teleports finally be >> counted as a form of real traffic into and out of a sim? etc. etc.) >> >> Don't confuse emotionless straight direct talk with negativism. >> >> Thanks. >> >> ----- Original Message ---- >> From: Drew Dwi >> To: Ann Otoole >> Cc: Sarah Hutchinson ; >> sldev@lists.secondlife.com >> Sent: Thursday, June 5, 2008 11:54:52 AM >> Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 >> >> Hi, >> >> Hate to poke my head in, but careful reading is required before harsh >> feedback. >> >> Per Kippie's post (you don't get your own email? the name says Sarah >> fyi): >> >> "With regards to User Picks, we learned that Picks are used for a lot >> more than just sharing of favorite places. It was decided that until >> Second Life offer the more social features that Picks have evolved into, >> that it should be left as is." >> >> I don't see how any of the changes listed below affect search. >> >> -Drew >> >> Ann Otoole wrote: >> > I previously requested someone look into how this project can impact >> > search and there were no replies so I will reiterate: >> > >> > Profile Picks are part of the new search relevancy. Messing with this >> > breaks search. An external non LL contracted team cannot be allowed to >> > work on things that will result in devastation of the economy. How >> > this can even happen is interesting. Great work and all but who >> > decided to allow you to potentially erase the SL economy? >> > >> > Landmarks were initially listed in the SL blog as being a search >> > relevance factor. The entire discussion of removing landmarks should >> > have never happened without a discussion of this factor first. >> > >> > My recommendation is for the LL search related team to pay more >> > attention to protecting their turf and communicating with this >> > community to ensure everyone understands how this work will or will >> > not impact the new search. >> > >> > >> > ----- Original Message ---- >> > From: Sarah Hutchinson > > >> > To: sldev@lists.secondlife.com >> > Sent: Thursday, June 5, 2008 11:37:46 AM >> > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 >> > >> > Hello all! >> > >> > Thank you so much for your feedback and comments on the Landmarks & >> > Navigation project. My name is Kippie Friedkin and I'm a member of the >> > Vectorform team. The team has been watching the threads and taking >> > into consideration all of your input. We're excited that there has >> > been so much interest in this project! Working on an open source >> > project is a great learning experience for us, so we've been careful >> > to respond with accuracy. Now we'll work on responding with a little >> > more speed. As we have begun to define the design and functionality, >> > we're better positioned to understand and discuss the technical issues. >> > >> > I thought I'd begin this note with an update on the project - where >> > we've been, where we are, and where we're going. >> > >> > *Where we've been >> > *The project began with a massive research phase that encompassed >> > Office Hours discussions, interviews with Residents (both new and >> > veteran), scouring Second Life blogs, researching resident-created >> > tools, reviewing other Viewers and a host of web apps. >> > >> > During this phase, it was our goal to learn how Residents navigate >> > in-world and how they create, use, and manage Landmarks. We solicited >> > feedback on their pain points, ideas, and general comments that >> > touched on Inventory, Landmarks, navigation, and User Picks. >> > >> > At the end of this research phase, we presented our finding to Linden >> > Lab as well as some initial mockups and wireframes that would satisfy >> > some of the project goals (as stated on the WIKI) as: >> > >> > * >> > >> > *To create a history of locations visited*, presented in some >> > visual fashion, which may include: >> > >> > o >> > >> > Back & forward buttons for teleporting through location >> > history >> > >> > o >> > >> > Prominent on-screen affordance for accessing/adding >> Landmarks >> > >> > * >> > >> > *To improve the existing, or create a new, system for managing >> > Landmarks*, which should support the following: >> > >> > o >> > >> > Sorting, re-ordering >> > >> > o >> > >> > Organizing into folders or similar >> > >> > o >> > >> > Renaming >> > >> > o >> > >> > Sharing >> > >> > o >> > >> > Tagging >> > >> > * >> > >> > *To create a new navigation panel* (ie. the visual container for >> > the new UI components) >> > >> > o >> > >> > To provide the ability to hide/show this panel. >> > >> > A few other things were investigated and discussed at the project's >> onset: >> > >> > 1. >> > >> > Removing Landmarks from Inventory, in favor of a new system for >> > managing Landmarks. >> > >> > 2. >> > >> > Deprecating Picks or finding some way to make sharing Landmarks >> > easier. >> > >> > Discussions with Residents quickly removed these two items from the >> > scope of this project. >> > >> > Removing Landmarks from the Inventory is an extremely difficult thing >> > from to do from an implementation perspective. It also means that one >> > of our project requirements - that of backwards compatibility - was >> > broken. So it was determined that Landmarks were best left a part of >> > the Inventory. As noted, there are many ways a Landmark can end up in >> > one's Inventory, and the pros of Landmarks being left where they are, >> > very quickly outweighed any cons that currently exist. >> > >> > With regards to User Picks, we learned that Picks are used for a lot >> > more than just sharing of favorite places. It was decided that until >> > Second Life offer the more social features that Picks have evolved >> > into, that it should be left as is. >> > >> > *Where we are today >> > *The Vectorform team has spent the past few weeks working on >> > wireframes and designs for the newly proposed features. >> > >> > Based on our research, Resident feedback, and meetings with Linden >> > Lab, we are building the following features in the Viewer: >> > >> > 1. >> > >> > *Navigation Panel* >> > The Navigation panel will include forward, back, home and >> > history buttons, as well as an address/location text box and >> > 'go' button. >> > >> > The designs are being revised and updated to fit more into the >> > new Dazzle style with insight and feedback from Residents and >> > Lindens. >> > >> > The Navigation Panel can be able to be shown or hidden using >> > both a small toggle at the top-left of the Viewer as well a >> > keyboard shortcut - "/". (We are still determining if this will >> > work as a shortcut key, but an initial review indicated it was >> > not being used by another UI element - so this is TBD). >> > >> > In between the back and forward buttons will be a small, history >> > button which will allow a Resident to view the list of places >> > he/she has visited during that session. The number of places >> > stored in this history and whether it persists between sessions >> > can be set in ones User Preferences. >> > >> > The name of the parcel and region will be shown in the location >> > history. Mousing over an item in the list will reveal additional >> > info (SLURL? How long ago you were there?) >> > >> > Clicking the back or forward button will automatically teleport >> > the Resident back/foward in their location history. >> > >> > Clicking the home button will teleport the Resident back to >> > his/her home location. >> > >> > Address Bar - The address bar will display a SLURL by default. >> > Users can enter a SLURL, or Region name in their Inventory. If >> > the Resident types in a Region name that is not in their >> > Inventory, we will go a global search to find the location. If >> > the location cannot be found, the Search floater will open. >> > >> > 2. >> > >> > *User Preferences >> > *We are introducing a new tab to the User Preferences floater >> > that will providing users the ability to: >> > >> > * >> > >> > Set the number of days to store location history >> > >> > * >> > >> > Set the number of days to store address bar history >> > >> > * >> > >> > Clear the history of either of the above two items >> > >> > * >> > >> > Export Landmarks in HTML, TXT, or XML formats >> > >> > 3. >> > >> > *Create/Edit Landmarks UI* >> > Residents will now be able to add a custom name and stores notes >> > when creating or editing a Landmark. There will also be the >> > option to select or create a folder when creating/editing >> > Landmarks. >> > >> > All Landmarks and their folders will be will be placed into the >> > Landmarks folder in the Inventory floater. >> > >> > To clear up any confusion, the following circumstances will >> > still apply: >> > >> > * >> > >> > Landmarks received from purchased objects will remain with >> > the object/folder as they are created. >> > >> > * >> > >> > Landmarks received view Inventory transfer will be placed >> > into a Received Landmarks folder by default, but also >> > allow for the Resident to edit and select a folder in >> > which to place the Landmark. >> > >> > * >> > >> > Landmarks received via automatic givers will also be >> > placed into the Received Landmarks folder, by default. >> > Still TBD in terms of scoping, but we'd also like to >> > include functionality that allows the Resident to edit and >> > select a folder in which to place the Landmark. >> > >> > * >> > >> > Landmarks embedded in Notecards will not see any change in >> > functionality. The landmark will remain embedded in the >> > Notecard and not accessible except through Notecard access. >> > >> > 4. >> > >> > *Landmarks Menu* >> > A new 'Landmarks' menu will be added to the top menu of the >> > Viewer. The options for this menu are as follows: >> > >> > * >> > >> > Create Landmark >> > >> > * >> > >> > Manage Landmarks >> > >> > * >> > >> > Set Home to Current Location >> > >> > * >> > >> > Teleport Home >> > >> > * >> > >> > Received Landmarks - A sub-folder in the Landmarks folder >> > in Inventory where all received Landmarks are stored by >> > default. >> > >> > * >> > >> > Recent Places - Displays a list of Landmarks a Resident >> > has recented used. >> > >> > * >> > >> > Access to Landmarks located in the Inventory Floater - >> > Residents will now have access to Landmarks stored in the >> > Landmarks folder of their Inventory via this menu. Any >> > sub-folders of the main Landmarks folder will appear in >> > this Landmarks menu and be navigable via this menu. >> > >> > 5. >> > >> > *Manage Landmarks UI* >> > This new UI element is meant to allow residents a filtered via >> > of the Inventory, in which to organize and manage (edit/delete) >> > Landmarks. It consists of a small floater which will almost look >> > like a filter viewed of the Inventory Floater. The Manage >> > Landmarks floater will allow Residents to filter Landmarks, >> > create/edit/delete folders easily, and provide a place (without >> > having to weed through the rest of the Inventory) to edit >> Landmarks. >> > >> > If you've had a chance to look at the wireframe posted on >> > NAV-28, there are two approaches to the Manage Landmarks UI. At >> > present, we have been asked to proceed with the separated >> > floaters approach (Solution 2). >> > >> > Also, an advanced feature proposed for the Manage Landmarks UI >> > was a Data Sort View which would allow Residents to view, sort, >> > and manage Landmarks from a column set approach (like iTunes >> >> > ). However, at this time, we have >> > been asked to put that feature on hold since it's real benefit >> > has not been clear for all project stakeholders. >> > >> > When editing a Landmarks, Residents will have the ability to >> > specify a custom name, add their own notes to each Landmark. >> > Residents will also have the ability to specify a picture they >> > want to use for a particular Landmark. Our technical team is >> > also reviewing the possibility of allowing a Resident the option >> > of using/reverting back to the default image for this location >> > (as specified by the Land Owner). It is as of yet undetermined >> > if this feature will be in scope. >> > >> > The Edit Landmarks Floater will include small icons for 'Show on >> > Map' and 'Copy SLURL' to provide additional functionality. >> > >> > Finally, we intend to display additional metadata about the >> > Landmark from the Edit Landmark floater - date acquired, last >> > teleport date, and last updated date. >> > >> > *Shared Landmarks & Tagging >> > *One of our original ideas (and a common suggestion from Residents) >> > has been to include tagging of Landmarks and other Inventory assets. >> > We investigated a couple of ways to create a folksonomy use with >> > Landmarks in Second Life during the first phase of our project. >> > However, it became clear that tagging functionality would be useful >> > for many other areas and could touch many other areas including >> > search, the web, User Picks, and most Inventory items. Rather than >> > build a small one-off tagging system just for Landmarks, it was >> > decided that creating a true folksonomy that could be used throughout >> > Second Life (For searching, sharing landmarks, creating more a social >> > network, etc.) was a much bigger project than our timeline or project >> > goals would allow for. So tagging functionality was deemed out of >> > scope for this project. >> > >> > *Where we're going! Issues, Risks, Reviews, and Builds! >> > * >> > The design team is working closely with Linden Lab and soliciting >> > Resident feedback on new designs revisions. We hope to have design >> > approachs for the new Nav bar solidifed by the end of this week. >> > >> > In the meantime, our technical team have been working on laying the >> > foundation for the new Navigation bar, as well as spending time >> > researching the items which many of you have spoken about on this >> > list. A few items for which we're actively researching: >> > >> > * >> > >> > Understanding more about SLURLs and their relation to the Agni >> > grid and how they come into play with the beta grid(s). >> > >> > * >> > >> > How the introduction of a new top-left UI element will affect >> > Resident-created HUDs. >> > >> > * >> > >> > How the introduction of forward/back button teleport >> > functionality will affect grid stability. >> > >> > In addition to researching open issues, our tech team is also working >> > on wrapping up a Viewer build (minus approved creative). We will be >> > testing that and reviewing it with Linden Lab over the next week. >> > >> > I would encourage all of you to continue sharing your thoughts and >> > feedback. As I stated at the beginning of this message, the Vectorform >> > team will be much more actively engaged with this list moving forward. >> > >> > Best, >> > Kippie Friedkin >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From robin.cornelius at gmail.com Sat Jun 7 00:20:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jun 7 00:20:23 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <48499CA3.203@gmx.net> <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> Message-ID: <484A36B5.6040803@gmail.com> Laurent Laborde wrote: > i found : > Advanced->Debug Setting->CacheSize > > There is an option "CacheValidateCounter" too but i have no idea of > the meaning so i won't touch it :) > used in void LLTextureCache::purgeTextures(bool validate) > > Since ... a long time ago ... i cry for texture saved as TGA (see the > wiki about texture cache) > and the ability to store texture cache on a separated and optimized > server using squid or similar. > > Overkill for "random user", awesome for company, cybercafe and technonerdogeeky. > With the current fetch system squid is not really direct useful, without miss-appropriating it some what, if we go http textures via caps then may be it would be useful but would need an slproxy instance as well. I was going to do a mysql cache, i've already done some mods so it should be a trivial next step for me. I greatly expect for a single client the performance to be worse but as the number of local clients increase and if the db server is thrown a lot of memory it may level out and could help reduce total data download. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080607/de86436b/signature.pgp From dmahalko at gmail.com Sat Jun 7 00:27:41 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 7 00:27:42 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: There is performance value in disabling (some) file deletion procedures in the client. For example, I know what a DSF temporary cache file is. There is currently no wiki article about DSF's. Should I create such an article? Should I explain in perfectly clear terms to anyone who cares to read it what can be done with a DSF? Or does LL prefer this remain a "don't ask, don't tell" sort of topic? Do you (LL staff in general) want security through obscurity, or are we going to be honest and open about file/data formats in the \cache folder? I see a very nice specific client performance improvement by no longer deleting DSFs, even if they are a space hog. The client kills them on exit, normally, which is rather annoying: http://svn.secondlife.com/trac/linden/browser/release/indra/newview/llappviewer.cpp 1184 // delete some of the files left around in the cache. 1185 removeCacheFiles("*.wav"); 1186 removeCacheFiles("*.tmp"); 1187 removeCacheFiles("*.lso"); 1188 removeCacheFiles("*.out"); 1189 removeCacheFiles("*.dsf"); 1190 removeCacheFiles("*.bodypart"); 1191 removeCacheFiles("*.clothing"); Fortunately I found a way to prevent DSF deletion, even without recompiling the source, thanks to special NTFS permissions: http://img528.imageshack.us/my.php?image=shotclientinthefootcu0.png Too bad these DSFs don't get their own folder alongside the \textures folder. - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 2:40 PM, Soft wrote: > You may be overthinking this. Simply raising the limit from 1 gig to a > much larger number would be sufficient. I wouldn't be surprised if > that number were in the xml for the network preferences panel, not the > viewer source, even. > From robin.cornelius at gmail.com Sat Jun 7 00:37:52 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jun 7 00:37:55 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <484A3AD0.3040409@gmail.com> Dale Mahalko wrote: > For example, I know what a DSF temporary cache file is. There is > currently no wiki article about DSF's. Should I create such an > article? Should I explain in perfectly clear terms to anyone who cares > to read it what can be done with a DSF? Or does LL prefer this remain > a "don't ask, don't tell" sort of topic? Do you (LL staff in general) > want security through obscurity, or are we going to be honest and open > about file/data formats in the \cache folder? This is a whole topic on its own. We really need some general Linden input on this. I'm not currently prepare to release any patches that open these formats up to casual picking of files nor do my releases have such patches even though its a trivial patch. > > I see a very nice specific client performance improvement by no longer > deleting DSFs, even if they are a space hog. The client kills them on > exit, normally, which is rather annoying: Yes, i am about to start testing this aspect too but someone reported that some things can get cached corrupt which is annoying and we would have no way to remove them at present. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080607/d44aba49/signature.pgp From sarah77 at gmail.com Sat Jun 7 04:55:46 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Sat Jun 7 04:55:49 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4849FB3F.3070604@weblogsinc.com> References: <193533.8360.qm@web59104.mail.re1.yahoo.com> <4849ADD8.6010202@lindenlab.com> <4849FB3F.3070604@weblogsinc.com> Message-ID: <9010c35c0806070455j1adb57bbn4e22f5eb0e04256e@mail.gmail.com> On Fri, Jun 6, 2008 at 11:06 PM, Tateru Nino wrote: > Was it not said that the landmarks and navigation project would deprecate, > then eliminate Top Picks? > The idea to remove Profile Picks was introduced as an area for discussion at the beginning of the project. However, almost immediately after the first or second Office Hour during which we discussed how Residents use Profile Picks, we learned that Profile Picks are used not just to share a favorite place, but to mark friends, memorials, favorite quotes, tutorials, help, classifieds for stores, and more. It was decided that it does not make sense to remove Profile Picks at this time because Residents have changed their intended use into a social networking-like tool. Until more social features could be introduced in the Viewer, Residents made it clear they didn't want to lose Profile Picks. So removing/deprecating/eliminating Profile Picks was removed as a project goal. - Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080607/d1fa9349/attachment.htm From aimee at ama-zing.co.uk Sat Jun 7 07:07:06 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Jun 7 07:07:11 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> Message-ID: <172A0D95-5CCC-4F28-BCC5-420085EE3A15@ama-zing.co.uk> On Jun 6, 2008, at 19:35, Jacek Antonelli wrote: > I think having the small button visible by default is important from a > usability standpoint. I'm thinking particularly of "discoverability" > -- users see the button, click it to find out what it does, and thus > discover that the functionality exists. Otherwise, the majority of > users wouldn't even know about it, which dampens the usefulness of the > project. Very true I guess, I think I was meaning more that it needs to be incorporated into the menu bar in some way rather than being out in the main window. Along the lines of the button in the top right of the title bar on Mac application windows that toggles all the toolbars. > Happily, that's a long term UI goal. :-) > > http://wiki.secondlife.com/wiki/User_Interface_Improvements Oh yes, I'd forgotten that, I remember looking at that screen shot and getting my hopes up before ^^ interestingly, having held up Adobe as a random icon of UI design yesterday, the first thing I read today is http://blogs.adobe.com/ jnack/2008/06/future_photoshop_ui.html ... defending the reasoning behind some of their upcoming changes in CS4 :) Aimee. From secret.argent at gmail.com Sat Jun 7 08:54:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 08:53:02 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <5C84BA56-605D-4FF8-AD2A-33D72CD9B4E0@gmail.com> Apologies for the lateness of this response, we have been very busy at work this week and I have not been able to get in world, let alone catch up on my mail, for some time. On 2008-06-05, at 10:37, Sarah Hutchinson wrote: > A new 'Landmarks' menu will be added to the top menu of the Viewer. > The options for this menu are as follows: > Create Landmark > > Manage Landmarks > > Set Home to Current Location > > Teleport Home > > Received Landmarks > > Recent Places > > Access to Landmarks located in the Inventory Floater - Residents > will now have access to Landmarks stored in the Landmarks folder of > their Inventory via this menu. Any sub-folders of the main > Landmarks folder will appear in this Landmarks menu and be > navigable via this menu. > This all looks good. I would like to have an additional menu item here: "Landmarks Floater", instead of having a permanent tab on the screen. > Also, an advanced feature proposed for the Manage Landmarks UI was > a Data Sort View which would allow Residents to view, sort, and > manage Landmarks from a column set approach (like iTunes). However, > at this time, we have been asked to put that feature on hold since > it's real benefit has not been clear for all project stakeholders. > I like this view, I would just like to have it available for all asset types. Will the additional information in a landmark be part of the landmark and transferred with the landmark if it is given to a third party? Would it be possible to make the picture display on the landmark floater optional, to save screen space? > How the introduction of a new top-left UI element will affect > Resident-created HUDs. This is why I would rather the landmark floater be activated from the menu, like the other floaters, and be located anywhere, like the other floaters. From secret.argent at gmail.com Sat Jun 7 08:56:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 08:55:18 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: <0246F3B5-FE0E-4A74-A774-CEEF1E91ED74@gmail.com> On Thu, Jun 5, 2008 at 8:01 PM, Sarah Hutchinson wrote: > I apologize for the confusion - while the SLURL has been discussed > as the default, you will also be able to type a Region name. How about having it *display* the region name? Possibly because the region name is at the top of the screen anyway? What about making the region name in the title bar editable, instead? From secret.argent at gmail.com Sat Jun 7 09:06:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:05:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48493385.4050008@signpostmarv.name> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> <48493385.4050008@signpostmarv.name> Message-ID: <5D0D3D39-2C29-4B3C-8881-2A783007C830@gmail.com> On 2008-06-06, at 07:54, SignpostMarv Martin wrote: > Aside from llParcelMediaCommandList() with the > PARCEL_MEDIA_COMMAND_AGENT flag set. You can't get information _about me_ that way, because I don't have streaming media turned on. Nor do an increasing number of other people who are aware that streaming media can reveal that information. > Argent Stonecutter wrote: >> Email doesn't happen inside SL. There is currently no way for you >> to get that information about me *within second life* and use it >> to determine that any member of my family is using SL from the >> same IP address and figure out who they are in SL. None. Zippo. >> Zero. That SHOULD NOT change. From secret.argent at gmail.com Sat Jun 7 09:10:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:09:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48493DF8.4040003@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> <48493DF8.4040003@gmail.com> Message-ID: <144FC2CF-B027-4A1F-910B-0CD5436EC83E@gmail.com> On 2008-06-06, at 08:39, Jason Giglio wrote: > Don't get all nitpicky. The use of the term "bandwidth" to mean > "speed > limit" is already an abuse of an engineering term that had a specific, > mostly unrelated meaning. I would not have any compunctions about using "speed limit" as an analogy for bandwidth when talking to a non-technical person, any more than I would have compunctions about referring to the speed of light that way, even though it's not precisely correct either way. Using "bandwidth" to refer to a quantity of data, rather than a rate of data flow, is more than merely imprecise, it's inaccurate. From secret.argent at gmail.com Sat Jun 7 09:16:11 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:14:48 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <18E99479-EA5B-43C9-B801-9F0A006B6C18@gmail.com> On 2008-06-06, at 10:25, Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer > which will allow you to show and hide the nav bar as you want. Can I drag the nav bar? If I drag the nav bar, will the toggle move? Or can I drag the toggle? If the answer in either case is "no", wouldn't that be a fairly obvious enhancement that would avoid many of the issues with HUD conflicts? Speaking of which, how about applying the same technology to the location of minimized floaters? Have a tab at the edge of the area where minimized floaters are. Click it, and the minimized floaters are hidden, and the tab gets a number showing how many minimized floaters it holds. Drag it, and you can change where the minimized floaters show up. From secret.argent at gmail.com Sat Jun 7 09:24:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:23:21 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> Message-ID: <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> On 2008-06-06, at 11:31, Richard Nelson wrote: > The inventory fetch is scheduled one folder at a time. Any time > you explicitly open a folder, the request for the contents of that > folder are put at the top of the queue, so you should see the > contents appear quickly. But as long as you see the number of > fetched items being reported at the top of the inventory window, > then the entire thing is being downloaded. That means that only pulling in the landmarks folder for the map would have the following advantages: 1. It would reduce clutter in the pulldown from the map. 2. It could be fetched quicker, showing a complete view sooner. I'm not asking you to "delicately step around having my inventory available". I'm suggesting an additional advantage of restricting the map pulldown to the Landmarks folder, beyond the primary goal of reducing clutter. :) From secret.argent at gmail.com Sat Jun 7 09:49:48 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:48:26 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <484980A4.1020708@gmx.net> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <484980A4.1020708@gmx.net> Message-ID: On 2008-06-06, at 13:23, Felix Duesenburg wrote: > Did anyone take a closer look at Blender's UI beyond an initial > "Hoooo!" and shying away? I spent a week and change working with it before shying away. From secret.argent at gmail.com Sat Jun 7 09:55:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:53:37 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> Message-ID: On 2008-06-06, at 13:35, Jacek Antonelli wrote: > I think having the small button visible by default is important from a > usability standpoint. I'm thinking particularly of "discoverability" > -- users see the button, click it to find out what it does, and thus > discover that the functionality exists. Otherwise, the majority of > users wouldn't even know about it, which dampens the usefulness of the > project. This is the same logic that led to the search box in the menu bar, when there was already a search button on the screen. The usefulness of a project shouldn't be just based on "how many people use this particular feature" but also "how well does this fit into the rest of the system", because there's always going to be SOME feature set that you don't use, whoever you are, and if you can't get it out of your face it's annoying. They eventually made the search box optional. Nothing should sit between the chat bar and the menu bar that isn't optional. Anything between the chat bar and the menu bar should be movable. From secret.argent at gmail.com Sat Jun 7 09:58:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:57:19 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4849879D.5000602@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> Message-ID: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> On 2008-06-06, at 13:53, Lawson English wrote: > Sure, not for most purposes, but there could be use-cases where P2P > was useful, hence the long-standing proposal that the protocol > support informing the viewer that P2P is available in a given sim/ > grid and *how* to establish contact with other participating viewers. One thing to keep in mind: there's not that many viewers in a sim anyway. We need an inter-viewer "data bus" for low volume data sharing between viewers in range, that's mediated through the sim. I think puppeteering info is small enough to count as "low volume". For higher volume data transfer, let the viewers share P2P contact information through this bus, subject to user request and approval. From secret.argent at gmail.com Sat Jun 7 10:02:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 10:01:24 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On 2008-06-06, at 15:05, Celierra Darling wrote: > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the > release notes said that that was found to be counterproductive and it > was reduced to 1 GB. On the other hand there has been a switch to a new texture cache format since then. From kfa at gmx.net Sat Jun 7 10:19:05 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Jun 7 10:19:18 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> Message-ID: <484AC309.1010803@gmx.net> Argent Stonecutter wrote: > ... > > For higher volume data transfer, let the viewers share P2P contact > information through this bus, subject to user request and approval. > Sounds good from a technical viewpoint, but couldn't this open another can of worms? I could imagine that in SL, to a higher degree even than on the www, people are icky about privacy and wouldn't want to reveal their IP addresses to untrusted parties. If you use P2P networks then you (ought to) know what you're doing, but with SL you didn't bargain for that actually. Even with explicit approval - if declining means you can't use some functionality, then this is a double-edged sword. From sldev at bitparts.org Sat Jun 7 10:31:01 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 10:31:02 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <484AC5D5.4060608@bitparts.org> I've done some more testing, and I don't like what I see. I set my texture cache to 50GB (using the xml hack posted earlier). I went home, moved around and fetched all of the textures around my home - got up to about 39MB. TPed to a shopping sim, wandered around letting lots of stuff fetch, and saw it increase to about 300MB. Good, good. TPed home, let everything rez... checked my cache... and it's back down to 50MB. Stuff is getting discarded from the disk cache even when it's nowhere near full. Is this intended? If so, why? -Jim From sldev at bitparts.org Sat Jun 7 10:34:20 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 10:34:20 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <484AC5D5.4060608@bitparts.org> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <484AC5D5.4060608@bitparts.org> Message-ID: <484AC69C.8040305@bitparts.org> Buckaroo Mu wrote: > I've done some more testing, and I don't like what I see. I set my > texture cache to 50GB (using the xml hack posted earlier). I went > home, moved around and fetched all of the textures around my home - > got up to about 39MB. TPed to a shopping sim, wandered around letting > lots of stuff fetch, and saw it increase to about 300MB. Good, good. > TPed home, let everything rez... checked my cache... and it's back > down to 50MB. Stuff is getting discarded from the disk cache even when > it's nowhere near full. Is this intended? If so, why? > I should clarify - I'm checking the "textures" folder of my cache folder, not the total "cache" folder. From secret.argent at gmail.com Sat Jun 7 10:41:10 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 10:40:12 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484AC309.1010803@gmx.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484AC309.1010803@gmx.net> Message-ID: <6647DE62-2129-406D-87A0-C381A2BA4844@gmail.com> On 2008-06-07, at 12:19, Felix Duesenburg wrote: > Argent Stonecutter wrote: >> For higher volume data transfer, let the viewers share P2P contact >> information through this bus, subject to user request and approval. > > Sounds good from a technical viewpoint, but couldn't this open > another can of worms? I could imagine that in SL, to a higher > degree even than on the www, people are icky about privacy and > wouldn't want to reveal their IP addresses to untrusted parties. That's why "subject to user request and approval". You would have to turn on "P2P support" the way you have to turn on "streaming media" now. You would have to click some icon to approve each new P2P request. Of course a plugin or custom viewer might decide not to cooperate with this, but plugins can already decide not to cooperate with any of the restrictions in SL, so I don't see that as being a new problem. > If you use P2P networks then you (ought to) know what you're doing, > but with SL you didn't bargain for that actually. Even with > explicit approval - if declining means you can't use some > functionality, then this is a double-edged sword. That's true, and that's already an issue with streaming media and external HTTP requests (which I routinely deny). I'm proposing this because it provides the required functionality for the more common case of synchronizing actions between viewers without opening up the P2P can of worms for the easy case. From kerdezixe at gmail.com Sat Jun 7 10:45:52 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Jun 7 10:45:53 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache Message-ID: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> I'm playing with 010 Editor, which is a powerfull Hex editor. (but not free, not opensource, and 100% Windows). i use it as a toy, but can be used to read/edit/write/parse/whatever (it have a script engine) binary file, disk, and process heap. (kinda the ultimate hacker's tool, but it's not my purpose here). I'll use it to make some... statitics about the cache. And maybe create an "offline cache cleaning tool". (MANY people clean their cache at startup, maybe they won't do that anymore if they have some kind of "Cache Defragmenter Super+ Gold Edition Bundle pack") Anyway... it's for my own pleasure to do some geeky stuff. Here is the template file : Nothing less, nothing more, it display all the texture.entries data, uncluding a shiny reformating to display the texture UUID : //-------------------------------------- //--- 010 Editor v3.0 Binary Template // // File: ReadTextureEntries.bt // Author: kerunix Flan // Revision: r1 // Purpose: Playing with texture.entries SL Texture Cache //-------------------------------------- typedef ubyte LLUUID[16]; typedef struct { float mVersion; // Version of ... something ? uint32 mEntries; // Number of entries. } EntriesHeader ; typedef struct { LLUUID mID; // 128 bits int32 mSize; // total size of image if known (NOT size cached), or -1 if unknown time_t mTime; // seconds since 1/1/1970 } EntriesBody ; string ReadEntriesBody( EntriesBody &body) { string s; SPrintf(s,"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",body.mID[0],body.mID[1],body.mID[2],body.mID[3],body.mID[4],body.mID[5],body.mID[6],body.mID[7],body.mID[8],body.mID[9],body.mID[10],body.mID[11],body.mID[12],body.mID[13],body.mID[14],body.mID[15]); return s; } string ReadEntriesHeader (EntriesHeader &head) { string s; SPrintf(s,"Version = %f, Entries = %u", head.mVersion, head.mEntries); return s; } EntriesHeader header; EntriesBody body[header.mEntries]; //------------------------ Note : It doesn't help at all to "steal" cached texture and i'll never release that kind of tool. Note2 : what's the purpose of separating headers from bodies ? Secure-obscurity ? Note3 : what is the mVersion ? Version of the file structure ? Note4 : BareRose HQ is a wonderfull place to stresstest the texture cache. Bigger-note : What about storing cache *per sim* ? Most peoples always go in the same dozen of sim 99% of time and a lot of texture are unique to the sim. When you enter in a sim, just load the *entire* cache related to this sim and discard later the unused texture. Could it save time ? (pre-decoding ?) That's all... have fun :) -- F4FQM Kerunix Flan Laurent Laborde From dmahalko at gmail.com Sat Jun 7 13:36:27 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 7 13:36:30 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: It looks like the setting in XML is forced down to 1 gigabyte: http://svn.secondlife.com/trac/linden/browser/release/indra/newview/llappviewer.cpp 2624 LLSplashScreen::update("Initializing Texture Cache..."); 2625 2626 // Init the texture cache 2627 // Allocate 80% of the cache size for textures 2628 BOOL read_only = mSecondInstance ? true : false; 2629 const S32 MB = 1024*1024; 2630 S64 cache_size = (S64)(gSavedSettings.getU32("CacheSize")) * MB; 2631 const S64 MAX_CACHE_SIZE = 1024*MB; 2632 cache_size = llmin(cache_size, MAX_CACHE_SIZE); 2633 S64 texture_cache_size = ((cache_size * 8)/10); 2634 S64 extra = LLAppViewer::getTextureCache()->initCache(LL_PATH_CACHE, texture_cache_size, read_only); 2635 texture_cache_size -= extra; 2636 2637 LLSplashScreen::update("Initializing VFS..."); 2638 2639 // Init the VFS 2640 S64 vfs_size = cache_size - texture_cache_size; 2641 const S64 MAX_VFS_SIZE = 1024 * MB; // 1 GB 2642 vfs_size = llmin(vfs_size, MAX_VFS_SIZE); So, max cache size = 1024 * 1024 * 1024 = 1 gigabyte Texture cache size = 80% VFS cache size = 20% - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 2:40 PM, Soft wrote: > You may be overthinking this. Simply raising the limit from 1 gig to a > much larger number would be sufficient. I wouldn't be surprised if > that number were in the xml for the network preferences panel, not the > viewer source, even. > From richard at lindenlab.com Sat Jun 7 14:50:57 2008 From: richard at lindenlab.com (Richard Nelson) Date: Sat Jun 7 14:51:01 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> Message-ID: On Sat, 07 Jun 2008 09:24:44 -0700, Argent Stonecutter wrote: > > That means that only pulling in the landmarks folder for the map would > have the following advantages: > > 1. It would reduce clutter in the pulldown from the map. > 2. It could be fetched quicker, showing a complete view sooner. > > I'm not asking you to "delicately step around having my inventory > available". I'm suggesting an additional advantage of restricting the > map pulldown to the Landmarks folder, beyond the primary goal of > reducing clutter. :) Ok, my apologies. It seems we agree in principle then. I was speaking to the overall behavior of inventory fetching, not to the specific behavior of the landmarks dropdown in the map. I agree that the current implementation is not terribly usable, and your suggestion sounds reasonable to me, personally. Off the wall idea here...how about a hybrid inventory view/dropdown? What you see at first is a text entry box with an arrow next to it. But what you type in the text field doesn't just perform a match against the first characters of each entry, like a typical combo box, but instead performs a filter operation against all landmarks in your inventory. And instead of popping up a flat list of landmarks, we pop up a filtered inventory view? This would provide a better search mechanism using the existing inventory behavior, and allow you to scan by folder, etc. Under the hood, we could let you change the filter rules for that dropdown to only scan a certain folder, and so on. Just a thought. R. From secret.argent at gmail.com Sat Jun 7 15:14:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 15:13:32 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> Message-ID: <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> On 2008-06-07, at 16:50, Richard Nelson wrote: > Ok, my apologies. It seems we agree in principle then. I was > speaking to the overall behavior of inventory fetching, not to the > specific behavior of the landmarks dropdown in the map. I agree > that the current implementation is not terribly usable, and your > suggestion sounds reasonable to me, personally. I understand, it's easy to get off on a tangent in email, and I was kind of getting off on one. > Off the wall idea here...how about a hybrid inventory view/ > dropdown? What you see at first is a text entry box with an arrow > next to it. But what you type in the text field doesn't just > perform a match against the first characters of each entry, like a > typical combo box, but instead performs a filter operation against > all landmarks in your inventory. Hmmm, so when you pull down the inventory you get your Landmarks folder, but when you search it searched all your inventory? That would give you the best of both worlds, perhaps. I don't think I'd really care about where the landmarks were in my inventory in that case, so having it go into a folder view pulldown is probably unnecessary yak shaving. Leave the more complex view for the inventory folder or the landmarks floater. ... You know, though, this does give me an idea... What about making the landmarks navigation bar associated with the map somehow? Move the region search entry to the top, like a search box, and put forward/back buttons next to it, and let it accept slurls or Region Name (X,Y,Z) or secondlife: urls. Then you don't have to worry about forward/back teleporting and stuff, all it would do would be move the destination dot around on the map until you hit teleport. Like, at the top of the map you'd have a navigation bar like this: +----------------- | (<) (>) [ Region (X, Y, Z) _____________________ ] (Search) (Copy) (Teleport) [Landmarks _____ |v] [Friends ________ |v] Layout not precise, but you get the idea, yesno? From sldev at bitparts.org Sat Jun 7 15:24:32 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 15:24:32 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <484AC69C.8040305@bitparts.org> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <484AC5D5.4060608@bitparts.org> <484AC69C.8040305@bitparts.org> Message-ID: <484B0AA0.3010402@bitparts.org> >> I've done some more testing, and I don't like what I see. I set my >> texture cache to 50GB (using the xml hack posted earlier). I went >> home, moved around and fetched all of the textures around my home - >> got up to about 39MB. TPed to a shopping sim, wandered around letting >> lots of stuff fetch, and saw it increase to about 300MB. Good, good. >> TPed home, let everything rez... checked my cache... and it's back >> down to 50MB. Stuff is getting discarded from the disk cache even >> when it's nowhere near full. Is this intended? If so, why? >> > I should clarify - I'm checking the "textures" folder of my cache > folder, not the total "cache" folder. > Further testing. When I log in, my cache... goes away. All of those textures are wiped. Or at least most of them - I'm down to a few megabytes, when I stand at my login spot. The discard algorithm is DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded (apparently, as disclosed in another thread) limit. From evolutie at gmail.com Sat Jun 7 15:27:08 2008 From: evolutie at gmail.com (evolutie) Date: Sat Jun 7 15:27:10 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> I finally got around to test with multiple clients logged on to aditi puppeteering, and unfortunetely the simulation doesn't seem to work. Seems like instead of simulating the movement of the joints, the direction in which the avatar looks is simulated. To illustrate: http://www.evolutie.org/movies/puppet1.mov shows me moving my hand http://www.evolutie.org/movies/puppet2.mov shows what this looks like to another client evo . > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > From missannotoole at yahoo.com Sat Jun 7 15:53:58 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat Jun 7 15:54:01 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed Message-ID: <26449.37698.qm@web59103.mail.re1.yahoo.com> Sounds like a defect in need of a pjira entry because there is no shortage of people noticing constant texture reloading. This eats bytes transferred and SL needs to tighten these bolts up before Time Warner deploys that dumb so-called "bandwith cap" (bytes transferred cap". Good catch. Optimally speaking, I should not have to reload textures from the same sim I am in almost exclusively. (I don't get out much lol) On a side note and in respect to textures and size impact... Anyone ever look at the math for a "sub optimal" sim with 15,000 textures at max size? That would be the worst case scenario for cache size per sim. Even 15,000 512*512 textures is a whole lot. And thats not counting avatars. So yea cache needs to be much larger and very efficient. Otherwise everyone on time warner will be switching to DSL lol. Probably will be switching to DSL anyway as a matter of principal if the upper limit is too restrictive. ----- Original Message ---- From: Buckaroo Mu >Further testing. When I log in, my cache... goes away. All of those >textures are wiped. Or at least most of them - I'm down to a few >megabytes, when I stand at my login spot. The discard algorithm is >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded >(apparently, as disclosed in another thread) limit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080607/f8ca679b/attachment.htm From lenglish5 at cox.net Sat Jun 7 16:47:13 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 7 16:47:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> Message-ID: <484B1E01.1010800@cox.net> Argent Stonecutter wrote: > On 2008-06-06, at 13:53, Lawson English wrote: >> Sure, not for most purposes, but there could be use-cases where P2P >> was useful, hence the long-standing proposal that the protocol >> support informing the viewer that P2P is available in a given >> sim/grid and *how* to establish contact with other participating >> viewers. > > One thing to keep in mind: there's not that many viewers in a sim anyway. > > We need an inter-viewer "data bus" for low volume data sharing between > viewers in range, that's mediated through the sim. > > I think puppeteering info is small enough to count as "low volume". With reverse http, the normal data requests via the GetEvent CAP should be plenty fast for "low volume." The server will simply POST each new event as it gets it to the veiwer's faux-POST/GET server. > > For higher volume data transfer, let the viewers share P2P contact > information through this bus, subject to user request and approval. > > _ Doable, I'm sure, but as Felix points out, opting out of it will cripple functionality in a given region/sim/grid and opting in, would provide some loss of privacy. Lawson From secret.argent at gmail.com Sat Jun 7 17:13:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 17:12:14 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484B1E01.1010800@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> Message-ID: <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> On 2008-06-07, at 18:47, Lawson English wrote: > Doable, I'm sure, but as Felix points out, opting out of it will > cripple functionality in a given region/sim/grid Why? All that will mean is that whatever optional feature that uses P2P can't be used. That's hardly crippling. From richard at lindenlab.com Sat Jun 7 17:30:05 2008 From: richard at lindenlab.com (Richard Nelson) Date: Sat Jun 7 17:30:08 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> Message-ID: On Sat, 07 Jun 2008 15:14:44 -0700, Argent Stonecutter wrote: > Hmmm, so when you pull down the inventory you get your Landmarks folder, > but when you search it searched all your inventory? That would give you > the best of both worlds, perhaps. I don't think I'd really care about > where the landmarks were in my inventory in that case, so having it go > into a folder view pulldown is probably unnecessary yak shaving. Sorry, let me clarify. I was thinking that *whatever* was decided (by tweaking the XUI or settings files) to be relevant for the dropdown, whether that is just your Landmarks folder or all landmarks in your inventory, the text you type in the entry field would filter/search just those contents. This is better than the current dropdown because you get substring searching instead of just prefix (which, IMO, is more usable), and you get to see your folders (based on your filter rules) if, like me, you can't be bothered to maintain a single Landmarks folder that has everything you may want to search for in the map window. Anyway, just an idea. Richard From sldev at bitparts.org Sat Jun 7 17:39:33 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 17:39:34 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <26449.37698.qm@web59103.mail.re1.yahoo.com> References: <26449.37698.qm@web59103.mail.re1.yahoo.com> Message-ID: <484B2A45.4050805@bitparts.org> Filed as VWR-7659 (https://jira.secondlife.com/browse/VWR-7659) Ann Otoole wrote: > Sounds like a defect in need of a pjira entry because > there is no shortage of people noticing constant texture reloading. > This eats bytes transferred and SL needs to tighten these bolts up > before Time Warner deploys that dumb so-called > "bandwith cap" (bytes transferred cap". > > Good catch. > > Optimally speaking, I should not have to reload textures from > the same sim I am in almost exclusively. (I don't get out much lol) > > On a side note and in respect to textures and size impact... > Anyone ever look at the math for a "sub optimal" sim > with 15,000 textures at max size? > That would be the worst case scenario for cache size per sim. > Even 15,000 512*512 textures is a whole lot. > And thats not counting avatars. > > So yea cache needs to be much larger and very efficient. > > Otherwise everyone on time warner will be switching to DSL lol. > Probably will be switching to DSL anyway as a matter of > principal if the upper limit is too restrictive. > > ----- Original Message ---- > From: Buckaroo Mu > >Further testing. When I log in, my cache... goes away. All of those > >textures are wiped. Or at least most of them - I'm down to a few > >megabytes, when I stand at my login spot. The discard algorithm is > >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded > >(apparently, as disclosed in another thread) limit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From darien_caldwell at comcast.net Sat Jun 7 23:26:22 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Sat Jun 7 23:26:22 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed References: <26449.37698.qm@web59103.mail.re1.yahoo.com> <484B2A45.4050805@bitparts.org> Message-ID: Sorry, i tried this, and don't see the issue you're describing. All the textures I had cached at my last logoff were still cached after logging on (1.20 RC9). are you sure you haven't flipped some wierd setting or something? ----- Original Message ----- From: "Buckaroo Mu" To: "Second Life Developer Mailing List" Sent: Saturday, June 07, 2008 5:39 PM Subject: Re: [sldev] Texture caching/bandwidth/performance how to proceed > Filed as VWR-7659 (https://jira.secondlife.com/browse/VWR-7659) > > Ann Otoole wrote: >> Sounds like a defect in need of a pjira entry because >> there is no shortage of people noticing constant texture reloading. >> This eats bytes transferred and SL needs to tighten these bolts up >> before Time Warner deploys that dumb so-called >> "bandwith cap" (bytes transferred cap". >> >> Good catch. >> >> Optimally speaking, I should not have to reload textures from >> the same sim I am in almost exclusively. (I don't get out much lol) >> >> On a side note and in respect to textures and size impact... >> Anyone ever look at the math for a "sub optimal" sim >> with 15,000 textures at max size? >> That would be the worst case scenario for cache size per sim. >> Even 15,000 512*512 textures is a whole lot. >> And thats not counting avatars. >> >> So yea cache needs to be much larger and very efficient. >> >> Otherwise everyone on time warner will be switching to DSL lol. >> Probably will be switching to DSL anyway as a matter of >> principal if the upper limit is too restrictive. >> >> ----- Original Message ---- >> From: Buckaroo Mu >> >Further testing. When I log in, my cache... goes away. All of those >> >textures are wiped. Or at least most of them - I'm down to a few >> >megabytes, when I stand at my login spot. The discard algorithm is >> >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded >> >(apparently, as disclosed in another thread) limit. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Sat Jun 7 23:35:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 7 23:35:51 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> Message-ID: <484B7DC5.7000900@cox.net> Argent Stonecutter wrote: > On 2008-06-07, at 18:47, Lawson English wrote: >> Doable, I'm sure, but as Felix points out, opting out of it will >> cripple functionality in a given region/sim/grid > > Why? > > All that will mean is that whatever optional feature that uses P2P > can't be used. That's hardly crippling. > > > Well, if its important enough to provide for, its probably exceedingly important. OTOH, if you really wanted to participate, you'd make sure you had the plugin or whatever so you could. Lawson From secret.argent at gmail.com Sun Jun 8 07:11:36 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 07:10:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484B7DC5.7000900@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> Message-ID: <441F5696-2366-4FC2-BB68-DF9600F5C232@gmail.com> On 2008-06-08, at 01:35, Lawson English wrote: > Well, if its important enough to provide for, its probably > exceedingly important. Well, first, streaming audio and video is "provided for", but it's hardly important. I don't even have Quicktime installed on my Wintendo any more. Voice is provided for but it's got negative value as far as I'm concerned: the only times I've used voice have been times I've been more or less forced to by other players if I wanted to participate in something, and the experience was entirely unpleasant. I'm not suggesting it as something "provided for" at all. What I suggested as a sim-level data bus to *avoid* having to use it, and the suggestion that IF that proved insufficient for some third-party plugin or viewer THEN you could negotiate some kind of P2P arrangement over it for users that chose to use it. I'm simply saying that using P2P needs to be explicitly requested by the user and explicitly approved by the user when it's required, just like streaming video is. > OTOH, if you really wanted to participate, you'd make sure you had > the plugin or whatever so you could. From secret.argent at gmail.com Sun Jun 8 12:06:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 12:05:29 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484B7DC5.7000900@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> Message-ID: <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> http://jira.secondlife.com/browse/SVC-2509 http://jira.secondlife.com/browse/SVC-2508 From lenglish5 at cox.net Sun Jun 8 12:18:18 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Jun 8 12:18:21 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> Message-ID: <484C307A.7020004@cox.net> Argent Stonecutter wrote: > http://jira.secondlife.com/browse/SVC-2509 > http://jira.secondlife.com/browse/SVC-2508 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > One issue to keep in mind is that LL is committed currently to using http or some variation for virtually all of its communications needs between client and server. Because of the http/1.1 recommendation for having at most only 2 http connections between client and server, their first response will be to point to the preceding requirement and any suggestion about communications will have to fit into that 2-socket requirement in some way. Lawson From dahliatrimble at gmail.com Sun Jun 8 16:47:28 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun Jun 8 16:47:30 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: Seems to me that the existing channels between the viewer and the server could support this already without additional sockets by adding an additional packet type or instant message filter, at least for the object->viewer pathway. Perhaps a more robust XML-RPC implementation for objects could support the rest? On Sun, Jun 8, 2008 at 12:18 PM, Lawson English wrote: > Argent Stonecutter wrote: > >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> One issue to keep in mind is that LL is committed currently to using http > or some variation for virtually all of its communications needs between > client and server. Because of the http/1.1 recommendation for having at most > only 2 http connections between client and server, their first response will > be to point to the preceding requirement and any suggestion about > communications will have to fit into that 2-socket requirement in some way. > > Lawson > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080608/b724b40b/attachment.htm From secret.argent at gmail.com Sun Jun 8 18:59:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 18:58:16 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <03A9114E-C798-4625-AEDB-2D6EFB000731@gmail.com> On 2008-06-08, at 14:18, Lawson English wrote: > One issue to keep in mind is that LL is committed currently to > using http or some variation for virtually all of its > communications needs between client and server. I don't see what that has to so with it. This is not a new connection, it's a new message type. Whether messages between the client and the server are using UDP, TCP, HTTP, or SMTP is an implementation detail. From tateru.nino at gmail.com Sun Jun 8 19:03:21 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jun 8 19:04:07 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <484C8F69.6080505@gmail.com> Lawson English wrote: > Argent Stonecutter wrote: >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > One issue to keep in mind is that LL is committed currently to using > http or some variation for virtually all of its communications needs > between client and server. Because of the http/1.1 recommendation for > having at most only 2 http connections between client and server, > their first response will be to point to the preceding requirement and > any suggestion about communications will have to fit into that > 2-socket requirement in some way. > The two-socket recommendation is an RFC2616 advisory, intended to encourage a specific behavior pattern based on the size, quantity, request pattern and so forth of entities on the Web. It is not unreasonable for non-Web-based applications to have more (or fewer) simultaneous HTTP transports (persistent and non-), because they're never going to experience the conditions and circumstances that the two-socket recommendation was intended to address. From tateru.nino at gmail.com Sun Jun 8 19:07:06 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jun 8 19:07:52 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <484C904A.1070205@gmail.com> I should have added - there may be *other* reasons that a two-socket maximum may be sensible, but the recommendation in the specification isn't it :) Lawson English wrote: > Argent Stonecutter wrote: >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > One issue to keep in mind is that LL is committed currently to using > http or some variation for virtually all of its communications needs > between client and server. Because of the http/1.1 recommendation for > having at most only 2 http connections between client and server, > their first response will be to point to the preceding requirement and > any suggestion about communications will have to fit into that > 2-socket requirement in some way. > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dmahalko at gmail.com Mon Jun 9 00:22:15 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 9 00:22:17 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: >From the mention of pitchforks and politics in Robin's other thread, I am getting the impression that some people don't really want to improve the local caching performance as much as possible. The best possible caching performance would require storing raw data in ways that would make it all so much easier to "rip" and reuse copyrighted assets without the creator's permission. This whole secondary decoded image cache discussion... will LL's senior developers allow this project to exist in the release viewer? JPEG2000 seems to have two purposes. Not only does it allow high compression, but it isn't a widely accepted image standard, so the texture cache as designed now is somewhat protected and obfuscated by locally caching bitmaps that way. Decompressing JPEG2000 straight to video memory helps to hide the raw data from casual ripping. This is easily defeated with that OpenGL wrapper, but the wrapper also generates a ton of garbage that must be sifted to find the desired texture to steal, so it isn't easy to use for ripping by any means. A raw decompressed texture cache would be ridiculously easy to rip. Can you imagine casually browsing to the SL cache folders with Windows and having it auto-create thumbnails of every single cached image? Or having the texture cache folders imported into Picasa's catalog? There are people selling high-value avatar skins and sculpties who would probably have an apoplectic fit if they saw this. The VFS is another obfuscatory layer. As designed it is a RAM-disk, read into memory only when the client starts up, and it isn't written to the disk at all while the client is running. It consumes precious limited system memory at all times, but it also helps to hide downloaded assets in a storage system that cannot be easily snooped with file-access monitoring tools. As a RAM-disk, the VFS absolutely does not scale, and trying to improve network caching performance by making the VFS several gigabytes in size just invites virtual-memory page swapping and poor overall system performance. I think we'd be much better off to use the new folder-based texture caching system to store all asset types, and completely cease the use of the VFS and its totally-held-in-RAM design. BUT this would remove all obfuscatory layers of the VFS and would make it easier to directly examine and potentially rip downloaded assets of any type. Non-texture assets are probably all in their raw file data formats, and they would be laid bare and helpless in a folder-based cache, so LL may not be willing to allow this. A move to a local MySQL database may be needed not only to merely make the asset cache scalable and more efficient, but more importantly, to preserve the local asset storage obfuscation layers. The developers on this list appear to understand that ultimately nothing sent to the client can be protected from copying and unauthorized reuse, and this is just the facts of life. It sounds to me like some people at LL don't want to force the rest of the userbase to accept this reality. We may have to continue to live with lousy local caching performance just to help assuage the fears of the angry and irrational pitchfork-waving masses that are still running "anti-copybot" scripts. - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Mon Jun 9 01:55:25 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 01:55:28 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <484CEFFD.4060408@gmail.com> Dale Mahalko wrote: > The best possible caching performance would require storing raw data > in ways that would make it all so much easier to "rip" and reuse > copyrighted assets without the creator's permission. It is not difficult now. > This whole secondary decoded image cache discussion... will LL's > senior developers allow this project to exist in the release viewer? Linden Lab is not accepting *any* outside contributions currently. That said, if it really does perform better, I don't foresee them not taking it because of some concern about the perception of easier ripping. > JPEG2000 seems to have two purposes. Not only does it allow high > compression, but it isn't a widely accepted image standard, so the > texture cache as designed now is somewhat protected and obfuscated by > locally caching bitmaps that way. JPEG2000 has wide support in many applications. It is in no way security through obscurity. > Decompressing JPEG2000 straight to video memory helps to hide the raw > data from casual ripping. This is easily defeated with that OpenGL That is not the reason it is done that way. > A raw decompressed texture cache would be ridiculously easy to rip. The current cache is just as easy. > Can you imagine casually browsing to the SL cache folders with Windows > and having it auto-create thumbnails of every single cached image? Or Who cares? A small utility anyone can write in a few hours can do this today. > having the texture cache folders imported into Picasa's catalog? There > are people selling high-value avatar skins and sculpties who would > probably have an apoplectic fit if they saw this. I doubt it. People that make a living selling these sorts of items are well aware by now that they will always be easily copied. > The VFS is another obfuscatory layer. As designed it is a RAM-disk, > read into memory only when the client starts up, and it isn't written > to the disk at all while the client is running. It consumes precious This was never the intention of the VFS. The VFS was created due to a perception at Linden Lab that filesystems were not good enough to store cache files. It was kind of strange logic, but I guess at a time when FAT32 was still common, it might have made sense. > I think we'd be much better off to use the new folder-based texture > caching system to store all asset types, and completely cease the use > of the VFS and its totally-held-in-RAM design. It is already mostly this way. > A move to a local MySQL database may be needed not only to merely make > the asset cache scalable and more efficient, but more importantly, to > preserve the local asset storage obfuscation layers. This is probably the stupidest thing I've ever seen you type. :) Such a solution is very much not scalable. Databases store structured relational data, not files. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/5182c2bd/smime.bin From danteferret at gmail.com Mon Jun 9 03:23:23 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 03:23:26 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> Lets all just stop pretending anyone who wants to steal textures can't with the current system. Anyone who wants them can already get them. The only thing storing data raw would do is make them more accesable to people who don't want them and have no knoledge of how to get them currently. And if they don't want them then whats the harm? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/befade52/attachment.htm From tom at streamsense.net Mon Jun 9 03:34:10 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Jun 9 03:35:08 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D070A.1050705@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> Message-ID: <484D0722.3020701@streamsense.net> Dante Tucker wrote: > Lets all just stop pretending anyone who wants to steal textures can't > with the current system. Anyone who wants them can already get them. > The only thing storing data raw would do is make them more accesable > to people who don't want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? Agreed. I tire of people moaning about IP security. Your stuff is already stolen, deal with it. ~Tom From robin.cornelius at gmail.com Mon Jun 9 03:49:59 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 03:50:03 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D0722.3020701@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: On Mon, Jun 9, 2008 at 11:34 AM, Thomas Grimshaw wrote: > Dante Tucker wrote: >> >> Lets all just stop pretending anyone who wants to steal textures can't >> with the current system. Anyone who wants them can already get them. The >> only thing storing data raw would do is make them more accesable to people >> who don't want them and have no knoledge of how to get them currently. And >> if they don't want them then whats the harm? > > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > It wasn't ip security i started this about but the general SL populations "perception". We know here the texture cache might just as well not mess about and save in a direct format. We know its trivial to rip a texture now with a 101 methods but ignorance like :- http://jira.secondlife.com/browse/VWR-4614 http://jira.secondlife.com/browse/VWR-6798 http://jira.secondlife.com/browse/VWR-4503 just to pick a few, not the example i was looking for, there is/was one somewhere with a pile of votes saying remove the texture console. And this noise is heard so often and often gets associated with anti-opensource. There are no real usable technical solutions to content theft, nothing technical really works anywhere. As far as i see the only solution is the social one, where people have the respect not to just rip stuff off and thats a whole bigger issue than just SL. May be i just should not care. The libsl guys do not, and they got blamed for copybot. Closed source or open source, copying is inevitable, i just don't want open source to get the blame. Robin From secret.argent at gmail.com Mon Jun 9 04:40:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 04:39:26 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> On 2008-06-09, at 02:22, Dale Mahalko wrote: > A move to a local MySQL database God no. sqlite, please. Without all the MySQL "I'm pretending to be a real database engine" overhead. But preserving the local obfuscation would still be easy, simply by storing the raw bitmaps rather than any encoded form, and storing caching metadata in binary at the beginning of the file instead of in filesystem datestamps and extensions. Plus there's no reason to use the raw UUID. XORING it with "Please don't steal Mac OS X"... I mean "Please don't steal this asset"... would do. From tateru.nino at gmail.com Mon Jun 9 05:03:01 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 05:03:49 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <484D1BF5.4060807@weblogsinc.com> Dale Mahalko wrote: > A raw decompressed texture cache would be ridiculously easy to rip. > Can you imagine casually browsing to the SL cache folders with Windows > and having it auto-create thumbnails of every single cached image? Or > having the texture cache folders imported into Picasa's catalog? > Umm. Actually, this can already be done. -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Mon Jun 9 05:04:45 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 05:05:41 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> Message-ID: <484D1C5D.40805@gmail.com> Actually, the raw, decoded textures would be *slightly* more complicated to rip than the current JPG2K textures are. You'd have to at least convert the image formats first to something that other tools could understand. Dante Tucker wrote: > Lets all just stop pretending anyone who wants to steal textures can't > with the current system. Anyone who wants them can already get them. > The only thing storing data raw would do is make them more accesable > to people who don't want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From teravus at gmail.com Mon Jun 9 05:21:49 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 05:21:51 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C904A.1070205@gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> Message-ID: <34cc66250806090521q3c1cf2fsf9086a11ca47829b@mail.gmail.com> Unfortunately, Operating systems like Microsoft windows has the '2' limitation buried in the registry, and some ubiquitous libraries honor that limitation (can you say wininet?). In fact, for server applications using wininet, it's recommended by Microsoft to dig into the registry and change that value. Best Regards Teravus On 6/8/08, Tateru Nino wrote: > > I should have added - there may be *other* reasons that a two-socket > maximum may be sensible, but the recommendation in the specification isn't > it :) > > Lawson English wrote: > >> Argent Stonecutter wrote: >> >>> http://jira.secondlife.com/browse/SVC-2509 >>> http://jira.secondlife.com/browse/SVC-2508 >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> One issue to keep in mind is that LL is committed currently to using http >> or some variation for virtually all of its communications needs between >> client and server. Because of the http/1.1 recommendation for having at most >> only 2 http connections between client and server, their first response will >> be to point to the preceding requirement and any suggestion about >> communications will have to fit into that 2-socket requirement in some way. >> >> Lawson >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/22712868/attachment.htm From zak.escher at gmail.com Mon Jun 9 05:32:02 2008 From: zak.escher at gmail.com (Zak Escher) Date: Mon Jun 9 05:32:09 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> Message-ID: <484D22C2.1090403@gmail.com> I keep getting the following when trying to run develop.py. This is from within Windows Vista Ultimate 64-Bit. (Note: I have replaced my user id with ) c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BO OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- broken CMake Error at C:/Program Files (x86)/CMake 2.6/share/cmake-2.6/Modules/CMakeTes tCCompiler.cmake:32 (MESSAGE): The C compiler "cl" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/ CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~2\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual Studio Version 8.0.50727.867. Copyright (C) Microsoft Corp 1984-2005. All rights reserved. 1>------ Build started: Project: cmTryCompileExec, Configuration: Debug Win32 ------ 1>Compiling... 1>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 1>Copyright (C) Microsoft Corporation. All rights reserved. 1>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTC1 /MDd /Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/CMakeTmp/ Debug/cmTryCompileExec.pdb" /W3 /c /Zi /TC /Zm1000 1> ".\testCCompiler.c" 1>testCCompiler.c 1>Compiling manifest to resources... 1>Linking... 1>link: extra operand `/ERRORREPORT:QUEUE' 1>Try `link --help' for more information. 1>Project : error PRJ0002 : Error result 1 returned from 'C:\cygwin\bin\link.exe'. 1>Build log was saved at "file://c:\Users\\sl_1_19_1_14\linden\indra\build-VC80\CMakeFiles\CMake Tmp\cmTryCompileExec.dir\Debug\BuildLog.htm" 1>cmTryCompileExec - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) -- Configuring done Cleaning 'build-VC80' Traceback (most recent call last): File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 654, in ? main(sys.argv[1:]) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 627, in mai n setup.run_cmake() File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 509, in run _cmake PlatformSetup.run_cmake(self, args) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 155, in run _cmake self.run(cmd, 'cmake') File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 504, in run raise CommandError('the command %r exited with %s' % __main__.CommandError: the command 'cmake' exited with 1 From teravus at gmail.com Mon Jun 9 05:35:29 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 05:35:33 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C904A.1070205@gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> Message-ID: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> I also note, that according to Microsoft's kb article: "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. The four-connection limit for HTTP 1.0 is a self-imposed restriction that coincides with the standard that is used by a number of popular Web browsers." You can read the article here: http://support.microsoft.com/kb/183110 You can read the RFC here: http://www.faqs.org/rfcs/rfc2616.html Best Regards Teravus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/084c762c/attachment.htm From robin.cornelius at gmail.com Mon Jun 9 05:40:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 05:40:25 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D22C2.1090403@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: On Mon, Jun 9, 2008 at 1:32 PM, Zak Escher wrote: > I keep getting the following when trying to run develop.py. This is from > within Windows Vista Ultimate 64-Bit. > > (Note: I have replaced my user id with ) > > c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 > Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE > -DUNATTENDED:BO > OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in > 'build-VC80' > -- Check for working C compiler: cl > -- Check for working C compiler: cl -- broken > CMake Error at C:/Program Files (x86)/CMake > 2.6/share/cmake-2.6/Modules/CMakeTes > tCCompiler.cmake:32 (MESSAGE): > The C compiler "cl" is not able to compile a simple test program. try running from the console the vcvars.bat (or vsvars.bat) that is found in c:\program files\visual studio 2005\VC\bin\ or a path very like that and try again. Looks like your visual studio is not correctly setup for out of IDE compiling. Robin From Celierra at gmail.com Mon Jun 9 08:50:38 2008 From: Celierra at gmail.com (Celierra Darling) Date: Mon Jun 9 08:50:40 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 8:35 AM, Teravus Ovares wrote: > I also note, that according to Microsoft's kb article: > > "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. The > four-connection limit for HTTP 1.0 is a self-imposed restriction that > coincides with the standard that is used by a number of popular Web > browsers." > > You can read the article here: > http://support.microsoft.com/kb/183110 > > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > The relevant text in the RFC seems to be in 8.1.4, "Practical Considerations". The relevant paragraph quoted: " Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion. " They are all "SHOULD" guidelines, not mandates as the Microsoft quote claims. There are several browsers which break the recommendation already, as the Firefox people seem to have noticed. Microsoft (apparently) is also going to break the 2-connection guideline starting with IE8. According to http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/5eebb8c65c34c3c6/323b25cfd9211fa0?fwc=1 , here are the numbers for some major browsers: Firefox 2: 2 Firefox 3: 2 (now 6) Opera 9.26: 4 Opera 9.5 beta: 4 Safari 3.0.4 Mac/Windows: 4 IE 7: 2 IE 8: 6 See also https://bugzilla.mozilla.org/show_bug.cgi?id=423377 , where this discussion appears to have already happened once before. ~Cel From tateru.nino at gmail.com Mon Jun 9 09:03:32 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 09:04:22 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D22C2.1090403@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: <484D5454.6040207@weblogsinc.com> Cmake2.6 is not supported at present, is it? I thought the build only supported (I think it was 2.4.8) Zak Escher wrote: > I keep getting the following when trying to run develop.py. This is > from within Windows Vista Ultimate 64-Bit. > > (Note: I have replaced my user id with ) > > c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 > Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE > -DUNATTENDED:BO > OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in > 'build-VC80' > -- Check for working C compiler: cl > -- Check for working C compiler: cl -- broken > CMake Error at C:/Program Files (x86)/CMake > 2.6/share/cmake-2.6/Modules/CMakeTes > tCCompiler.cmake:32 (MESSAGE): > The C compiler "cl" is not able to compile a simple test program. > > It fails with the following output: > > Change Dir: > C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/ > CMakeTmp > > > > Run Build Command:C:\PROGRA~2\MICROS~2\Common7\IDE\devenv.com > CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec > > > > Microsoft (R) Visual Studio Version 8.0.50727.867. > > Copyright (C) Microsoft Corp 1984-2005. All rights reserved. > > 1>------ Build started: Project: cmTryCompileExec, Configuration: Debug > Win32 ------ > > 1>Compiling... > > 1>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version > 14.00.50727.762 > for 80x86 > > 1>Copyright (C) Microsoft Corporation. All rights reserved. > > 1>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D > "CMAKE_INTDIR=\"Debug\"" > /D "_MBCS" /FD /RTC1 /MDd /Fo"cmTryCompileExec.dir\Debug\\" > > /Fd"C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/CMakeTmp/ > > Debug/cmTryCompileExec.pdb" > /W3 /c /Zi /TC /Zm1000 > > 1> ".\testCCompiler.c" > > 1>testCCompiler.c > > 1>Compiling manifest to resources... > > 1>Linking... > > 1>link: extra operand `/ERRORREPORT:QUEUE' > > 1>Try `link --help' for more information. > > 1>Project : error PRJ0002 : Error result 1 returned from > 'C:\cygwin\bin\link.exe'. > > 1>Build log was saved at > > "file://c:\Users\\sl_1_19_1_14\linden\indra\build-VC80\CMakeFiles\CMake > > Tmp\cmTryCompileExec.dir\Debug\BuildLog.htm" > > > 1>cmTryCompileExec - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped > ========== > > > > > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:3 (project) > > > -- Configuring done > Cleaning 'build-VC80' > Traceback (most recent call last): > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 654, in ? > main(sys.argv[1:]) > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 627, in mai > n > setup.run_cmake() > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 509, in run > _cmake > PlatformSetup.run_cmake(self, args) > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 155, in run > _cmake > self.run(cmd, 'cmake') > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 504, in run > > raise CommandError('the command %r exited with %s' % > __main__.CommandError: the command 'cmake' exited with 1 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Mon Jun 9 09:12:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 09:13:38 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> Message-ID: <484D5677.80300@gmail.com> Actually it is not a mandate. A mandate would be a MUST NOT. This is a SHOULD NOT, specifically: "A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users." I've got personal knowledge that the author did not intend the above to apply to situations like this. For the substrate to MSIE, however, it is entirely appropriate. Also, the above only applies to persistent connections, not non-persistent connections (applying the same guideline to non-persistent connections would cause problems that this guideline is intended to avoid). Just because you're doing HTTP, doesn't make you a part of the Web, and connection considerations in Web architecture over HTTP are different to other architectures over HTTP. Teravus Ovares wrote: > I also note, that according to Microsoft's kb article: > > "The HTTP 1.1 specification (RFC2616) mandates the two-connection > limit. The four-connection limit for HTTP 1.0 is a self-imposed > restriction that coincides with the standard that is used by a number > of popular Web browsers." > > You can read the article here: > http://support.microsoft.com/kb/183110 > > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > > Best Regards > > Teravus From robla at lindenlab.com Mon Jun 9 10:13:40 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 9 10:13:46 2008 Subject: [sldev] Linden Lab is accepting outside contribution (Re: Cache politics: performance vs obfuscation) In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <484D64C4.8070507@lindenlab.com> On 6/9/08 1:55 AM, Jason Giglio wrote: > Linden Lab is not accepting *any* outside contributions currently. This is false. We are accepting outside contribution. We are trying to stay focused on stability issues right now, so that's where you're most likely to see us quickly take your patches. I can see where earlier statements on this list might lead one to believe that we're not taking contribution, but such statements do not represent the consensus view. Rob From tongb at ohio.edu Mon Jun 9 10:20:16 2008 From: tongb at ohio.edu (Bruce Tong) Date: Mon Jun 9 10:20:19 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D5454.6040207@weblogsinc.com> References: <48448135.6090805@lindenlab.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> <484D5454.6040207@weblogsinc.com> Message-ID: <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> Trying to build with CMake against slviewer-src-maint-viewer-7-r89229... C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' Opening solution: build-VC80\SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, now opening new VisualStudio instance... Reading .sln file version... Opening VS version: VC80... Value cannot be null. Parameter name: type Quitting do to error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife .sln Error getting property: "SolutionBuild" Object reference not set to an instance of an object. Object reference not set to an instance of an object. Error getting property: "Projects" Object reference not set to an instance of an object. Object reference not set to an instance of an object. Finished! I tried to track down the source of this failure. In main.cpp of VSTool, starting at line 315: Type objType = Type.GetTypeFromProgID(progid); dte = System.Activator.CreateInstance(objType); It looks like GettypeFromProgID() returns null. The progid value is being set in GetVSProgID(), based on "VC80" it is being set to "VisualStudio.DTE.8.0". >From this point I'm speculating since I've not done any development for Windows since 1994. I assumed null was the result when the type could not be found. I further assumed since I have an express edition of 2005, that "VisualStudio.DTE.8.0" might not be the right string. So I read a bunch of web pages, poked around in the registry, and for the .sln extension the ProgID on this computer might be "VisualStudio.Launcher.sln", but I also see things like "VCExpress.cpp.8.0". I'm not really certain if I'm on the right track here, or not. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From jake at lindenlab.com Mon Jun 9 10:35:50 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 10:36:02 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> Message-ID: <484D69F6.3040802@lindenlab.com> evolutie wrote: > I finally got around to test with multiple clients logged on to aditi > puppeteering, and unfortunetely the simulation doesn't seem to work. > Seems like instead of simulating the movement of the joints, the > direction in which the avatar looks is simulated. > To illustrate: > http://www.evolutie.org/movies/puppet1.mov shows me moving my hand > http://www.evolutie.org/movies/puppet2.mov shows what this looks like > to another client > > evo > . > > >> It's based off 1.19.1 by the way, and we do actually have a region on aditi >> that is running the simulator code (note, again, this code is relatively >> incomplete and the simulator could well crash) named Puppeteering (You may >> well need to log directly into it by they way). >> >> I'll be honest and say I'm not the least bit surprised. The reason LL let this code branch go was because of issues like this and the fact that mouse-generated real time animation manipulation (which is mostly a client side thing) just wasn't as compelling as had been thought. From teravus at gmail.com Mon Jun 9 10:39:42 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 10:39:45 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484D5677.80300@gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> Message-ID: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Can anyone confirm that the client does not use a library that respects this 2 connection limitation? So far in testing, it appears that it does. When two threads get stuck, it fails to do anything else via http. We've tried to use HTTP CAPS for inventory, and consistently, when the inventory service runs slow, the client stops making *any* further http requests. Best Regards Teravus On 6/9/08, Tateru Nino wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This is a > SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections with any > server or proxy. A proxy SHOULD use up to 2*N connections to another server > or proxy, where N is the number of simultaneously active users." > > I've got personal knowledge that the author did not intend the above to > apply to situations like this. For the substrate to MSIE, however, it is > entirely appropriate. Also, the above only applies to persistent > connections, not non-persistent connections (applying the same guideline to > non-persistent connections would cause problems that this guideline is > intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the Web, and > connection considerations in Web architecture over HTTP are different to > other architectures over HTTP. > > > > > Teravus Ovares wrote: > >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >> coincides with the standard that is used by a number of popular Web >> browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3199c322/attachment.htm From teravus at gmail.com Mon Jun 9 10:47:56 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 10:47:59 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484D5677.80300@gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> Message-ID: <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> I note that we can argue exactly what the RFC means until we're blue in the face. Ultimately what matters is how the libraries the client uses handle it. >From the referenced definition of the words: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) So, given this, the word 'MAY' is optional. SHOULD is almost always. SHOULD NOT is almost never. Best Regards Teravus On 6/9/08, Tateru Nino wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This is a > SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections with any > server or proxy. A proxy SHOULD use up to 2*N connections to another server > or proxy, where N is the number of simultaneously active users." > > I've got personal knowledge that the author did not intend the above to > apply to situations like this. For the substrate to MSIE, however, it is > entirely appropriate. Also, the above only applies to persistent > connections, not non-persistent connections (applying the same guideline to > non-persistent connections would cause problems that this guideline is > intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the Web, and > connection considerations in Web architecture over HTTP are different to > other architectures over HTTP. > > > > > Teravus Ovares wrote: > >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >> coincides with the standard that is used by a number of popular Web >> browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/265eab98/attachment-0001.htm From dahliatrimble at gmail.com Mon Jun 9 11:11:26 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon Jun 9 11:11:31 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> Message-ID: I dont see why the requested functionality couldn't work with existing channels, or am I missing something here? On Mon, Jun 9, 2008 at 10:47 AM, Teravus Ovares wrote: > I note that we can argue exactly what the RFC means until we're blue in the > face. Ultimately what matters is how the libraries the client uses handle > it. > > From the referenced definition of the words: > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > > So, given this, the word 'MAY' is optional. SHOULD is almost always. > SHOULD NOT is almost never. > > Best Regards > > Teravus > > > On 6/9/08, Tateru Nino wrote: > >> Actually it is not a mandate. A mandate would be a MUST NOT. This is a >> SHOULD NOT, specifically: >> "A single-user client SHOULD NOT maintain more than 2 connections with any >> server or proxy. A proxy SHOULD use up to 2*N connections to another server >> or proxy, where N is the number of simultaneously active users." >> >> I've got personal knowledge that the author did not intend the above to >> apply to situations like this. For the substrate to MSIE, however, it is >> entirely appropriate. Also, the above only applies to persistent >> connections, not non-persistent connections (applying the same guideline to >> non-persistent connections would cause problems that this guideline is >> intended to avoid). >> >> Just because you're doing HTTP, doesn't make you a part of the Web, and >> connection considerations in Web architecture over HTTP are different to >> other architectures over HTTP. >> >> >> >> >> Teravus Ovares wrote: >> >>> I also note, that according to Microsoft's kb article: >>> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >>> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >>> coincides with the standard that is used by a number of popular Web >>> browsers." >>> You can read the article here: >>> http://support.microsoft.com/kb/183110 >>> You can read the RFC here: >>> http://www.faqs.org/rfcs/rfc2616.html >>> Best Regards >>> Teravus >>> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/9c2a20da/attachment.htm From robin.cornelius at gmail.com Mon Jun 9 11:20:50 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 11:20:53 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> <484D5454.6040207@weblogsinc.com> <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> Message-ID: <484D7482.3080506@gmail.com> Bruce Tong wrote: > > I tried to track down the source of this failure. > > In main.cpp of VSTool, starting at line 315: > > Type objType = Type.GetTypeFromProgID(progid); > dte = System.Activator.CreateInstance(objType); > > It looks like GettypeFromProgID() returns null. The progid value is > being set in GetVSProgID(), based on "VC80" it is being set to > "VisualStudio.DTE.8.0". > >>From this point I'm speculating since I've not done any development > for Windows since 1994. > > I assumed null was the result when the type could not be found. I > further assumed since I have an express edition of 2005, that > "VisualStudio.DTE.8.0" might not be the right string. So I read a > bunch of web pages, poked around in the registry, and for the .sln > extension the ProgID on this computer might be > "VisualStudio.Launcher.sln", but I also see things like > "VCExpress.cpp.8.0". I'm not really certain if I'm on the right track > here, or not. > http://jira.secondlife.com/browse/VWR-7680 Yea we were on this today on #opensl It appears that the express editions do not register themselves the same way as the Standard or better editions. Its the DTE's you are looking for For express there is reference to VCExpress.DTE which links to VCExpress.DTE.9.0 (on my system) but the CLSID this then contains is not a registered com objectm if i look at my Standard installed VC 2003 .NET i have a VisualStudio.DTE.7.1 and the com objects are registered correctly. (And VSTool.exe works perfectly on my 2003.NET (standard edition) but not on my 2008 Express. I think its a limitation of express versions Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/cd55658c/signature.pgp From me at signpostmarv.name Mon Jun 9 12:35:33 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Jun 9 12:35:43 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> Message-ID: <484D8605.4090200@signpostmarv.name> referenced by name or sim UUID ? ~ Marv. > Bigger-note : > What about storing cache *per sim* ? Most peoples always go in the > same dozen of sim 99% of time and a lot of texture are unique to the > sim. > When you enter in a sim, just load the *entire* cache related to this > sim and discard later the unused texture. > Could it save time ? (pre-decoding ?) > > That's all... have fun :) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/49cfd2a2/smime.bin From rdw at lindenlab.com Mon Jun 9 12:43:17 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jun 9 12:43:18 2008 Subject: Improved viewer and script communications (Re: [sldev]Puppettering Branch) In-Reply-To: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> References: <48473027.9090101@lindenlab.com><6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com><484B1E01.1010800@cox.net><3DC4D675-A 662-4217-AF6D-FEF08586E946@gmail.com><484B7DC5.7000900@cox.net><299591AF-E75A-4757-825F-9F0350A59377@gmail.com><484C307A.702000 4@cox.net> <484C904A.1070205@gmail.com><34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com><484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Message-ID: <484D87D5.3050609@lindenlab.com> Teravus Ovares wrote: > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it appears > that it does. When two threads get stuck, it fails to do anything > else via http. We've tried to use HTTP CAPS for inventory, and > consistently, when the inventory service runs slow, the client stops > making *any* further http requests. The client uses libcurl. I wasn't able to dig up information either confirming or denying that libcurl has such a restriction, but maybe you can! -RYaN From zak.escher at gmail.com Mon Jun 9 13:03:22 2008 From: zak.escher at gmail.com (Zak Escher) Date: Mon Jun 9 13:03:27 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: <484D8C8A.2080604@gmail.com> I ran the batch file. Now I am getting the following: C:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BO OL=FALSE "" "C:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in 'build-VC80' CMake Error: Could not create named generator Visual Studio 8 2005 Cleaning 'build-VC80' Traceback (most recent call last): File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 654, in ? main(sys.argv[1:]) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 627, in mai n setup.run_cmake() File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 509, in run _cmake PlatformSetup.run_cmake(self, args) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 155, in run _cmake self.run(cmd, 'cmake') File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 504, in run raise CommandError('the command %r exited with %s' % __main__.CommandError: the command 'cmake' exited with 1 Robin Cornelius wrote: > On Mon, Jun 9, 2008 at 1:32 PM, Zak Escher wrote: > >> I keep getting the following when trying to run develop.py. This is from >> within Windows Vista Ultimate 64-Bit. >> >> (Note: I have replaced my user id with) >> >> c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 >> Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE >> -DUNATTENDED:BO >> OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in >> 'build-VC80' >> -- Check for working C compiler: cl >> -- Check for working C compiler: cl -- broken >> CMake Error at C:/Program Files (x86)/CMake >> 2.6/share/cmake-2.6/Modules/CMakeTes >> tCCompiler.cmake:32 (MESSAGE): >> The C compiler "cl" is not able to compile a simple test program. >> > > try running from the console the vcvars.bat (or vsvars.bat) that is > found in c:\program files\visual studio 2005\VC\bin\ > > or a path very like that and try again. Looks like your visual studio > is not correctly setup for out of IDE compiling. > > Robin > From timothyhorrigan at mac.com Mon Jun 9 13:36:04 2008 From: timothyhorrigan at mac.com (Timothy Horrigan) Date: Mon Jun 9 13:36:16 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <484D9434.4090409@mac.com> Robin Cornelius wrote: > > > just to pick a few, not the example i was looking for, there is/was > one somewhere with a pile of votes saying remove the texture console. > And this noise is heard so often and often gets associated with > anti-opensource. > > There are no real usable technical solutions to content theft, nothing > technical really works anywhere. As far as i see the only solution is > the social one, where people have the respect not to just rip stuff > off and thats a whole bigger issue than just SL. > > Anytime you make content visible to the public, you are running the risk of them "stealing" it. Even if you make direct copying, they can just reverse-engineer it. In the case of SL, the textures are "stealing" space on my hard drive, so I should be able to look at the cache files :-) I liked the people who wanted to eliminate the texture console. even though they were unable to explain how the texture console would actually enable a user to rip a specific console. -------------- next part -------------- A non-text attachment was scrubbed... Name: timothyhorrigan.vcf Type: text/x-vcard Size: 224 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/6afd74c9/timothyhorrigan.vcf From timothyhorrigan at mac.com Mon Jun 9 13:36:28 2008 From: timothyhorrigan at mac.com (Timothy Horrigan) Date: Mon Jun 9 13:36:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <484D944C.9010009@mac.com> Robin Cornelius wrote: > > > just to pick a few, not the example i was looking for, there is/was > one somewhere with a pile of votes saying remove the texture console. > And this noise is heard so often and often gets associated with > anti-opensource. > > There are no real usable technical solutions to content theft, nothing > technical really works anywhere. As far as i see the only solution is > the social one, where people have the respect not to just rip stuff > off and thats a whole bigger issue than just SL. > > Anytime you make content visible to the public, you are running the risk of them "stealing" it. Even if you make direct copying impossible, they can just reverse-engineer it. In the case of SL, the textures are "stealing" space on my hard drive, so I should be able to look at the cache files :-) I liked the people who wanted to eliminate the texture console. even though they were unable to explain how the texture console would actually enable a user to rip a specific console. -------------- next part -------------- A non-text attachment was scrubbed... Name: timothyhorrigan.vcf Type: text/x-vcard Size: 224 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/92ad078b/timothyhorrigan.vcf From evolutie at gmail.com Mon Jun 9 13:56:48 2008 From: evolutie at gmail.com (evolutie) Date: Mon Jun 9 13:57:07 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484D69F6.3040802@lindenlab.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> Message-ID: <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: > evolutie wrote: >> >> I finally got around to test with multiple clients logged on to aditi >> puppeteering, and unfortunetely the simulation doesn't seem to work. >> Seems like instead of simulating the movement of the joints, the >> direction in which the avatar looks is simulated. >> To illustrate: >> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >> to another client >> >> evo >> . >> >> >>> >>> It's based off 1.19.1 by the way, and we do actually have a region on >>> aditi >>> that is running the simulator code (note, again, this code is relatively >>> incomplete and the simulator could well crash) named Puppeteering (You >>> may >>> well need to log directly into it by they way). >>> >>> > > I'll be honest and say I'm not the least bit surprised. The reason LL let > this code branch go was because of issues like this and the fact that > mouse-generated real time animation manipulation (which is mostly a client > side thing) just wasn't as compelling as had been thought. > hmmmm. I realize the code is unsupported.. and therefor i'm not that surprised either. But it looks more like either the wrong simulation code is being executed on the serverside of things or the puppeteering client is sending or receiving (or interpreting) wrong data.. Somewhere in the communication someone isn't aware of the avatar being a "physical avatar". I think that the current UI being mousebased is useful, but yes, I would love to have other input for it like script functions and physical interfaces like mocap suits etc. But the ability for realtime animation of avatars is a wonderful exciting thing!!! It offers a lot of possibilities that right now are just not possible in SL, and well.. really.. it's totally compelling :-) With things on the clientside already working really well, I don't see too much trouble technically to make it work 'globally'. An array of joint positions/rotations isn't that heavy... Am I overlooking something? Apologies for putting these issues on unsupported features up.. I would just love to see this going to the next level, but can't do anything when it comes to the serverside of things.. And maybe this is just a matter of the wrong code running on the puppeteering SIM ? thnx and regards, Evo From blindwanderer at gmail.com Mon Jun 9 14:04:31 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Mon Jun 9 14:04:36 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <89ca6da00806091402j2b614bc2t4df2f5f10374c06f@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <484D944C.9010009@mac.com> <89ca6da00806091402j2b614bc2t4df2f5f10374c06f@mail.gmail.com> Message-ID: <89ca6da00806091404u63911c62p8085f4a4f69b7f71@mail.gmail.com> I've been playing with the client cache for years. Yes I said years. Three years ago I wrote a tool that converted the VFS to a tar archive. It then became trivial to open it in WinZip (which handles large archives really well). It was during this time that I reverse engineered the asset formats. At the time I opened a dialog with LL on the issues of asset security, and so I was asked the question: "No matter what we do, people can still steal assets, so why bother doing anything?" The problem is, to render an asset it needs to be in raw form. Even if you encrypt the data stream and caches, the weak link is the end of the chain where it gets rendered. There is no point in hardening the front door when the back door is hanging off it's hinges. LL will do what ever is easy and will provide good performance. The question I have is this: Is it faster to read a decoded image from disk or read a JPEG2000 encoded image from disk and decode it? With the steady increase of the number of CPU cores in a system, allowing for more simultaneous threads, is it really important? On Mon, Jun 9, 2008 at 4:36 PM, Timothy Horrigan wrote: > Robin Cornelius wrote: >> >> >> just to pick a few, not the example i was looking for, there is/was >> one somewhere with a pile of votes saying remove the texture console. >> And this noise is heard so often and often gets associated with >> anti-opensource. >> >> There are no real usable technical solutions to content theft, nothing >> technical really works anywhere. As far as i see the only solution is >> the social one, where people have the respect not to just rip stuff >> off and thats a whole bigger issue than just SL. >> >> > > Anytime you make content visible to the public, you are running the risk of > them "stealing" it. Even if you make direct copying impossible, they can > just reverse-engineer it. > > In the case of SL, the textures are "stealing" space on my hard drive, so I > should be able to look at the cache files :-) > > I liked the people who wanted to eliminate the texture console. even though > they were unable to explain how the texture console would actually enable a > user to rip a specific console. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From ordinal.malaprop at fastmail.fm Mon Jun 9 14:22:10 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Mon Jun 9 14:22:15 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D0722.3020701@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > Dante Tucker wrote: >> Lets all just stop pretending anyone who wants to steal textures >> can't with the current system. Anyone who wants them can already >> get them. The only thing storing data raw would do is make them >> more accesable to people who don't want them and have no knoledge >> of how to get them currently. And if they don't want them then >> whats the harm? > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > > ~Tom Not to pick on Tom particularly here, but this is the sort of m message that reinforces my opinion that: (a) the people involved in discussing assets don't understand what those _creating_ the assets want or think; (b) they don't care. The level of snobbery applied here is breathtaking, endless references to pitchforks ho ho, you know, they're all irrational peasants. But even in the current situation, textures not being instantly obtainable by just going to the right directory and dragging to somewhere else is a disincentive to pirates. YES, we do all know about glintercept and all the other ways to get hold of textures. YES, we know that there is an intrinsic problem here, that displaying the damn assets implies that they are received by the client. YES, we've all heard these teenage extropian "information wants to be free" tropes, thanks all the same. Amazingly enough, people appreciate the practical issues. What they don't like is the idea that they are being treated as idiots and rubes by LL and assorted geeky types because they dare to get worried about the reason that they are there and building the world for you lot to play about with in the first place. Because, you know, if it wasn't for people who make content, you and I would not be here discussing this stuff, as I've said before. If you can't offer anything to content creators apart from "ha ha your stuff has already been stolen stupid n00bs" then you might as well close the whole company down right now. From jake at lindenlab.com Mon Jun 9 14:23:29 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 14:23:41 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> Message-ID: <484D9F51.4010209@lindenlab.com> Comments at the bottom evolutie wrote: > On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: > >> evolutie wrote: >> >>> I finally got around to test with multiple clients logged on to aditi >>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>> Seems like instead of simulating the movement of the joints, the >>> direction in which the avatar looks is simulated. >>> To illustrate: >>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>> to another client >>> >>> evo >>> . >>> >>> >>> >>>> It's based off 1.19.1 by the way, and we do actually have a region on >>>> aditi >>>> that is running the simulator code (note, again, this code is relatively >>>> incomplete and the simulator could well crash) named Puppeteering (You >>>> may >>>> well need to log directly into it by they way). >>>> >>>> >>>> >> I'll be honest and say I'm not the least bit surprised. The reason LL let >> this code branch go was because of issues like this and the fact that >> mouse-generated real time animation manipulation (which is mostly a client >> side thing) just wasn't as compelling as had been thought. >> >> > > hmmmm. I realize the code is unsupported.. and therefor i'm not that > surprised either. > But it looks more like either the wrong simulation code is being > executed on the serverside of things or the puppeteering client is > sending or receiving (or interpreting) wrong data.. Somewhere in the > communication someone isn't aware of the avatar being a "physical > avatar". > I think that the current UI being mousebased is useful, but yes, I > would love to have other input for it like script functions and > physical interfaces like mocap suits etc. > But the ability for realtime animation of avatars is a wonderful > exciting thing!!! It offers a lot of possibilities that right now are > just not possible in SL, and well.. really.. it's totally compelling > :-) > With things on the clientside already working really well, I don't see > too much trouble technically to make it work 'globally'. An array of > joint positions/rotations isn't that heavy... Am I overlooking > something? > Apologies for putting these issues on unsupported features up.. I > would just love to see this going to the next level, but can't do > anything when it comes to the serverside of things.. And maybe this > is just a matter of the wrong code running on the puppeteering SIM ? > > thnx and regards, > Evo > I haven't actually looked, I just asked Ops to build and put up the code. I'll go ping them and talk to the relevant people. In terms of finishing the code and pushing it out, well, that's partly why we released it to you guys. If someone here came up with a compelling instance of usage then yeah, it's possible we would revisit it. Internally, as an LL driven project it's unlikely - we just don't have the internal resources free to do large R&D on this particularly item right now - but we figure that's all the more reason to see what you guys can do with it. Never say never. Jake From evolutie at gmail.com Mon Jun 9 14:31:32 2008 From: evolutie at gmail.com (evolutie) Date: Mon Jun 9 14:31:35 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484D9F51.4010209@lindenlab.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> <484D9F51.4010209@lindenlab.com> Message-ID: <5fb4b1fa0806091431q78b23e99s5e86e3fec815f172@mail.gmail.com> Thanks Jake! It's very appreciated! evo On Mon, Jun 9, 2008 at 11:23 PM, Jake Simpson wrote: > Comments at the bottom > > evolutie wrote: >> >> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: >> >>> >>> evolutie wrote: >>> >>>> >>>> I finally got around to test with multiple clients logged on to aditi >>>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>>> Seems like instead of simulating the movement of the joints, the >>>> direction in which the avatar looks is simulated. >>>> To illustrate: >>>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>>> to another client >>>> >>>> evo >>>> . >>>> >>>> >>>> >>>>> >>>>> It's based off 1.19.1 by the way, and we do actually have a region on >>>>> aditi >>>>> that is running the simulator code (note, again, this code is >>>>> relatively >>>>> incomplete and the simulator could well crash) named Puppeteering (You >>>>> may >>>>> well need to log directly into it by they way). >>>>> >>>>> >>>>> >>> >>> I'll be honest and say I'm not the least bit surprised. The reason LL let >>> this code branch go was because of issues like this and the fact that >>> mouse-generated real time animation manipulation (which is mostly a >>> client >>> side thing) just wasn't as compelling as had been thought. >>> >>> >> >> hmmmm. I realize the code is unsupported.. and therefor i'm not that >> surprised either. >> But it looks more like either the wrong simulation code is being >> executed on the serverside of things or the puppeteering client is >> sending or receiving (or interpreting) wrong data.. Somewhere in the >> communication someone isn't aware of the avatar being a "physical >> avatar". >> I think that the current UI being mousebased is useful, but yes, I >> would love to have other input for it like script functions and >> physical interfaces like mocap suits etc. >> But the ability for realtime animation of avatars is a wonderful >> exciting thing!!! It offers a lot of possibilities that right now are >> just not possible in SL, and well.. really.. it's totally compelling >> :-) >> With things on the clientside already working really well, I don't see >> too much trouble technically to make it work 'globally'. An array of >> joint positions/rotations isn't that heavy... Am I overlooking >> something? >> Apologies for putting these issues on unsupported features up.. I >> would just love to see this going to the next level, but can't do >> anything when it comes to the serverside of things.. And maybe this >> is just a matter of the wrong code running on the puppeteering SIM ? >> >> thnx and regards, >> Evo >> > > I haven't actually looked, I just asked Ops to build and put up the code. > I'll go ping them and talk to the relevant people. > > In terms of finishing the code and pushing it out, well, that's partly why > we released it to you guys. If someone here came up with a compelling > instance of usage then yeah, it's possible we would revisit it. Internally, > as an LL driven project it's unlikely - we just don't have the internal > resources free to do large R&D on this particularly item right now - but we > figure that's all the more reason to see what you guys can do with it. > > Never say never. > > Jake > -- http://www.creativemachinery.org From xotmid at gmail.com Mon Jun 9 14:34:31 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Jun 9 14:34:33 2008 Subject: [sldev] Shadow Patch? Message-ID: http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html Is this going to make it into rc10? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/a9d95ad8/attachment.htm From q at lindenlab.com Mon Jun 9 14:36:07 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon Jun 9 14:36:11 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> On Jun 9, 2008, at 5:22 PM, ordinal.malaprop@fastmail.fm wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > >> Dante Tucker wrote: >>> Lets all just stop pretending anyone who wants to steal textures >>> can't with the current system. Anyone who wants them can already >>> get them. The only thing storing data raw would do is make them >>> more accesable to people who don't want them and have no knoledge >>> of how to get them currently. And if they don't want them then >>> whats the harm? >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom > > Not to pick on Tom particularly here, but this is the sort of m > message that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what > those _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless > references to pitchforks ho ho, you know, they're all irrational > peasants. But even in the current situation, textures not being > instantly obtainable by just going to the right directory and > dragging to somewhere else is a disincentive to pirates. > > YES, we do all know about glintercept and all the other ways to get > hold of textures. YES, we know that there is an intrinsic problem > here, that displaying the damn assets implies that they are received > by the client. YES, we've all heard these teenage extropian > "information wants to be free" tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they > don't like is the idea that they are being treated as idiots and > rubes by LL and assorted geeky types because they dare to get > worried about the reason that they are there and building the world > for you lot to play about with in the first place. Because, you > know, if it wasn't for people who make content, you and I would not > be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. > Boy, I can totally see both sides of this argument. It's true -- if we're displaying it, it can be copied with a relatively small amount of work for a motivated individual with technical skill. It's *also* true that if it's trivially easy to copy it, it will be copied much more frequently than if it's slightly harder. This is why "security by obscurity" is popular. The extra step makes it obvious that you're taking some measure -- no matter how simple -- to break a protection scheme, and that sense of an explicit violation does deter a lot of people. So while I completely agree that there's no way we can provide true protection, I also agree that simply stuffing the files into a directory using standard formats is kind of like leaving your bike unlocked in the street -- someone will ride off with it who might not have bothered if you used even a cheap bike lock. Personally (I'm not speaking for Linden here), I think that if we want to change the way we do caching, we should make it slightly complicated to grab items out of the cache by NOT storing them in standard formats. Q From bboomslang at googlemail.com Mon Jun 9 14:36:26 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Jun 9 14:36:32 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <347b550f0806091436t3cafddf3m463de8a6afa3e903@mail.gmail.com> I have to agree with Ordinal here. Yes, obviously, data sent to the client is decodeable by the client and not possible to protect perfectly. That's a given. But that does not say at the same time that you should make things so simple that taking textures is obvious. We still don't put bars on our windows, even though we absolutely know that breaking glas is easy. We still put paper envelopes around our letters despite everybody knowing that paper envelopes don't protect their content. Yes, the professional thieve won't have a problem with breaking your doorlocks - but that doesn't say you rip out your door and let anybody walk in unhindered. The very same reasoning works for software, too. Right, there is no perfect protection. It's pointless to flog that dead horse all the time - but it's at least as pointless to throw all limitations out the window just because of that argument. There are ways to give content at least a token protection that will prevent the most stupid ways of content to spread. No, that won't keep professional thieves out. And yes, it would be ridiculous to go to the lengths the music industry tried to do with DRM, because that will actually harm the users more than the thieves. Practical example: watermarking images in SL and checking those watermarks on re-upload would be an easy way for said token protection against too simple copying. And would add ways to claim ownership. No, definitely not perfect protection, but doable without adding harm for users or degrading performance (as the check is done on upload only and the watermarking right after upload). Would that solve texture-theft? Nope. But it would at least keep some of it onder control. Don't underestimate the results of the proverbial slap-on-the-wrist with most people. bye, Barney On Mon, Jun 9, 2008 at 11:22 PM, wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: >> >>> Lets all just stop pretending anyone who wants to steal textures can't >>> with the current system. Anyone who wants them can already get them. The >>> only thing storing data raw would do is make them more accesable to people >>> who don't want them and have no knoledge of how to get them currently. And >>> if they don't want them then whats the harm? >>> >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom >> > > Not to pick on Tom particularly here, but this is the sort of m message > that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what those > _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless references to > pitchforks ho ho, you know, they're all irrational peasants. But even in the > current situation, textures not being instantly obtainable by just going to > the right directory and dragging to somewhere else is a disincentive to > pirates. > > YES, we do all know about glintercept and all the other ways to get hold of > textures. YES, we know that there is an intrinsic problem here, that > displaying the damn assets implies that they are received by the client. > YES, we've all heard these teenage extropian "information wants to be free" > tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they don't > like is the idea that they are being treated as idiots and rubes by LL and > assorted geeky types because they dare to get worried about the reason that > they are there and building the world for you lot to play about with in the > first place. Because, you know, if it wasn't for people who make content, > you and I would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha your > stuff has already been stolen stupid n00bs" then you might as well close the > whole company down right now. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/01281b0f/attachment-0001.htm From danteferret at gmail.com Mon Jun 9 14:38:57 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 14:38:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> Now don't forget everything here is just opinion. The ultimate decision of what happens with the client is up to Linden Labs. My point is they will listen to everyone before making a decision, not just the few that rant here in this list. We look at things from a technical perspective, others will argue a different perspective. And in the end LL will take all into account. It's a balance really, no reason to get mad. On Mon, Jun 9, 2008 at 5:22 PM, wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: >> >>> Lets all just stop pretending anyone who wants to steal textures can't >>> with the current system. Anyone who wants them can already get them. The >>> only thing storing data raw would do is make them more accesable to people >>> who don't want them and have no knoledge of how to get them currently. And >>> if they don't want them then whats the harm? >>> >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom >> > > Not to pick on Tom particularly here, but this is the sort of m message > that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what those > _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless references to > pitchforks ho ho, you know, they're all irrational peasants. But even in the > current situation, textures not being instantly obtainable by just going to > the right directory and dragging to somewhere else is a disincentive to > pirates. > > YES, we do all know about glintercept and all the other ways to get hold of > textures. YES, we know that there is an intrinsic problem here, that > displaying the damn assets implies that they are received by the client. > YES, we've all heard these teenage extropian "information wants to be free" > tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they don't > like is the idea that they are being treated as idiots and rubes by LL and > assorted geeky types because they dare to get worried about the reason that > they are there and building the world for you lot to play about with in the > first place. Because, you know, if it wasn't for people who make content, > you and I would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha your > stuff has already been stolen stupid n00bs" then you might as well close the > whole company down right now. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/185c279c/attachment.htm From overtake at keynet.com.br Mon Jun 9 14:46:42 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Mon Jun 9 14:47:45 2008 Subject: [sldev] Puppettering Branch References: <48473027.9090101@lindenlab.com><5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com><484D69F6.3040802@lindenlab.com><5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com><484D9F51.4010209@lindenlab.com> <5fb4b1fa0806091431q78b23e99s5e86e3fec815f172@mail.gmail.com> Message-ID: <004901c8ca7a$6c69c0f0$6e00a8c0@eaurouge> Thats great! I?m one of the machinima people waiting anxiously for it ((: {}Overtake ----- Original Message ----- From: "evolutie" To: "Jake Simpson" Cc: Sent: Monday, June 09, 2008 6:31 PM Subject: Re: [sldev] Puppettering Branch > Thanks Jake! It's very appreciated! > > evo > > On Mon, Jun 9, 2008 at 11:23 PM, Jake Simpson wrote: >> Comments at the bottom >> >> evolutie wrote: >>> >>> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: >>> >>>> >>>> evolutie wrote: >>>> >>>>> >>>>> I finally got around to test with multiple clients logged on to aditi >>>>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>>>> Seems like instead of simulating the movement of the joints, the >>>>> direction in which the avatar looks is simulated. >>>>> To illustrate: >>>>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>>>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>>>> to another client >>>>> >>>>> evo >>>>> . >>>>> >>>>> >>>>> >>>>>> >>>>>> It's based off 1.19.1 by the way, and we do actually have a region >>>>>> on >>>>>> aditi >>>>>> that is running the simulator code (note, again, this code is >>>>>> relatively >>>>>> incomplete and the simulator could well crash) named Puppeteering >>>>>> (You >>>>>> may >>>>>> well need to log directly into it by they way). >>>>>> >>>>>> >>>>>> >>>> >>>> I'll be honest and say I'm not the least bit surprised. The reason LL >>>> let >>>> this code branch go was because of issues like this and the fact that >>>> mouse-generated real time animation manipulation (which is mostly a >>>> client >>>> side thing) just wasn't as compelling as had been thought. >>>> >>>> >>> >>> hmmmm. I realize the code is unsupported.. and therefor i'm not that >>> surprised either. >>> But it looks more like either the wrong simulation code is being >>> executed on the serverside of things or the puppeteering client is >>> sending or receiving (or interpreting) wrong data.. Somewhere in the >>> communication someone isn't aware of the avatar being a "physical >>> avatar". >>> I think that the current UI being mousebased is useful, but yes, I >>> would love to have other input for it like script functions and >>> physical interfaces like mocap suits etc. >>> But the ability for realtime animation of avatars is a wonderful >>> exciting thing!!! It offers a lot of possibilities that right now are >>> just not possible in SL, and well.. really.. it's totally compelling >>> :-) >>> With things on the clientside already working really well, I don't see >>> too much trouble technically to make it work 'globally'. An array of >>> joint positions/rotations isn't that heavy... Am I overlooking >>> something? >>> Apologies for putting these issues on unsupported features up.. I >>> would just love to see this going to the next level, but can't do >>> anything when it comes to the serverside of things.. And maybe this >>> is just a matter of the wrong code running on the puppeteering SIM ? >>> >>> thnx and regards, >>> Evo >>> >> >> I haven't actually looked, I just asked Ops to build and put up the code. >> I'll go ping them and talk to the relevant people. >> >> In terms of finishing the code and pushing it out, well, that's partly >> why >> we released it to you guys. If someone here came up with a compelling >> instance of usage then yeah, it's possible we would revisit it. >> Internally, >> as an LL driven project it's unlikely - we just don't have the internal >> resources free to do large R&D on this particularly item right now - but >> we >> figure that's all the more reason to see what you guys can do with it. >> >> Never say never. >> >> Jake >> > > > > -- > http://www.creativemachinery.org > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From missannotoole at yahoo.com Mon Jun 9 15:03:57 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 9 15:03:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Message-ID: <186182.74892.qm@web59109.mail.re1.yahoo.com> I'm aware of the challenge/opportunity. Thus why I don't have much to say about it in negative unproductive terms (anymore :P ). My interest is in finding a way to increase both the storage capacity and efficiency of storing/loading while increasing protection against unauthorized access. My gut feeling is what I want will require better personal computer hardware. I do not think it is simple. This will require some creative thinking and hard work. If everyone had a powerful 64 bit pc/os with 4gb ram and high end video card then maybe an in memory database might be an interesting concept. But everyone doesn't have enough memory and processing power yet. Oracle is moving in this direction for heavy transaction systems to get hundreds of thousands of transactions per second with resiliency between network disconnects. Is the mysql effort doing anything similar? I doubt a lot of low hanging fruit is available The number and size factor of an entire sim's textures is large. The more you store the longer to find it to reload. etc etc. Doesn't mean we can't plan ahead. And try. ----- Original Message ---- From: Dante Tucker To: ordinal.malaprop@fastmail.fm Cc: Second Life Developer Mailing List Sent: Monday, June 9, 2008 5:38:57 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Now don't forget everything here is just opinion. The ultimate decision of what happens with the client is up to Linden Labs. My point is they will listen to everyone before making a decision, not just the few that rant here in this list. We look at things from a technical perspective, others will argue a different perspective. And in the end LL will take all into account. It's a balance really, no reason to get mad. On Mon, Jun 9, 2008 at 5:22 PM, wrote: On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: Dante Tucker wrote: Lets all just stop pretending anyone who wants to steal textures can't with the current system. Anyone who wants them can already get them. The only thing storing data raw would do is make them more accesable to people who don't want them and have no knoledge of how to get them currently. And if they don't want them then whats the harm? Agreed. I tire of people moaning about IP security. Your stuff is already stolen, deal with it. ~Tom Not to pick on Tom particularly here, but this is the sort of m message that reinforces my opinion that: (a) the people involved in discussing assets don't understand what those _creating_ the assets want or think; (b) they don't care. The level of snobbery applied here is breathtaking, endless references to pitchforks ho ho, you know, they're all irrational peasants. But even in the current situation, textures not being instantly obtainable by just going to the right directory and dragging to somewhere else is a disincentive to pirates. YES, we do all know about glintercept and all the other ways to get hold of textures. YES, we know that there is an intrinsic problem here, that displaying the damn assets implies that they are received by the client. YES, we've all heard these teenage extropian "information wants to be free" tropes, thanks all the same. Amazingly enough, people appreciate the practical issues. What they don't like is the idea that they are being treated as idiots and rubes by LL and assorted geeky types because they dare to get worried about the reason that they are there and building the world for you lot to play about with in the first place. Because, you know, if it wasn't for people who make content, you and I would not be here discussing this stuff, as I've said before. If you can't offer anything to content creators apart from "ha ha your stuff has already been stolen stupid n00bs" then you might as well close the whole company down right now. _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/648defe7/attachment.htm From jake at lindenlab.com Mon Jun 9 15:34:01 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 15:34:15 2008 Subject: [sldev] How Far For Security? In-Reply-To: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> Message-ID: <484DAFD9.6030009@lindenlab.com> I'd just like to make the point that a lot of LL reads these threads and we have lots of internal discussions about exactly stuff like this. We have one currently going regarding a feature we are talking about adding thats very much along these lines. "How far do we go to obstrufacate the data stream?" is the question. Bear in mind that some of the economy of Second Life is built upon people being able to build and have some degree of confidence that what they build won't get ripped off immediately by those who can, so they can be sure of getting some return on their investment of time. I'm sure you can understand how many in LL will be sympathetic to this thinking. Sure, technically anything can be reversed engineered (save scripts since they don't come to the client in any way) so the question becomes "how hard do we make it?" (or even "how hard CAN we make it?") - which is basically paraphrasing what's already been said in this thread. Stating "Well, because it's possible, don't even bother trying to stop it" doesn't (unfortunately) solve the issue of "how can I protect what I make" which is the root cry of anyone who spends time building things; it just undermines the Second Life economy to the point where it might potentially not be viable, obviously something people within in LL are keen to avoid. Please understand we are having the same discussions internally and what is said here is taken on board by those making the internal decisions, so keep at it. I'd like to rename this thread since it's quote a contentious name. Cheers Jake Dante Tucker wrote: > Now don't forget everything here is just opinion. The ultimate > decision of what happens with the client is up to Linden Labs. My > point is they will listen to everyone before making a decision, not > just the few that rant here in this list. We look at things from a > technical perspective, others will argue a different perspective. And > in the end LL will take all into account. It's a balance really, no > reason to get mad. > > On Mon, Jun 9, 2008 at 5:22 PM, > wrote: > > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: > > Lets all just stop pretending anyone who wants to steal > textures can't with the current system. Anyone who wants > them can already get them. The only thing storing data raw > would do is make them more accesable to people who don't > want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? > > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > > ~Tom > > > Not to pick on Tom particularly here, but this is the sort of m > message that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what > those _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless > references to pitchforks ho ho, you know, they're all irrational > peasants. But even in the current situation, textures not being > instantly obtainable by just going to the right directory and > dragging to somewhere else is a disincentive to pirates. > > YES, we do all know about glintercept and all the other ways to > get hold of textures. YES, we know that there is an intrinsic > problem here, that displaying the damn assets implies that they > are received by the client. YES, we've all heard these teenage > extropian "information wants to be free" tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What > they don't like is the idea that they are being treated as idiots > and rubes by LL and assorted geeky types because they dare to get > worried about the reason that they are there and building the > world for you lot to play about with in the first place. Because, > you know, if it wasn't for people who make content, you and I > would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From danteferret at gmail.com Mon Jun 9 15:51:17 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 15:51:19 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> Could you give a quick description of that file? For some downloading it is not a possibility. On Mon, Jun 9, 2008 at 5:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/480a09ea/attachment.htm From lenglish5 at cox.net Mon Jun 9 16:21:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 16:21:29 2008 Subject: [sldev] iphone 3D client possible? Message-ID: <484DBAF7.9000308@cox.net> I don't know the difference between OpenGL and OpenGL ES, but Apple claims hardware OpenGL ES acceleration for the new iPhone. Does this mean that some subset of the 3D viewer code will be implementable on the iPhone? Lawson From me at signpostmarv.name Mon Jun 9 16:23:51 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Jun 9 16:23:53 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> References: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> Message-ID: <484DBB87.90604@signpostmarv.name> I believe it refers to http://www.massively.com/2008/05/29/high-end-graphics-features-planned-for-second-life/ Dante Tucker wrote: > Could you give a quick description of that file? For some downloading > it is not a possibility. > > On Mon, Jun 9, 2008 at 5:34 PM, Brandon Husbands > wrote: > > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/30d2e260/smime.bin From gigstaggart at gmail.com Mon Jun 9 16:34:50 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 16:34:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> Message-ID: <484DBE1A.8040008@gmail.com> Kent Quirk (Q Linden) wrote: > Personally (I'm not speaking for Linden here), I think that if we want > to change the way we do caching, we should make it slightly > complicated to grab items out of the cache by NOT storing them in > standard formats. Do you use "right click protection" javascript on web pages you design, to prevent people from "stealing" your images? It's the same thing. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/19f0a405/smime.bin From daveh at lindenlab.com Mon Jun 9 16:38:18 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Mon Jun 9 16:38:21 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484DBAF7.9000308@cox.net> References: <484DBAF7.9000308@cox.net> Message-ID: OpenGL ES is a subset of OpenGL. Its basically had all the intermediate calls removed in favour of vertex arrays. There's been some cool stuff done with the iphone: someone ported quake 3! http://www.youtube.com/watch?v=kvci1vTXyUo Unfortunately I doubt its got enough power to run SL. On 10 Jun 2008, at 00:21, Lawson English wrote: > I don't know the difference between OpenGL and OpenGL ES, but Apple > claims hardware OpenGL ES acceleration for the new iPhone. Does this > mean that some subset of the 3D viewer code will be implementable on > the iPhone? > > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d4ed8ee6/attachment.htm From sldev at bitparts.org Mon Jun 9 16:41:38 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Mon Jun 9 16:41:44 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484DBFB2.4070801@bitparts.org> How about this, then - to the same thing we do now, storing the header in the binary cache, and the bulk of the data in a raw file - just change it from a (CPU-intensive) JPG2000 decode to a (CPU-cheap) TGA or whatever raw format the client uses inside the code? Or even if you just stored the first (arbitrary-number) of bytes in the textures.cache file, with the rest coming from the existant UUID-named file? The bottleneck, as I have demonstrated through the use of a RAMdisk cache folder, is definitely the decoding. -Buckaroo ps - 'scuse my top-posting, I know it's frowned on, but damnit, it just makes it easier to read. -b Jake Simpson wrote: > I'd just like to make the point that a lot of LL reads these threads > and we have lots of internal discussions about exactly stuff like > this. We have one currently going regarding a feature we are talking > about adding thats very much along these lines. > > "How far do we go to obstrufacate the data stream?" is the question. > > Bear in mind that some of the economy of Second Life is built upon > people being able to build and have some degree of confidence that > what they build won't get ripped off immediately by those who can, so > they can be sure of getting some return on their investment of time. > I'm sure you can understand how many in LL will be sympathetic to this > thinking. Sure, technically anything can be reversed engineered (save > scripts since they don't come to the client in any way) so the > question becomes "how hard do we make it?" (or even "how hard CAN we > make it?") - which is basically paraphrasing what's already been said > in this thread. Stating "Well, because it's possible, don't even > bother trying to stop it" doesn't (unfortunately) solve the issue of > "how can I protect what I make" which is the root cry of anyone who > spends time building things; it just undermines the Second Life > economy to the point where it might potentially not be viable, > obviously something people within in LL are keen to avoid. > > Please understand we are having the same discussions internally and > what is said here is taken on board by those making the internal > decisions, so keep at it. > > I'd like to rename this thread since it's quote a contentious name. > > Cheers > > Jake > From gbrandon at gmail.com Mon Jun 9 17:18:32 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Jun 9 17:18:35 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: On Mon, Jun 9, 2008 at 6:34 PM, Jake Simpson wrote: > Stating "Well, because it's possible, don't even bother trying to stop it" > doesn't (unfortunately) solve the issue of "how can I protect what I make" > which is the root cry of anyone who spends time building things; it just > undermines the Second Life economy to the point where it might potentially > not be viable, obviously something people within in LL are keen to avoid. The thing I worry about is people having the wrong idea. Which would you prefer: a. Go ahead and be like the web where people know they have to protect their own assets or b. Make people think it's LL's job to protect their assets, and make them angry at you when it turns out it doesn't work the way they thought? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/529fe54a/attachment-0001.htm From gigstaggart at gmail.com Mon Jun 9 17:23:31 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 17:23:34 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DBFB2.4070801@bitparts.org> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484DBFB2.4070801@bitparts.org> Message-ID: <484DC983.9030301@gmail.com> Buckaroo Mu wrote: > How about this, then - to the same thing we do now, storing the header > in the binary cache, and the bulk of the data in a raw file - just > change it from a (CPU-intensive) JPG2000 decode to a (CPU-cheap) TGA or It's definitely a possibility. The thing is, recompressing into another lossy format will lose some quality. If we are going to do that though, S3TC is probably the way to go, that's video card native. I've experimented with some rough patches to enable S3TC recompression, the loss in quality is noticeable, but not terrible. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/ffe10d89/smime.bin From lenglish5 at cox.net Mon Jun 9 17:28:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 17:28:42 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: References: <484DBAF7.9000308@cox.net> Message-ID: <484DCAB8.80100@cox.net> Dave Hillier wrote: > OpenGL ES is a subset of OpenGL. Its basically had all the > intermediate calls removed in favour of vertex arrays. > > There's been some cool stuff done with the iphone: someone ported > quake 3! http://www.youtube.com/watch?v=kvci1vTXyUo > Unfortunately I doubt its got enough power to run SL. > Maybe the old iPhone couldn't do it, but the new one? I'm pretty sure some reasonably robust subset of the current SL 3D graphcis will run at acceptable framerates. http://events.apple.com.edgesuite.net/0806wdt546x/event/index.html This kills, well, slaughters, a LOT of platforms, I think. $200 for the base model. Lawson From GordonWendt at gmail.com Mon Jun 9 18:08:32 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 18:08:35 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> Message-ID: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> With all due respect if you have linden after your name (Q Linden in this case) then you are going to be assumed to be speaking for LL every time you post anywhere, is it fair? no but that's life on a mailing list that the company you works for runs. On the topic of obscurity through obscurity it doesn't work, period. People can easily figure out that glintercept is at glintercept.nutty.org, anytime I post on the forums people see that since I link to it from my signature. To discourge piracy either go full out or leave it out in the open and make the platform allow people to implement their own solutions to this. -G.W. On Mon, Jun 9, 2008 at 5:36 PM, Kent Quirk (Q Linden) wrote: > > On Jun 9, 2008, at 5:22 PM, ordinal.malaprop@fastmail.fm wrote: > > >> On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: >> >> Dante Tucker wrote: >>> >>>> Lets all just stop pretending anyone who wants to steal textures can't >>>> with the current system. Anyone who wants them can already get them. The >>>> only thing storing data raw would do is make them more accesable to people >>>> who don't want them and have no knoledge of how to get them currently. And >>>> if they don't want them then whats the harm? >>>> >>> Agreed. >>> >>> I tire of people moaning about IP security. >>> >>> Your stuff is already stolen, deal with it. >>> >>> ~Tom >>> >> >> Not to pick on Tom particularly here, but this is the sort of m message >> that reinforces my opinion that: >> >> (a) the people involved in discussing assets don't understand what those >> _creating_ the assets want or think; >> (b) they don't care. >> >> The level of snobbery applied here is breathtaking, endless references to >> pitchforks ho ho, you know, they're all irrational peasants. But even in the >> current situation, textures not being instantly obtainable by just going to >> the right directory and dragging to somewhere else is a disincentive to >> pirates. >> >> YES, we do all know about glintercept and all the other ways to get hold >> of textures. YES, we know that there is an intrinsic problem here, that >> displaying the damn assets implies that they are received by the client. >> YES, we've all heard these teenage extropian "information wants to be free" >> tropes, thanks all the same. >> >> Amazingly enough, people appreciate the practical issues. What they don't >> like is the idea that they are being treated as idiots and rubes by LL and >> assorted geeky types because they dare to get worried about the reason that >> they are there and building the world for you lot to play about with in the >> first place. Because, you know, if it wasn't for people who make content, >> you and I would not be here discussing this stuff, as I've said before. >> >> If you can't offer anything to content creators apart from "ha ha your >> stuff has already been stolen stupid n00bs" then you might as well close the >> whole company down right now. >> >> > Boy, I can totally see both sides of this argument. > > It's true -- if we're displaying it, it can be copied with a relatively > small amount of work for a motivated individual with technical skill. > > It's *also* true that if it's trivially easy to copy it, it will be copied > much more frequently than if it's slightly harder. This is why "security by > obscurity" is popular. The extra step makes it obvious that you're taking > some measure -- no matter how simple -- to break a protection scheme, and > that sense of an explicit violation does deter a lot of people. > > So while I completely agree that there's no way we can provide true > protection, I also agree that simply stuffing the files into a directory > using standard formats is kind of like leaving your bike unlocked in the > street -- someone will ride off with it who might not have bothered if you > used even a cheap bike lock. > > Personally (I'm not speaking for Linden here), I think that if we want to > change the way we do caching, we should make it slightly complicated to grab > items out of the cache by NOT storing them in standard formats. > > > Q > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/05c72485/attachment.htm From secret.argent at gmail.com Mon Jun 9 18:16:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:14:48 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> Message-ID: <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> On 2008-06-09, at 13:11, Dahlia Trimble wrote: > I dont see why the requested functionality couldn't work with > existing channels, or am I missing something here? The intent was that the requested functionality would, in fact, use existing channels... not new connections. I'm not sure why the issue is even being brought up, to tell the truth. From GordonWendt at gmail.com Mon Jun 9 18:16:38 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 18:16:41 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <493033a70806091816v338d4565mcfb85a62537f9e07@mail.gmail.com> @Kent, to correct my phrasing slightly on the above post you may not be speaking as LL however by definition as an employee your statements still carry certain weight coming from someone from LL although I'll admit that's a very tricky distinction. @Jason, javascript protection of course is quite pointless since even a ten year old can bypass it, as is the same here if your sending data to somebody's computer it's impossible to protect unless you A) don't send it at all which defeats the purose, or B) have total control of the end system and the entire path from the beginning to the end, which is quite frankly impossible due to the nature of the internet, computing, not to mention that nobody will give up total control of their system and you'd need a different system run by each company that you have software from. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/151edc2a/attachment-0001.htm From secret.argent at gmail.com Mon Jun 9 18:19:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:17:48 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484D8605.4090200@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> Message-ID: On 2008-06-09, at 14:35, SignpostMarv Martin wrote, regarding Laurent's suggestion for a sim cache: > referenced by name or sim UUID ? I would think that since it's a cache it doesn't really matter. If the UUID is well distributed it could use it directly, or the sim name, or a hash of the sim name. It probably doesn't even matter much if there's sim name collisions. From secret.argent at gmail.com Mon Jun 9 18:22:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:21:01 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <410A9BDF-B4EF-4BD3-87FD-4BD8AFBA6320@gmail.com> On 2008-06-09, at 16:22, ordinal.malaprop@fastmail.fm wrote: > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. I don't think I've seen that attitude from LL. From certain people, yes, but generally not the Lindens. And as I suggested in a previous message, an efficient cache with enough obfuscation to keep the honest honest is entirely possible. From secret.argent at gmail.com Mon Jun 9 18:30:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:29:12 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: If you use a raw format that's efficiently decoded by the client, with a header containing metadata, in an undocumented format with an undocumented size, then you'll have as much obscurity as you have now in a format that is perhaps bulkier but certainly will consume less CPU time to extract. And if you store the data by UUID or by a simple collision-free permutation of the UUID rather than going through VFS it should be possible to expand the texture cache on disk significantly. How far to go for obscurity? Only so far as it makes it easier to use GLintercept than to hack the cache. :) From secret.argent at gmail.com Mon Jun 9 18:46:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:45:03 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: On 2008-06-09, at 19:18, Brandon Lockaby wrote: > a. Go ahead and be like the web where people know they have to > protect their own assets The failure of so many web ventures, and the "dot bomb", suggests that the internet is not automatically the best model to follow. People do better work when they get rewarded. People are not capable of "protecting their own assets". The corollary of (a) is "eliminate a huge portion of the SL economy, and possibly go out of business". > b. Make people think it's LL's job to protect their assets, and > make them angry at you when it turns out it doesn't work the way > they thought? The corollary of (b) is "you always have angry customers, you have to learn to deal with them and where possible prevent the problems that they're angry about... it's part of the cost of staying in business." I've taken the opposite side of many of LL's decisions, and I still think they made a mistake removing large portions of the simulated economy in SL... it's caused a lot of problems, and led to a lot of bad behavior. I also don't approve of some changes in the fine details of the rights system, like enabling the creation of objects that can neither be copied or transferred. But I certainly can't complain about them being cautious about making changes that might remove the rest of the economic simulation by making everything too obviously free. Can you see a way to retain the Linden economy without people buying things in SL? From secret.argent at gmail.com Mon Jun 9 18:49:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:48:32 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> On 2008-06-09, at 20:08, Gordon Wendt wrote: > On the topic of obscurity through obscurity it doesn't work, period. Depends on what you mean by "working". It works well enough to make honest people treat a purchased object as having value. Does it need to work any better than that? All DRM schemes are no better than "honor system" deep. They work because most people don't need any more incentive than that. From robla at lindenlab.com Mon Jun 9 18:48:44 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 9 18:48:47 2008 Subject: [sldev] [POLICY] Devise better way to discuss hotbutton issues on sldev Message-ID: <484DDD7C.9090606@lindenlab.com> We have a tendency on the sldev mailing lists to have long threads that extend for a very long time, which seem irreconcilable. The current sldev posting guidelines aren't helping either (though perhaps that's only because people haven't been reminded, see: https://wiki.secondlife.com/wiki/SLDev ) Common hotbuttons: * IP address privacy. ** Discussed in JIRA here: SVC-241 ** Currently being replayed on sldev in the "Re: [sldev] Puppettering Branch" * What level of protection to put on in-world textures. ** Discussed in JIRA here: VWR-2909 ** Currently being replayed on sldev as "Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation" At a minimum, we have to do better at documenting the debate, perhaps with FAQs for each side of the discussion, so that at least we can pick up where we left off rather than starting from the beginning. I've filed this issue to discuss this problem: https://jira.secondlife.com/browse/MISC-1267 Please direct replies there rather than on-list. Thanks Rob From lenglish5 at cox.net Mon Jun 9 18:57:18 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 18:57:22 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <484DDF7E.9090306@cox.net> Gordon Wendt wrote: > With all due respect if you have linden after your name (Q Linden in > this case) then you are going to be assumed to be speaking for LL > every time you post anywhere, is it fair? no but that's life on a > mailing list that the company you works for runs. > > On the topic of obscurity through obscurity it doesn't work, period. > People can easily figure out that glintercept is at > glintercept.nutty.org , anytime I post > on the forums people see that since I link to it from my signature. > To discourge piracy either go full out or leave it out in the open and > make the platform allow people to implement their own solutions to this. > Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson From gbrandon at gmail.com Mon Jun 9 19:12:12 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Jun 9 19:12:15 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484DDF7E.9090306@cox.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <484DDF7E.9090306@cox.net> Message-ID: I think in the end we're just gonna see more tools that make it as easy to copy things as people want it to be. In that case it won't matter what kind of cache this viewer uses. I think if that doesn't happen it would be a result of SL falling out of favor as the world wide VW platform, or remaining what it is until a more robust one comes along. In summary, I believe if SL is successful, we will see tools come along that make these cache security decisions pointless. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/eea227d4/attachment-0001.htm From secret.argent at gmail.com Mon Jun 9 19:16:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 19:15:42 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484DBB87.90604@signpostmarv.name> References: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> <484DBB87.90604@signpostmarv.name> Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > I believe it refers to http://www.massively.com/2008/05/29/high-end- > graphics-features-planned-for-second-life/ I don't think that will make it into RC10, or 1.21, or 1.22, ... From GordonWendt at gmail.com Mon Jun 9 19:16:55 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 19:16:58 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484DDF7E.9090306@cox.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <484DDF7E.9090306@cox.net> Message-ID: <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment.htm From soft at lindenlab.com Mon Jun 9 19:22:42 2008 From: soft at lindenlab.com (Soft) Date: Mon Jun 9 19:22:45 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? That's a long-term feature. No. The intent of the RC branch is that subsequent RCs at a given version number contain bug fixes only. From missannotoole at yahoo.com Mon Jun 9 20:08:01 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 9 20:08:04 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> Here is what some of the people on this list come across like: Let's say you have a town full of people worried about terrorists making home made bombs. Here comes a resident yelling obscenities at them, calling them stupid, yelling that there is nothing that can be done about it, and handing out flyers with instructions on how to make fertilizer bombs. Doesn't matter if it is right or wrong the behavior is antisocial and unacceptable. Thats the mentality I see going on. The professional nature of this list has vanished. I think LL needs to clean this list up and deal with it. The number of people causing problems is small and finite and I don't see much code or ideas coming from them. This list is an LL list and as such should fall under the TOS/CS and abusive behavior should be rewarded with suspensions from Secondlife and if it continues then the SL accounts be revoked. IMHO anyway. If obfuscation happens to be part of a new way to manage cache so more can be stored and the performance be improved then I'm all for it. However, the cache performance is what counts. The number of bytes being transferred is becoming critical. And may soon become very expensive. Can we return to finding ways to improve the cache now? ----- Original Message ---- From: Gordon Wendt To: Second Life Developer Mailing List Sent: Monday, June 9, 2008 10:16:55 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment.htm From GordonWendt at gmail.com Mon Jun 9 20:22:32 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 20:22:35 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <988916.32450.qm@web59107.mail.re1.yahoo.com> References: <988916.32450.qm@web59107.mail.re1.yahoo.com> Message-ID: <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> Apologies to Ann for the double post since gmail at least automatically wants to send it directly to whoever sent the original message to the list. If you would like to skip to my ontopic comments on this conversation please skip to the second paragraph. @Ann Ironically you just displayed the same behavior you said should be banned and I take great offense at you comparing people who disagree with you on the topic of obsfucating information to terrorists. Other than your post here attacking other resident's directly I don't see any personal attacks just attacks on each other's arguments which is the nature of such discourse when not everybody agrees. Incidentally it seems so far that LL knows that off topic conversations and arguments go on in the list and as long as the main conversation goes along and as long as they are quick and not overly disruptive these arguments seem to be overlooked... this is just from my experience so far and Rob and the other list admins take action as they see fit without much regard to precedent. On the topic of the issue though since this really is getting off topic I'm sure there is some middleground in terms of performance but it seems like high performance would require changing the fundamental way that images are sent, recieved, and dealt with by the server and client respectively although I'd be interested if LL or anyone else has data on where the slowest parts of the process are since I'm not sure we know for sure that encoding is where the bottleneck is although that is unfortunately the only part that can really be directly seen except by LL since we don't know what goes on serverside. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment.htm From schlenk at uni-oldenburg.de Mon Jun 9 23:00:48 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Mon Jun 9 23:00:43 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> References: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> Message-ID: <484E1890.1080604@uni-oldenburg.de> Argent Stonecutter schrieb: > On 2008-06-09, at 02:22, Dale Mahalko wrote: >> A move to a local MySQL database > > God no. > > sqlite, please. Without all the MySQL "I'm pretending to be a real > database engine" overhead. SQLites pretty good for some stuff, but caching blob data is not one of it due to the required frequent fsync() calls needed to maintain transactions. (just see the current discussion around Firefox 3 being very slow on Ubuntu). But MySQL is an even worse idea... I had to write a heavily parallel (targeting some 1000 parallel writing threads) blob storage system for a different application and using SQLite, even only for storing the metadata leads to heavy lock contention and made the system far less scalable. Current filesystems like NTFS or ext3 are pretty okay for storing files and metadata, they are made for that kind of usecase..., its even faster to do a stat() on disk than to lookup stuff in sqlite in most cases. Michael From gigstaggart at gmail.com Mon Jun 9 23:34:11 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 23:34:15 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484E2063.20806@gmail.com> Argent Stonecutter wrote: > The corollary of (a) is "eliminate a huge portion of the SL economy, > and possibly go out of business". Yes, because the entire economy collapsed the day after copybot came out. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/62bc0b25/smime.bin From gigstaggart at gmail.com Mon Jun 9 23:37:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 23:37:12 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> Message-ID: <484E2114.5000902@gmail.com> Argent Stonecutter wrote: > All DRM schemes are no better than "honor system" deep. They work > because most people don't need any more incentive than that. Yes, exactly. Which is why we do not need to add additional complexity and bugs, and inconvenience for legitimate users by adding them at all. Most people are honest, and most people will remain honest. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/6e4a9aa9/smime.bin From tateru.nino at gmail.com Tue Jun 10 00:29:15 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 00:30:03 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Message-ID: <484E2D4B.2010407@gmail.com> I've just checked 3 WinXP systems (two with SP2 and one with SP3) and the registry settings for wininet for HTTP/1.0 and HTTP/1.1 connections are set to 0xa (10) on all of them. That's HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. Teravus Ovares wrote: > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it appears > that it does. When two threads get stuck, it fails to do anything > else via http. We've tried to use HTTP CAPS for inventory, and > consistently, when the inventory service runs slow, the client stops > making *any* further http requests. > > Best Regards > > Teravus > > > On 6/9/08, *Tateru Nino* > wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This > is a SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections > with any server or proxy. A proxy SHOULD use up to 2*N connections > to another server or proxy, where N is the number of > simultaneously active users." > > I've got personal knowledge that the author did not intend the > above to apply to situations like this. For the substrate to MSIE, > however, it is entirely appropriate. Also, the above only applies > to persistent connections, not non-persistent connections > (applying the same guideline to non-persistent connections would > cause problems that this guideline is intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the > Web, and connection considerations in Web architecture over HTTP > are different to other architectures over HTTP. > > > > > > Teravus Ovares wrote: > > I also note, that according to Microsoft's kb article: > "The HTTP 1.1 specification (RFC2616) mandates the > two-connection limit. The four-connection limit for HTTP 1.0 > is a self-imposed restriction that coincides with the standard > that is used by a number of popular Web browsers." > You can read the article here: > http://support.microsoft.com/kb/183110 > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > Best Regards > Teravus > > From secret.argent at gmail.com Tue Jun 10 00:46:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 00:45:17 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484E2063.20806@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: On 2008-06-10, at 01:34, Jason Giglio wrote: > Argent Stonecutter wrote: >> The corollary of (a) is "eliminate a huge portion of the SL economy, >> and possibly go out of business". > > Yes, because the entire economy collapsed the day after copybot > came out. Don't be silly. If copybot had not been broken, incomplete, and horribly inconvenient, if it been built into the standard client, with right click "show source" and "save as" that worked like "show source" and "save as" in a browser (because that IS what "treat it like the web" implies) in a browser and let you trivially grab all prims and assets in a convenient form for uploading as your own product, then... yes... it likely would have. From secret.argent at gmail.com Tue Jun 10 00:50:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 00:49:19 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484E2114.5000902@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> <484E2114.5000902@gmail.com> Message-ID: On 2008-06-10, at 01:37, Jason Giglio wrote: > Argent Stonecutter wrote: >> All DRM schemes are no better than "honor system" deep. They work >> because most people don't need any more incentive than that. > > Yes, exactly. Which is why we do not need to add additional > complexity > and bugs, Which is not what I'm suggesting. > Most people are honest, and most people will remain honest. Most people are pretty honest. Most people will remain pretty honest as long as that's the easy way. But when I drive the speed limit pretty much everyone passes me, and most people don't bother donating to the building fund but will buy a ticket to the museum, so long as there's someone at the door taking tickets. From lenglish5 at cox.net Tue Jun 10 00:53:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 00:53:21 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> Message-ID: <484E32ED.2080605@cox.net> Argent Stonecutter wrote: > On 2008-06-09, at 13:11, Dahlia Trimble wrote: >> I dont see why the requested functionality couldn't work with >> existing channels, or am I missing something here? > > The intent was that the requested functionality would, in fact, use > existing channels... not new connections. I'm not sure why the issue > is even being brought up, to tell the truth. > > _ Cause I'm an ijit? Lawson From lenglish5 at cox.net Tue Jun 10 01:02:44 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:02:48 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: <484E3524.6040008@cox.net> Argent Stonecutter wrote: > On 2008-06-10, at 01:34, Jason Giglio wrote: >> Argent Stonecutter wrote: >>> The corollary of (a) is "eliminate a huge portion of the SL economy, >>> and possibly go out of business". >> > >> Yes, because the entire economy collapsed the day after copybot came >> out. > > Don't be silly. If copybot had not been broken, incomplete, and > horribly inconvenient, if it been built into the standard client, with > right click "show source" and "save as" that worked like "show source" > and "save as" in a browser (because that IS what "treat it like the > web" implies) in a browser and let you trivially grab all prims and > assets in a convenient form for uploading as your own product, then... > yes... it likely would have. > > _ There's no provision in the average browser for extracting and then republishing content on the same website you extracted it from in the first place. Certainly not with the possibility of getting paid right then and there if you do it. Many of the technical details of SL fit or can be made to fit the web, but the social/interaction details are quite different, IMHO. Lawson From gbrandon at gmail.com Tue Jun 10 01:20:05 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Tue Jun 10 01:20:08 2008 Subject: [sldev] Security issues/Thank you/Congratulations Message-ID: When I first started digging into the SL protocol, it seemed like just about everything I tried to do uncovered a security issue. For awhile I thought we were just doomed, I mean it :D Alot of you who work with the protocol surely know the sort of thing I'm talking about! But right now I'm breathing a sigh of relief because from my point of view, things have been changing fast! Granted, there are still issues, and I'm sure they won't dry up just yet as I see an increasing number of people deciding to work with the protocol lately, but as of now I can honestly say I don't know a way to crash the official viewer or ruin someone's business just by using the intended client/server protocols on LL's grid. So I want to thank Linden Lab for responding so well to security issues, and say congratulations! As far as I'm concerned the response to these issues is stellar. And I want to extend thanks to everyone who makes an effort to report security issues. I know many of these people are probably nervous about talking publically about the things they've seen but they deserve some recognition. Well here is a huge THANK YOU to EVERYONE involved in helping improve Second Life in this very important way! :D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cd567181/attachment.htm From lenglish5 at cox.net Tue Jun 10 01:22:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:22:28 2008 Subject: [sldev] [AWG] AW Groupies meeting Tuesday. Topic: Dawn of the virtual worlds internet Message-ID: <484E39BC.8010405@cox.net> Tuesday, 10 June 2008, 9:30 AM AW Groupies meeting. Topics for discussion will likely include: * last week's successful login using the Second Life development server to rez an avatar in an OpenSim region. This is relatively minor technical step away from TP between SL and OpenSim (after that comes the hard part: trying to get the social/economic stuff right). http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ * possibly more info on the new Python-based test-harness based on the new protocols used above. http://wiki.secondlife.com/wiki/AWG_Test_Harness As always, IM Zha Ewry, Tree Kyomoon or Saijanai Kuhn in-world for a group invite to get to the AW Groupies meeting. AW Groupies is the [generally very techno-geek] in-world discussion group for the Architecture Working Group, a collaboration between Linden Lab, IBM, libsecondlife, OpenSim, and others, to create system of virtual worlds that can inter-operate with each other using an open system of internet protocols. http://wiki.secondlife.com/wiki/Architecture_Working_Group http://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs Lawson (Saijanai Kuhn) From lenglish5 at cox.net Tue Jun 10 01:39:00 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:39:03 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <484E3DA4.7020801@cox.net> Soft wrote: > On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > >> http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html >> >> Is this going to make it into rc10? >> > > That's a long-term feature. No. > > The intent of the RC branch is that subsequent RCs at a given version > number contain bug fixes only. > _______________________________________________ > Intent yes, reality? ;-) Lawson From me at signpostmarv.name Tue Jun 10 02:43:27 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:43:30 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484E4CBF.5060203@signpostmarv.name> Q Linden wrote: > Personally (I'm not speaking for Linden here), I think that if we want > to change the way we do caching, we should make it slightly > complicated to grab items out of the cache by NOT storing them in > standard formats. Jason Giglio wrote: > It's definitely a possibility. The thing is, recompressing into another > lossy format will lose some quality. > > If we are going to do that though, S3TC is probably the way to go, > that's video card native. Argent Stonecutter wrote: > If you use a raw format that's efficiently decoded by the client, with > a header containing metadata, in an undocumented format with an > undocumented size, then you'll have as much obscurity as you have now > in a format that is perhaps bulkier but certainly will consume less > CPU time to extract. If a non-standard format is used, it'll only be useful in the short term. 1) Code gets released 2) Code is either documented or becomes documented 3) Wide adoption of Second Life makes said non-standard format become de-facto standard for virtual worlds. A standard image codec that is "native" to OpenGL encapsulated in a container format which allows metadata to be embedded that is either standardised but traditionally unrelated to 3D software assets (Ogg ?) or a proprietary non-standard format would seem preferable to using a non-standard image format. Not that I am likely to develop software that would use such a system, but I would think that using unrelated standardised container/codec formats would still have a security-through-obscurity edge, since although all the tools for working with the individual formats are out there, people would have to scratch their heads while they figure out how to glue them together (unless working directly with the SL source code, which would be intended for loading assets into a 3D environment, not viewing/editing said assets via an image editor) ~ Marv -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/1eaa6cc2/smime.bin From me at signpostmarv.name Tue Jun 10 02:55:15 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:55:16 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484DCAB8.80100@cox.net> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> Message-ID: <484E4F83.7000402@signpostmarv.name> Lawson English wrote: > Maybe the old iPhone couldn't do it, but the new one? I'm pretty sure > some reasonably robust subset of the current SL 3D graphcis will run > at acceptable framerates. Is having the exact same experience necessary at "acceptable" framerates even necessary ? Why not go a different route with an iPhone client, and just have a cut-down IM client that has a 3D background ? Taking a cue from SLeek's interface, only give iPhone users the option to "move avatar to landing point" "touch objects with touch_events or left-click configs" and "sit on object with sit target or left-click config for sitting". At least initially, trying to do *everything* you do in SL on a desktop/laptop computer on a portable device would just seem rather..... stupid ? While it's conceivable you could build something via an iPhone (multi-touch rescale & rotate anyone ? ), I'd imagine that content-creators are likely to prefer desktop/laptop computing environments, and that portable devices such as the iPhone would be best suited to the content-consumer crowd. Since the frame rate on the iPhone may be low till the view can be optimised, rather than try to mirror the experience on a portable device, why not just give the option to (focus on object/avatar) with basic pan/rotate/zoom controls ? Exploring an environment in the traditional way (e.g. walking/flying around) may be too cumbersome to do on a portable device (either due to confined interface space or low-framerates), so why not have portable device viewers focus on how people explore when under heavy lag- move the camera, not the avatar ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d64efb03/smime-0001.bin From me at signpostmarv.name Tue Jun 10 02:57:32 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:57:35 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484E3DA4.7020801@cox.net> References: <484E3DA4.7020801@cox.net> Message-ID: <484E500C.4060400@signpostmarv.name> Since the Shadow branch is restricted to GeForce 8 GPUs only, it would make more sense to release it as a First Look viewer, not an RC. ~ Marv. Lawson English wrote: > Soft wrote: >> On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands >> wrote: >> >>> Is this going to make it into rc10? >> That's a long-term feature. No. >> >> The intent of the RC branch is that subsequent RCs at a given version >> number contain bug fixes only. >> _______________________________________________ >> > Intent yes, reality? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/7107d6a6/smime.bin From lenglish5 at cox.net Tue Jun 10 03:08:01 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 03:08:03 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <484E5281.8050102@cox.net> SignpostMarv Martin wrote: > > Lawson English wrote: >> Maybe the old iPhone couldn't do it, but the new one? I'm pretty >> sure some reasonably robust subset of the current SL 3D graphcis will >> run at acceptable framerates. > > Is having the exact same experience necessary at "acceptable" > framerates even necessary ? > > Why not go a different route with an iPhone client, and just have a > cut-down IM client that has a 3D background ? > > Taking a cue from SLeek's interface, only give iPhone users the option > to "move avatar to landing point" "touch objects with touch_events or > left-click configs" and "sit on object with sit target or left-click > config for sitting". > > At least initially, trying to do *everything* you do in SL on a > desktop/laptop computer on a portable device would just seem > rather..... stupid ? > While it's conceivable you could build something via an iPhone > (multi-touch rescale & rotate anyone ? ), I'd imagine that > content-creators are likely to prefer desktop/laptop computing > environments, and that portable devices such as the iPhone would be > best suited to the content-consumer crowd. > > Since the frame rate on the iPhone may be low till the view can be > optimised, rather than try to mirror the experience on a portable > device, why not just give the option to (focus on object/avatar) with > basic pan/rotate/zoom controls ? Exploring an environment in the > traditional way (e.g. walking/flying around) may be too cumbersome to > do on a portable device (either due to confined interface space or > low-framerates), so why not have portable device viewers focus on how > people explore when under heavy lag- move the camera, not the avatar ? > Its a thought, and I don't know how the iPhone 2 will perform, but looking at the console games demos, I wouldn't be surprised if a properly designed SL client couldn't be usable even in 3D. Certainly, the [eventual] Python test harness library could be adapted for use on the iPhone and give Sleek-like capabilities. Would need to be rewritten in ObjC of course. Lawson From me at signpostmarv.name Tue Jun 10 03:42:54 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 03:42:55 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> Message-ID: <484E5AAE.5030507@signpostmarv.name> Argent Stonecutter wrote: > On 2008-06-09, at 14:35, SignpostMarv Martin wrote, regarding > Laurent's suggestion for a sim cache: >> referenced by name or sim UUID ? > > I would think that since it's a cache it doesn't really matter. If the > UUID is well distributed it could use it directly, or the sim name, or > a hash of the sim name. It probably doesn't even matter much if > there's sim name collisions. Clarification: VFS references, or LLSD list of assets UUIDs ? Problem 1) Sim gets renamed. Does the UUID stay the same ? Use case: metaverse development company X gets hired to develop a sim for company Y. company X owns the sim while the work is being done (with an inconspicuous name so as to avoid PR issues), company X then transfers ownership of sim to company Y. Company Y has name of sim changed. No assets within the sim are changed. Problem 2) beta grid vs main grid (and LL's SL vs OpenSim). Use case: aside from visitors, region A is identical on both grids. region B has a few differences (one or two buildings weren't yet erected at the time the beta grid snapshot was made). region C is completely different- few if none identical assets. Problem 3) region being withdrawn. Use case: short term events, like Burning Life/ SL Birthday With problem 1, if the cache is references by name, then you just duplicated your effort. if the cache references by UUID, then the region UUID should remain the same, lest the same duplicated effort issue crops up. With problem 2, in case C, you'll have the cache reference bloat to twice the size it needs to be. Garbage collection: Problem 2) If regions have the same identifier, when the viewer connects to one grid then the other, you'll either have twice the amount of assets loaded than is needed, or you'll have half of the assets going missing and needing to re-download. If identical sims on seperate grids have the same content, but different UUIDs, should such region-based caching make allowances for that ? Also, because of case C in problem 2, such a region-based referencing mechanism should probably have the grid the region is attached to as a root reference. Problem 3) Assuming the grid-based root reference is in place, I shall illustrate a conversation between the viewer and server that solves problem 3: Viewer) (upon login) "Does region x exist within the grid ?" Server) "Yes" (load/fetch referenced assets). "No" (remove region reference files) The server's response of "Yes"/"No" should not be based upon credentials (e.g. whether or not a Resident can access the given region should not be taken into account). ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/caef6888/smime.bin From aimee at ama-zing.co.uk Tue Jun 10 03:57:47 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jun 10 03:57:53 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <82890598-11BF-4F3D-8FCA-861AE11E6443@ama-zing.co.uk> Vollee has a vaguely usable SL client "running" (I think they're cheating and just streaming the video from elsewhere) on various phones including the iPhone. It's not perfect, but the couple of times I've tried it on my N95 it wasn't _too_ painful, it at least served the purpose of getting in world, moving around a bit and talking to people. http://rblog.rezmagazine.co.uk/2008/06/second-life-on-move.html Aimee, On Jun 10, 2008, at 10:55, SignpostMarv Martin wrote: > > Lawson English wrote: >> Maybe the old iPhone couldn't do it, but the new one? I'm pretty >> sure some reasonably robust subset of the current SL 3D graphcis >> will run at acceptable framerates. > > Is having the exact same experience necessary at "acceptable" > framerates even necessary ? > > Why not go a different route with an iPhone client, and just have a > cut-down IM client that has a 3D background ? From secret.argent at gmail.com Tue Jun 10 04:27:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 04:25:50 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484E4CBF.5060203@signpostmarv.name> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E4CBF.5060203@signpostmarv.name> Message-ID: <6DB48EB5-E112-4838-A65F-FFA73A06A3C0@gmail.com> On 2008-06-10, at 04:43, SignpostMarv Martin wrote: > If a non-standard format is used, it'll only be useful in the short > term. An effectively non-standard format is all that's "protecting" the cache now, and it's been useful for some years. And there's no reason to standardize the local on-disk cache format, or for any third part software to use the same format. It's completely internal. From secret.argent at gmail.com Tue Jun 10 04:37:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 04:36:33 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484E5AAE.5030507@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> <484E5AAE.5030507@signpostmarv.name> Message-ID: <556FCFBD-F18E-4141-AF13-825BBD9DBA66@gmail.com> On 2008-06-10, at 05:42, SignpostMarv Martin wrote: > Clarification: VFS references, or LLSD list of assets UUIDs ? I don't think VFS should even be in the loop for textures. The texture cache would be simply /xx/yy/zz/xxyyzzaabbccddee... where xxyyzzaabbccddee is a UUID or a unique permutation of a UUID. > Problem 1) Sim gets renamed. Does the UUID stay the same ?\ Who cares? It's a cache. For a few minutes you'll have preloaded the wrong textures, *once*, before throwing them away. At worst you'll be no worse off than you are now. The situations you're describing are rare, and at worst simply cause some wasted local copies, once, or you'll throw away some cached data you might want to keep, once. In all these cases you're If it turns out that grid matters, then you add an additional level for the grid. It doesn't matter if it invalidates existing cache when you add the extra level, it's a cache. From teravus at gmail.com Tue Jun 10 04:39:05 2008 From: teravus at gmail.com (Teravus Ovares) Date: Tue Jun 10 04:39:06 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484E2D4B.2010407@gmail.com> References: <48473027.9090101@lindenlab.com> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> <484E2D4B.2010407@gmail.com> Message-ID: <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> *Tateru Nino* Interesting, because I have four fully patched WinXP systems that don't have the registry values at all. There's a discrepancy there, do you regularly apply registry hacks? Best Regards Teravus On 6/10/08, Tateru Nino wrote: > > I've just checked 3 WinXP systems (two with SP2 and one with SP3) and the > registry settings for wininet for HTTP/1.0 and HTTP/1.1 connections are set > to 0xa (10) on all of them. > That's HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet > Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. > > Teravus Ovares wrote: > >> Can anyone confirm that the client does not use a library that respects >> this 2 connection limitation? So far in testing, it appears that it does. >> When two threads get stuck, it fails to do anything else via http. >> We've tried to use HTTP CAPS for inventory, and consistently, when the >> inventory service runs slow, the client stops making *any* further http >> requests. >> Best Regards >> Teravus >> >> On 6/9/08, *Tateru Nino* > tateru.nino@gmail.com>> wrote: >> >> Actually it is not a mandate. A mandate would be a MUST NOT. This >> is a SHOULD NOT, specifically: >> "A single-user client SHOULD NOT maintain more than 2 connections >> with any server or proxy. A proxy SHOULD use up to 2*N connections >> to another server or proxy, where N is the number of >> simultaneously active users." >> >> I've got personal knowledge that the author did not intend the >> above to apply to situations like this. For the substrate to MSIE, >> however, it is entirely appropriate. Also, the above only applies >> to persistent connections, not non-persistent connections >> (applying the same guideline to non-persistent connections would >> cause problems that this guideline is intended to avoid). >> >> Just because you're doing HTTP, doesn't make you a part of the >> Web, and connection considerations in Web architecture over HTTP >> are different to other architectures over HTTP. >> >> >> >> >> >> Teravus Ovares wrote: >> >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the >> two-connection limit. The four-connection limit for HTTP 1.0 >> is a self-imposed restriction that coincides with the standard >> that is used by a number of popular Web browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/938f5e1e/attachment.htm From ravenglassrentals at yahoo.com Tue Jun 10 05:11:38 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Jun 10 05:11:42 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <20080610060041.C849741B41B@stupor.lindenlab.com> Message-ID: <827605.10646.qm@web55601.mail.re4.yahoo.com> Second Life is not a web browser. It is a world. It is a world with an economy based on intellectual property and real property rights. If you want a web browser, go outside to the Internet; if you want a world with people in it, and not merely a abstract platformist sandbox, you will have to accommodate the needs of non-scripters and non-coders who make up the business people supporting the costs of this platform and making a profit for the platform providers. The concept that right-clicking thereby enables stealing of proprietary images and codes everywhere else on the Internet is false, and a tendentious reading along the extremist Stallmanite lines. Any discussion of obfuscation should be reviewed on its merits, in good faith, both to determine whether it assists in the matter of copyright theft and preserving the integrity of the original permissions system, and also with a view to functionality and scaling. sldev-request@lists.secondlife.com wrote: Send SLDev mailing list submissions to sldev@lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request@lists.secondlife.com You can reach the person managing the list at sldev-owner@lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. Re: Shadow Patch? (Argent Stonecutter) 2. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Gordon Wendt) 3. Re: Shadow Patch? (Soft) 4. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Ann Otoole) 5. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Gordon Wendt) 6. Re: Cache politics: performance vs obfuscation (Michael Schlenker) ---------------------------------------------------------------------- Message: 1 Date: Mon, 9 Jun 2008 21:16:52 -0500 From: Argent Stonecutter Subject: Re: [sldev] Shadow Patch? To: Second Life Developer Mailing List Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > I believe it refers to http://www.massively.com/2008/05/29/high-end- > graphics-features-planned-for-second-life/ I don't think that will make it into RC10, or 1.21, or 1.22, ... ------------------------------ Message: 2 Date: Mon, 9 Jun 2008 22:16:55 -0400 From: "Gordon Wendt" Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: "Second Life Developer Mailing List" Message-ID: <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment-0001.htm ------------------------------ Message: 3 Date: Mon, 9 Jun 2008 21:22:42 -0500 From: Soft Subject: Re: [sldev] Shadow Patch? To: "Brandon Husbands" Cc: Second Life Developer Mailing List Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? That's a long-term feature. No. The intent of the RC branch is that subsequent RCs at a given version number contain bug fixes only. ------------------------------ Message: 4 Date: Mon, 9 Jun 2008 20:08:01 -0700 (PDT) From: Ann Otoole Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: Second Life Developer Mailing List Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Here is what some of the people on this list come across like: Let's say you have a town full of people worried about terrorists making home made bombs. Here comes a resident yelling obscenities at them, calling them stupid, yelling that there is nothing that can be done about it, and handing out flyers with instructions on how to make fertilizer bombs. Doesn't matter if it is right or wrong the behavior is antisocial and unacceptable. Thats the mentality I see going on. The professional nature of this list has vanished. I think LL needs to clean this list up and deal with it. The number of people causing problems is small and finite and I don't see much code or ideas coming from them. This list is an LL list and as such should fall under the TOS/CS and abusive behavior should be rewarded with suspensions from Secondlife and if it continues then the SL accounts be revoked. IMHO anyway. If obfuscation happens to be part of a new way to manage cache so more can be stored and the performance be improved then I'm all for it. However, the cache performance is what counts. The number of bytes being transferred is becoming critical. And may soon become very expensive. Can we return to finding ways to improve the cache now? ----- Original Message ---- From: Gordon Wendt To: Second Life Developer Mailing List Sent: Monday, June 9, 2008 10:16:55 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment-0001.htm ------------------------------ Message: 5 Date: Mon, 9 Jun 2008 23:22:32 -0400 From: "Gordon Wendt" Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: "Second Life Developer Mailing List" Message-ID: <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Apologies to Ann for the double post since gmail at least automatically wants to send it directly to whoever sent the original message to the list. If you would like to skip to my ontopic comments on this conversation please skip to the second paragraph. @Ann Ironically you just displayed the same behavior you said should be banned and I take great offense at you comparing people who disagree with you on the topic of obsfucating information to terrorists. Other than your post here attacking other resident's directly I don't see any personal attacks just attacks on each other's arguments which is the nature of such discourse when not everybody agrees. Incidentally it seems so far that LL knows that off topic conversations and arguments go on in the list and as long as the main conversation goes along and as long as they are quick and not overly disruptive these arguments seem to be overlooked... this is just from my experience so far and Rob and the other list admins take action as they see fit without much regard to precedent. On the topic of the issue though since this really is getting off topic I'm sure there is some middleground in terms of performance but it seems like high performance would require changing the fundamental way that images are sent, recieved, and dealt with by the server and client respectively although I'd be interested if LL or anyone else has data on where the slowest parts of the process are since I'm not sure we know for sure that encoding is where the bottleneck is although that is unfortunately the only part that can really be directly seen except by LL since we don't know what goes on serverside. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment-0001.htm ------------------------------ Message: 6 Date: Tue, 10 Jun 2008 08:00:48 +0200 From: Michael Schlenker Subject: Re: [sldev] Cache politics: performance vs obfuscation To: Argent Stonecutter Cc: Second Life Developer Mailing List Message-ID: <484E1890.1080604@uni-oldenburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Argent Stonecutter schrieb: > On 2008-06-09, at 02:22, Dale Mahalko wrote: >> A move to a local MySQL database > > God no. > > sqlite, please. Without all the MySQL "I'm pretending to be a real > database engine" overhead. SQLites pretty good for some stuff, but caching blob data is not one of it due to the required frequent fsync() calls needed to maintain transactions. (just see the current discussion around Firefox 3 being very slow on Ubuntu). But MySQL is an even worse idea... I had to write a heavily parallel (targeting some 1000 parallel writing threads) blob storage system for a different application and using SQLite, even only for storing the metadata leads to heavy lock contention and made the system far less scalable. Current filesystems like NTFS or ext3 are pretty okay for storing files and metadata, they are made for that kind of usecase..., its even faster to do a stat() on disk than to lookup stuff in sqlite in most cases. Michael ------------------------------ _______________________________________________ SLDev mailing list SLDev@lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 18, Issue 66 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/ba904ff2/attachment-0001.htm From q at lindenlab.com Tue Jun 10 06:07:40 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue Jun 10 06:07:46 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> On Jun 9, 2008, at 9:08 PM, Gordon Wendt wrote: > With all due respect if you have linden after your name (Q Linden in > this case) then you are going to be assumed to be speaking for LL > every time you post anywhere, is it fair? no but that's life on a > mailing list that the company you works for runs. Yes, sure. All I meant (and it was badly phrased, I admit) was that I'm not trying to say that what I think is what LL as a whole thinks or will do. I'm trying to have a conversation here, and I didn't want my evolving thinking to be perceived as any firm indication of what LL will necessarily do. I'm only one of many. Q From kwerks.sl at gmail.com Tue Jun 10 07:38:19 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 07:38:23 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <827605.10646.qm@web55601.mail.re4.yahoo.com> References: <20080610060041.C849741B41B@stupor.lindenlab.com> <827605.10646.qm@web55601.mail.re4.yahoo.com> Message-ID: <7b61e3970806100738p7b2f1dbcncf2d14bd06928fa7@mail.gmail.com> On Tue, Jun 10, 2008 at 8:11 AM, Random Unsung wrote: > Second Life is not a web browser. It is a world. It is a world with an > economy based on intellectual property and real property rights. If you want > a web browser, go outside to the Internet; if you want a world with people > in it, and not merely a abstract platformist sandbox, you will have to > accommodate the needs of non-scripters and non-coders who make up the > business people supporting the costs of this platform and making a profit > for the platform providers. > > The concept that right-clicking thereby enables stealing of proprietary > images and codes everywhere else on the Internet is false, and a tendentious > reading along the extremist Stallmanite lines. > > Any discussion of obfuscation should be reviewed on its merits, in good > faith, both to determine whether it assists in the matter of copyright theft > and preserving the integrity of the original permissions system, and also > with a view to functionality and scaling. > > *sldev-request@lists.secondlife.com* wrote: > > Send SLDev mailing list submissions to > sldev@lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > or, via email, send a message with subject or body 'help' to > sldev-request@lists.secondlife.com > > You can reach the person managing the list at > sldev-owner@lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SLDev digest..." > > > Today's Topics: > > 1. Re: Shadow Patch? (Argent Stonecutter) > 2. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Gordon Wendt) > 3. Re: Shadow Patch? (Soft) > 4. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Ann Otoole) > 5. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Gordon Wendt) > 6. Re: Cache politics: performance vs obfuscation (Michael Schlenker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Jun 2008 21:16:52 -0500 > From: Argent Stonecutter > Subject: Re: [sldev] Shadow Patch? > To: Second Life Developer Mailing List > Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > > I believe it refers to http://www.massively.com/2008/05/29/high-end- > > graphics-features-planned-for-second-life/ > > I don't think that will make it into RC10, or 1.21, or 1.22, ... > > > > > ------------------------------ > > Message: 2 > Date: Mon, 9 Jun 2008 22:16:55 -0400 > From: "Gordon Wendt" > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: "Second Life Developer Mailing List" > Message-ID: > <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Irrational statements like what I keep seeing on this list are exactly why > an idiotic proposal like SVC-1919 was passed to remove UUID information > from > the viewer, just because things like showing a texture UUID in the GUI can > be used for nefarious purposes wasn't and isn't a reason to cripple the > client, doubly so when it can be easily undone. That's why there are no > copies of Mozilla Firefox (an open source web browser for those who don't > know) without right shift save image functionality or without the option to > view web page source. You don't see people whining and moaning about their > web page source being publicly available yet people want SL to be crippled > in the same way they'd want a web browser to be crippled. > > -G.W. > > On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > > > > Eh, the middle way is best, I think. > > > > Don't support things against the TOS via the SL viewer GUI, at the very > > least. Beyond that, minor obfuscation that requires a potential thief to > > have more technical understanding of what is going on than merely > accessing > > things via the standard MacOS/WIndows file GUI should be sufficient to > offer > > legal protection to content creators. Any protection BEOND that, will > > require more work on the content creator. A 3rd party solution to grab > > textures as they are uploaded and run them through signature/watermarking > > before forwarding them to LL, might be an option. No doubt there are > others, > > but for content creators, even slight obfuscation should offer legal > > protection. No obfuscation whatsoever, might not. > > > > In my non-legal view, of course. > > > > > > Lawson > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Mon, 9 Jun 2008 21:22:42 -0500 > From: Soft > Subject: Re: [sldev] Shadow Patch? > To: "Brandon Husbands" > Cc: Second Life Developer Mailing List > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > > > Is this going to make it into rc10? > > That's a long-term feature. No. > > The intent of the RC branch is that subsequent RCs at a given version > number contain bug fixes only. > > > ------------------------------ > > Message: 4 > Date: Mon, 9 Jun 2008 20:08:01 -0700 (PDT) > From: Ann Otoole > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: Second Life Developer Mailing List > Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Here is what some of the people on this list come across like: > > Let's say you have a town full of people worried about terrorists making > home made bombs. > Here comes a resident yelling obscenities at them, calling them stupid, > yelling that there is nothing that can be done about it, and handing out > flyers with instructions on how to make fertilizer bombs. > Doesn't matter if it is right or wrong the behavior is antisocial and > unacceptable. > > Thats the mentality I see going on. The professional nature of this list > has vanished. I think LL needs to clean this list up and deal with it. > The number of people causing problems is small and finite and I don't see > much code or ideas coming from them. > > This list is an LL list and as such should fall under the TOS/CS and > abusive behavior should be rewarded with suspensions from Secondlife and if > it continues then the SL accounts be revoked. > IMHO anyway. > > If obfuscation happens to be part of a new way to manage cache so more can > be stored and the performance be improved then I'm all for it. > However, the cache performance is what counts. > The number of bytes being transferred is becoming critical. > And may soon become very expensive. > > Can we return to finding ways to improve the cache now? > > > ----- Original Message ---- > From: Gordon Wendt > To: Second Life Developer Mailing List > Sent: Monday, June 9, 2008 10:16:55 PM > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > > Irrational statements like what I keep seeing on this list are exactly why > an idiotic proposal like SVC-1919 was passed to remove UUID information from > the viewer, just because things like showing a texture UUID in the GUI can > be used for nefarious purposes wasn't and isn't a reason to cripple the > client, doubly so when it can be easily undone. That's why there are no > copies of Mozilla Firefox (an open source web browser for those who don't > know) without right shift save image functionality or without the option to > view web page source. You don't see people whining and moaning about their > web page source being publicly available yet people want SL to be crippled > in the same way they'd want a web browser to be crippled. > > -G.W. > > > On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > > > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment-0001.htm > > ------------------------------ > > Message: 5 > Date: Mon, 9 Jun 2008 23:22:32 -0400 > From: "Gordon Wendt" > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: "Second Life Developer Mailing List" > Message-ID: > <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Apologies to Ann for the double post since gmail at least automatically > wants to send it directly to whoever sent the original message to the list. > > > If you would like to skip to my ontopic comments on this conversation > please > skip to the second paragraph. > > @Ann Ironically you just displayed the same behavior you said should be > banned and I take great offense at you comparing people who disagree with > you on the topic of obsfucating information to terrorists. Other than your > post here attacking other resident's directly I don't see any personal > attacks just attacks on each other's arguments which is the nature of such > discourse when not everybody agrees. Incidentally it seems so far that LL > knows that off topic conversations and arguments go on in the list and as > long as the main conversation goes along and as long as they are quick and > not overly disruptive these arguments seem to be overlooked... this is just > from my experience so far and Rob and the other list admins take action as > they see fit without much regard to precedent. > > On the topic of the issue though since this really is getting off topic I'm > sure there is some middleground in terms of performance but it seems like > high performance would require changing the fundamental way that images are > sent, recieved, and dealt with by the server and client respectively > although I'd be interested if LL or anyone else has data on where the > slowest parts of the process are since I'm not sure we know for sure that > encoding is where the bottleneck is although that is unfortunately the only > part that can really be directly seen except by LL since we don't know what > goes on serverside. > > -G.W. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment-0001.htm > > ------------------------------ > > Message: 6 > Date: Tue, 10 Jun 2008 08:00:48 +0200 > From: Michael Schlenker > Subject: Re: [sldev] Cache politics: performance vs obfuscation > To: Argent Stonecutter > Cc: Second Life Developer Mailing List > Message-ID: <484E1890.1080604@uni-oldenburg.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Argent Stonecutter schrieb: > > On 2008-06-09, at 02:22, Dale Mahalko wrote: > >> A move to a local MySQL database > > > > God no. > > > > sqlite, please. Without all the MySQL "I'm pretending to be a real > > database engine" overhead. > > SQLites pretty good for some stuff, but caching blob data is not one of > it due to the required frequent fsync() calls needed to maintain > transactions. (just see the current discussion around Firefox 3 being > very slow on Ubuntu). > > But MySQL is an even worse idea... > > I had to write a heavily parallel (targeting some 1000 parallel writing > threads) blob storage system for a different application and using > SQLite, even only for storing the metadata leads to heavy lock > contention and made the system far less scalable. Current filesystems > like NTFS or ext3 are pretty okay for storing files and metadata, they > are made for that kind of usecase..., its even faster to do a stat() on > disk than to lookup stuff in sqlite in most cases. > > Michael > > > > > ------------------------------ > > _______________________________________________ > SLDev mailing list > SLDev@lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > End of SLDev Digest, Vol 18, Issue 66 > ************************************* > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/3caa0ca8/attachment-0001.htm From xotmid at gmail.com Tue Jun 10 07:51:59 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Tue Jun 10 07:52:01 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484E500C.4060400@signpostmarv.name> References: <484E3DA4.7020801@cox.net> <484E500C.4060400@signpostmarv.name> Message-ID: I installed it and it was really nice looking... Made second life look rocking... The down side everyones FAKE Shadows... made it look wierd. I know it was not optimized but it still ran good.. Would love to see it as an option w/o having to dl a 3rd party patch. On Tue, Jun 10, 2008 at 4:57 AM, SignpostMarv Martin wrote: > Since the Shadow branch is restricted to GeForce 8 GPUs only, it would make > more sense to release it as a First Look viewer, not an RC. > > ~ Marv. > > Lawson English wrote: > >> Soft wrote: >> >>> On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands >>> wrote: >>> >>> >>>> Is this going to make it into rc10? >>>> >>> That's a long-term feature. No. >>> >>> The intent of the RC branch is that subsequent RCs at a given version >>> number contain bug fixes only. >>> _______________________________________________ >>> >>> >> Intent yes, reality? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/362ed1ee/attachment.htm From kwerks.sl at gmail.com Tue Jun 10 08:12:30 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 08:12:34 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <827605.10646.qm@web55601.mail.re4.yahoo.com> References: <20080610060041.C849741B41B@stupor.lindenlab.com> <827605.10646.qm@web55601.mail.re4.yahoo.com> Message-ID: <7b61e3970806100812r460753c4gee46c3ef71e73354@mail.gmail.com> SL is certainly not a web browser, or more precisely, should not be approached with that metaphor, I agree. As to digital IP, to a lawyer the notion of copyright, be it a digital asset or an equity asset is the same thing. To a programmer a digital asset is most certainly not the same thing as an entry in a ledger. Computers do two things and that is all they do; they they copy information and they make mathematical calculations based on those copies. That is all they do in the end and they do those things very well and they must do both of them to be useful. The gap in the dialog of IP regarding computers will never be bridged I think becuase lawyers seek to make copying difficult or impossible and the only way to do that is to curtail, even cripple somehow the computers ablity to copy and thus take away the one of the intrinsic things that makes computers useful. It just can't happen. The programmer will always simply see the thing as a "right-click away" because, well, it is. I think a far better way to approach the problem of digital IP to is quit trying to apply a legal model that does not fit. Realize that computers make things inifinitly copiable becuase they need to and therefore the path is to find ways to bend legal concepts to fit that reality rather then trying to bend the computer to fit existing legal concepts. I think, in this case, it's the lawyers that need to be flexible and creative, not the programmers per se. As a professional musician I have a very personal and economic interest in digital IP. Every time I see one of my discs on someones iPod or hear it in a bar, I wonder where that money went. However, as a professional programmer I realize the approach taken by the RIAA, for example, and others is completely futile. I believe what is needed to bridge this gap and address the issue properly is a different legal model and discourse and metaphor, and to quit talking so much about different programming model and metaphor. Just my 2 cents. Apologies for my last empty post. Mouse mis-cue. JB On Tue, Jun 10, 2008 at 8:11 AM, Random Unsung wrote: > Second Life is not a web browser. It is a world. It is a world with an > economy based on intellectual property and real property rights. If you want > a web browser, go outside to the Internet; if you want a world with people > in it, and not merely a abstract platformist sandbox, you will have to > accommodate the needs of non-scripters and non-coders who make up the > business people supporting the costs of this platform and making a profit > for the platform providers. > > The concept that right-clicking thereby enables stealing of proprietary > images and codes everywhere else on the Internet is false, and a tendentious > reading along the extremist Stallmanite lines. > > Any discussion of obfuscation should be reviewed on its merits, in good > faith, both to determine whether it assists in the matter of copyright theft > and preserving the integrity of the original permissions system, and also > with a view to functionality and scaling. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/a44b765c/attachment.htm From cenji.neutra at gmail.com Tue Jun 10 08:48:08 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 08:48:11 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal Message-ID: Open Grid Identifier Notation - Proposal draft 1 As part of some internal software development, we've had a need for a generic identification scheme for 'grids' and their major components. Rather than invent something behind closed-doors with high probability that something similar will be needed and re-invented by the VW community in the near future, we decided to come up with a proposal for open discussion. The 'grid identifier' notation proposed is fairly simple and takes into consideration the work of the AWG, the SLGOGP draft and 'current practice'. http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec In short, we're proposing using a domain-name-like system for identifiers, but with the components reversed so as not to have them confused with DNS domain names. For example, "com.secondlife.agni" could be the identifier for the SL main grid. There are also specific identifier types for VW components, such as SLGOGP's "agent domains" and "region domains". The proposal doesn't dictate how identifiers might be used or how/where they're managed. It would be up to other parties to build lookup, discovery and other services utilizing them (which can be the subject of future independent proposals). Feedback and criticism welcomed and appreciated. -Cenji Neutra Apez Corp (http://www.apez.biz ) From tateru.nino at gmail.com Tue Jun 10 08:50:14 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 08:51:02 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> <484E2D4B.2010407@gmail.com> <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> Message-ID: <484EA2B6.5010505@gmail.com> Me? pretty much never. Something must have set those values, but I couldn't tell you what it was. Teravus Ovares wrote: > *Tateru Nino* > > Interesting, because I have four fully patched WinXP systems that > don't have the registry values at all. There's a discrepancy there, > do you regularly apply registry hacks? > > Best Regards > > Teravus > > > On 6/10/08, *Tateru Nino* > wrote: > > I've just checked 3 WinXP systems (two with SP2 and one with SP3) > and the registry settings for wininet for HTTP/1.0 and HTTP/1.1 > connections are set to 0xa (10) on all of them. > That's > HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet > Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. > > Teravus Ovares wrote: > > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it > appears that it does. When two threads get stuck, it fails > to do anything else via http. We've tried to use HTTP CAPS > for inventory, and consistently, when the inventory service > runs slow, the client stops making *any* further http requests. > Best Regards > Teravus > > On 6/9/08, *Tateru Nino* >> wrote: > > Actually it is not a mandate. A mandate would be a MUST > NOT. This > is a SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 > connections > with any server or proxy. A proxy SHOULD use up to 2*N > connections > to another server or proxy, where N is the number of > simultaneously active users." > > I've got personal knowledge that the author did not intend the > above to apply to situations like this. For the substrate > to MSIE, > however, it is entirely appropriate. Also, the above only > applies > to persistent connections, not non-persistent connections > (applying the same guideline to non-persistent connections > would > cause problems that this guideline is intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the > Web, and connection considerations in Web architecture over > HTTP > are different to other architectures over HTTP. > > > > > > Teravus Ovares wrote: > > I also note, that according to Microsoft's kb article: > "The HTTP 1.1 specification (RFC2616) mandates the > two-connection limit. The four-connection limit for > HTTP 1.0 > is a self-imposed restriction that coincides with the > standard > that is used by a number of popular Web browsers." > You can read the article here: > http://support.microsoft.com/kb/183110 > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > Best Regards > Teravus > > > From me at signpostmarv.name Tue Jun 10 08:55:06 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 08:55:10 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <484EA3DA.6020202@signpostmarv.name> See http://signpsotmarv.blip.tv/file/979660/ and http://signpostmarv.blip.tv/file/979736 - both made with the viewer Brandon linked. Visit my office in Hippotropolis to view the build used in the videos :-P ~ Marv. Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d30fe81b/smime-0001.bin From gigstaggart at gmail.com Tue Jun 10 09:04:26 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 10 09:04:29 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <484EA60A.4050909@gmail.com> Cenji Neutra wrote: > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to have them > confused with DNS domain names. For example, "com.secondlife.agni" > could be the identifier for the SL main grid. There are also specific > identifier types for VW components, such as SLGOGP's "agent domains" > and "region domains". Why? What's the point in reversing them? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cbe8a6dc/smime.bin From kwerks.sl at gmail.com Tue Jun 10 09:12:29 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 09:12:33 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> Excellent notion. Is this discussion to take place here or elsewhere? Apologies if this is out of place here but... Has the notion of a prefix or transport been discussed rather then a name reversal? Is is not clear to me the benefit of the name reversal. Given the convention of the prefix 'www' indicating the world wide web, and in the spirit of that naming convention attempting to look forward to other network notions, has a prefix of 'grid' or 'mv' (metaverse) or something like that been considered? 'grid.angi.secondlife.com' or 'mv.agni.secondlife.com' or even more simply the transport mechanism? 'grid://agni.secondlife.com' or 'mv://agni.secondlife.com' It seems to me that the current push to utilize HTTP for services, the plethora of software that understands this domain ordering and the ability to capitalize on existing DNS services would make this much easier then re-writing those things to accomodate this convention. Please let me know if this is out of place here and where previous discussion might be reviewed and future discourse might be taken up. regards JB On Tue, Jun 10, 2008 at 11:48 AM, Cenji Neutra wrote: > Open Grid Identifier Notation - Proposal draft 1 > > As part of some internal software development, we've had a need for a > generic identification scheme for 'grids' and their major components. > Rather than invent something behind closed-doors with high probability > that something similar will be needed and re-invented by the VW > community in the near future, we decided to come up with a proposal > for open discussion. > The 'grid identifier' notation proposed is fairly simple and takes > into consideration the work of the AWG, the SLGOGP draft and 'current > practice'. > > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to have them > confused with DNS domain names. For example, "com.secondlife.agni" > could be the identifier for the SL main grid. There are also specific > identifier types for VW components, such as SLGOGP's "agent domains" > and "region domains". > > The proposal doesn't dictate how identifiers might be used or > how/where they're managed. It would be up to other parties to build > lookup, discovery and other services utilizing them (which can be the > subject of future independent proposals). > > Feedback and criticism welcomed and appreciated. > > -Cenji Neutra > > Apez Corp (http://www.apez.biz ) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/ba93a07e/attachment.htm From kfa at gmx.net Tue Jun 10 09:20:30 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 09:20:40 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA60A.4050909@gmail.com> References: <484EA60A.4050909@gmail.com> Message-ID: <484EA9CE.9070901@gmx.net> Jason Giglio wrote: > Cenji Neutra wrote: >> http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec >> >> In short, we're proposing using a domain-name-like system for >> identifiers, but with the components reversed so as not to have them >> confused with DNS domain names. For example, "com.secondlife.agni" >> could be the identifier for the SL main grid. There are also specific >> identifier types for VW components, such as SLGOGP's "agent domains" >> and "region domains". > > Why? What's the point in reversing them? > > Java does it the same way. The point is that it creates a top-down ordered folder structure. From kwerks.sl at gmail.com Tue Jun 10 09:34:18 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 09:34:19 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA9CE.9070901@gmx.net> References: <484EA60A.4050909@gmail.com> <484EA9CE.9070901@gmx.net> Message-ID: <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> Hmm, please forgive my thickness, but how does java's convention of organizing name space and a folder structure for source code apply to the existing convention of network discovery and DNS? Solid tools are already out there to utilize the other approach for this exact application. JB On Tue, Jun 10, 2008 at 12:20 PM, Felix Duesenburg wrote: > Jason Giglio wrote: > >> Cenji Neutra wrote: >> >>> http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec >>> >>> In short, we're proposing using a domain-name-like system for >>> identifiers, but with the components reversed so as not to have them >>> confused with DNS domain names. For example, "com.secondlife.agni" >>> could be the identifier for the SL main grid. There are also specific >>> identifier types for VW components, such as SLGOGP's "agent domains" >>> and "region domains". >>> >> >> Why? What's the point in reversing them? >> >> >> > Java does it the same way. The point is that it creates a top-down ordered > folder structure. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/24bf867a/attachment.htm From jhurliman at jhurliman.org Tue Jun 10 09:35:30 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jun 10 09:35:36 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: On Tue, Jun 10, 2008 at 12:46 AM, Argent Stonecutter < secret.argent@gmail.com> wrote: > On 2008-06-10, at 01:34, Jason Giglio wrote: > >> Argent Stonecutter wrote: >> >>> The corollary of (a) is "eliminate a huge portion of the SL economy, >>> and possibly go out of business". >>> >> >> > Yes, because the entire economy collapsed the day after copybot came out. >> > > Don't be silly. If copybot had not been broken, incomplete, and horribly > inconvenient, if it been built into the standard client, with right click > "show source" and "save as" that worked like "show source" and "save as" in > a browser (because that IS what "treat it like the web" implies) in a > browser and let you trivially grab all prims and assets in a convenient form > for uploading as your own product, then... yes... it likely would have. > > Then why hasn't primpreview killed the SL economy? http://www.youtube.com/watch?v=LfMNygcceAs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cf6d12a9/attachment-0001.htm From vexstreeter at gmail.com Tue Jun 10 09:37:05 2008 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue Jun 10 09:37:10 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <484EADB1.1050105@gmail.com> Cenji Neutra wrote: > Open Grid Identifier Notation - Proposal draft 1 > > As part of some internal software development, we've had a need for a > generic identification scheme for 'grids' and their major components. > I think you need to explain why a novel naming syntax is required. For instance, I'd think that a URI would be a better start, perhaps drawing on XML namespace URLs pointing to RDDL or some such, or a URN with types called out as components. From cenji.neutra at gmail.com Tue Jun 10 09:40:59 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 09:41:01 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> References: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> Message-ID: On Tue, Jun 10, 2008 at 12:04 PM, Jason Giglio wrote: >> confused with DNS domain names. For example, "com.secondlife.agni" >> could be the identifier for the SL main grid. > Why? What's the point in reversing them? The idea was to avoid confusion with domain names. On Tue, Jun 10, 2008 at 12:12 PM, JB Kraft wrote: > Excellent notion. Is this discussion to take place here or elsewhere? I guess it is related to SL development. There is also a Discussion/Talk page were comments can be posted. > Has the notion of a prefix or transport been discussed rather then a name > reversal? Is is not clear to me the benefit of the name reversal. No, it hasn't. This is the kind of feedback we were after :) > Given the convention of the prefix 'www' indicating the world wide web, and > in the spirit of that naming convention attempting to look forward to other > network notions, has a prefix of 'grid' or 'mv' (metaverse) or something > like that been considered? > > 'grid.angi.secondlife.com' or 'mv.agni.secondlife.com' > > or even more simply the transport mechanism? > > 'grid://agni.secondlife.com' or 'mv://agni.secondlife.com' > > It seems to me that the current push to utilize HTTP for services, the > plethora of software that understands this domain ordering and the ability > to capitalize on existing DNS services would make this much easier then > re-writing those things to accomodate this convention. The intention was to keep the abstract identifiers independent from any service end-points or resource locators. While a scheme like that may be useful as a standard way to connect to a service implementing a known interface, we're after a more abstract way to refer to them without any implication as to where the service might be located or what APIs it might support. Obviously, there is a need for a way to get to a service end-point from an identifier, but we don't want to dictate that at this stage. To give an example of how you might achieve something like that. Consider a hypothetical standard that specifies how an identifier can be used to obtain a service end-point in the following way: - map the identifier to a DNS host name by reversing the components and then appending a standard 'root' domain, such as virtualworld.id, for example to yield "agni.secondlife.com.virtualworld.id". - perform a DNS lookup on that domain for the SRV record - perhaps the SVC record can provide an SLGOGP login URL directly for an agent domain, or perhaps the host is identifies is required to support a simple rest GET request that returns some standard piece of XML that includes information such as login URLs and the like. Just one possibility of many and something that is outside of the scope of just specifying an identifier notation. -Cenji. From me at signpostmarv.name Tue Jun 10 10:06:10 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 10:06:13 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <484EB482.2050407@signpostmarv.name> John Hurliman wrote: > Then why hasn't primpreview killed the SL economy? > http://www.youtube.com/watch?v=LfMNygcceAs ^this is the kind of interface I was referring to for the iPhone. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/aecd76e7/smime.bin From waseemzhr at gmail.com Tue Jun 10 10:31:27 2008 From: waseemzhr at gmail.com (Waseem Azhar) Date: Tue Jun 10 10:31:29 2008 Subject: [sldev] Login SL Using Java Client Message-ID: Hi, I am writing java SL client. Currently I am stuck with login-to-simulator case. Using xml-rpc I am able to get authenticated with xml response from server. But when I send UseCircuitCode packet to simulator on UDP connection, I get no response from the Simulator. Can anyone help ? Thanks, -Azhar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/e31893e7/attachment.htm From kfa at gmx.net Tue Jun 10 07:04:25 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 10:52:31 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> Message-ID: <484E89E9.8060805@gmx.net> Kent Quirk (Q Linden) wrote: > > On Jun 9, 2008, at 9:08 PM, Gordon Wendt wrote: > >> With all due respect if you have linden after your name (Q Linden in >> this case) then you are going to be assumed to be speaking for LL >> every time you post anywhere, is it fair? no but that's life on a >> mailing list that the company you works for runs. > > Yes, sure. All I meant (and it was badly phrased, I admit) was that I'm > not trying to say that what I think is what LL as a whole thinks or will > do. I'm trying to have a conversation here, and I didn't want my > evolving thinking to be perceived as any firm indication of what LL will > necessarily do. I'm only one of many. > > Q > With all due respect as well, I do NOT think that the assumption Gordon expressed is a fair one, no matter how many would like to beat into the same kerf. Quite often things would be easier if we stopped assuming or trying to second-guess our counterparts and just took their words as they are. If there is a need to clarify, one can always ask back whether there's a person speaking or the company. We should be grateful that Lindens are engaging in discussion here, participate in developing ideas, and feel free to speak off the top of their heads just like everybody else. This shows they're not sitting in an ivory tower like so many others who seemingly can only communicate in carefully crafted legalese statements, always scared shitless the whole company could be pinned down for something they casually said. Cheers, Felix From ravenglassrentals at yahoo.com Tue Jun 10 10:58:31 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Jun 10 10:58:33 2008 Subject: [sldev] Re: "It's Just Not Possible" In-Reply-To: <20080610155510.66D1F41B34A@stupor.lindenlab.com> Message-ID: <425146.67076.qm@web55605.mail.re4.yahoo.com> JB, I'm glad you concede that SL is not a mere web browser, but your other statement about IP and lawyers is merely one ideological take, one common to programmers, and not even one all programmers, especially moderates, agree on. Number one, just because you can break into a house or steal the silver from the knife drawer technically doesn't mean this is morally and legally allowed. It isn't. And it's this decoupling of coders from the moral and legal suasion of real life that makes them continually morally and legally suspect. Locksmiths, architects, and doormen don't constantly inform their customers that their work is all hackable and pointless; they work to close the gaps. Software programmers should restore their accountability in the spirit of those real life professions. I don't think you can call yourself scientific, as in the science of computing, by claiming something "can never be done". By that logic, you would never stream a virtual world in 3-D across 20,000 servers because "it can't be done". Most people do not say their theft of a silver spoon in someone else's drawer is legitimate merely because it is always a drawer-pull away, because, well it is. Civilization is based on such scruples. I would urge you to restore them to your own field. The RIAA is not futile. It's not perfect; perhaps it is not the final say. But it works to secure many people's IP, despite the constant claims that it is futile by such as yourself. The existing legal and moral structures of thousands of years are perfectly adequate in their bare essentials to address the issue of creativity and theft and property. It is only in modern times that the progress was made in fact to establish property rights in the face of the tribe, the leader, the king. No need to go backwards to pre-Enlightenment eras just because we're on the Internet. No one who has a stake in SL can be directed to "quit talking about programming metaphors". The making of metaphors, and indeed the entire debate about programming the world of Second Life, is not the solve provence of coders. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/df0db000/attachment.htm From kfa at gmx.net Tue Jun 10 10:58:47 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 10:58:55 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> References: <484EA60A.4050909@gmail.com> <484EA9CE.9070901@gmx.net> <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> Message-ID: <484EC0D7.9060904@gmx.net> Hm, I'm not sure how this relates to our topic, I'm lacking some specific knowledge in that field. I took the question for "why on earth are the domain parts reversed there" which keeps popping up in Java related forums or lists. Maybe I misunderstood it, then please just scratch it. JB Kraft wrote: > Hmm, please forgive my thickness, but how does java's convention of > organizing name space and a folder structure for source code apply to > the existing convention of network discovery and DNS? Solid tools are > already out there to utilize the other approach for this exact application. > > JB > > On Tue, Jun 10, 2008 at 12:20 PM, Felix Duesenburg > wrote: > > Jason Giglio wrote: > > Cenji Neutra wrote: > > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to > have them > confused with DNS domain names. For example, > "com.secondlife.agni" > could be the identifier for the SL main grid. There are > also specific > identifier types for VW components, such as SLGOGP's "agent > domains" > and "region domains". > > > Why? What's the point in reversing them? > > > > Java does it the same way. The point is that it creates a top-down > ordered folder structure. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From kwerks.sl at gmail.com Tue Jun 10 11:05:04 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 11:05:06 2008 Subject: [sldev] Re: "It's Just Not Possible" In-Reply-To: <425146.67076.qm@web55605.mail.re4.yahoo.com> References: <20080610155510.66D1F41B34A@stupor.lindenlab.com> <425146.67076.qm@web55605.mail.re4.yahoo.com> Message-ID: <7b61e3970806101105t455a21acv9c5ad7a0a5d4c0ee@mail.gmail.com> Thank you for responding. As I mentioned, this particular issue is a personal one for me as, as a musician, I am directly affected financially by the problem. My other hat, as a programmer, does leave me with somewhat of a paradox in this regard however, as I can see behind the curtain. To the resolution of that, I very much appreciate other views and would like to state, for the record, that my scruples are most certainly intact. I very much endeavour to protect the artist in every way as I feel the dimishing of the value of art directly, as we all do. My stance to date indeed is an ideological one, but I think that is where the solutions lie frankly. Perhaps I am not eloquent enough to put that properly forth. As a programmer, I do see the moving of bits around as essential and essentially the same thing, be that 20,000 machines and a 3D world or a Commodore-64 pulling data off a tape drive and poking it into ram. The difference is simply scale. I see the browser, and SL for that matter, simply as a fancy dumb terminal, a VT-100, that some server sends data to to render, whether that data lands on the screen as green globby text or windlight is semantic to me. The difficulty is to see that data as something that belongs to someone, though indeed it does, and how to protect that. Frankly I am not sure you can given the way computers work without making them not work or not work well. To use your example, the data is simply not the same thing as the spoon in a drawer and therefore needs to be dealt with differently from an ideological perspective and not only from a programmers perspective. The forging of a silver spoon takes a great deal of human effort, the copying of an image or song takes none. Should the protection of theft of those things not be approached differently? I don't know, but at this point, I think they should. Perhaps I don't spend enough time in the company of lawyers to speak to what discussions land on their lists but from where I do sit, I hear very little coming from them on ways to approach the problem differently. The lawyers I do hear from, from my record company for instance, are all trying to talk about ways to apply the conventional model of the spoon to the very different problem of the mp3 and I suppose I am just trying to put forth that we may find even better ways to address the problem if we try to come at it from that ideological direction as well. Making the programmer the locksmith fits the spoon metaphor, but I propose that we at least entertain the notion that a digital asset may not actually be the metaphorical spoon. Mp3's may be something that the makers of laws and copyrights did not even conceive of or account for when they built the model and it is the model too, that needs adjusting. I apologize to the list if this particular discussion is somewhat too philosophical and out of bounds to its purpose but I feel strongly about it as both a programmer and a musician and think it bears the consideration of other approaches from both the the litigators asking the programmer to be locksmiths and the programmers somewhat naively seeing information as something that "wants to be free". Knowledge may want to be free but I'd rather you gave me a few cents for my information/music somehow. :) best regards JB On Tue, Jun 10, 2008 at 1:58 PM, Random Unsung wrote: > JB, I'm glad you concede that SL is not a mere web browser, but your other > statement about IP and lawyers is merely one ideological take, one common to > programmers, and not even one all programmers, especially moderates, agree > on. > > Number one, just because you can break into a house or steal the silver > from the knife drawer technically doesn't mean this is morally and legally > allowed. It isn't. And it's this decoupling of coders from the moral and > legal suasion of real life that makes them continually morally and legally > suspect. Locksmiths, architects, and doormen don't constantly inform their > customers that their work is all hackable and pointless; they work to close > the gaps. Software programmers should restore their accountability in the > spirit of those real life professions. > > I don't think you can call yourself scientific, as in the science of > computing, by claiming something "can never be done". By that logic, you > would never stream a virtual world in 3-D across 20,000 servers because "it > can't be done". > > Most people do not say their theft of a silver spoon in someone else's > drawer is legitimate merely because it is always a drawer-pull away, > because, well it is. Civilization is based on such scruples. I would urge > you to restore them to your own field. > > The RIAA is not futile. It's not perfect; perhaps it is not the final say. > But it works to secure many people's IP, despite the constant claims that it > is futile by such as yourself. > > The existing legal and moral structures of thousands of years are perfectly > adequate in their bare essentials to address the issue of creativity and > theft and property. It is only in modern times that the progress was made in > fact to establish property rights in the face of the tribe, the leader, the > king. No need to go backwards to pre-Enlightenment eras just because we're > on the Internet. > > No one who has a stake in SL can be directed to "quit talking about > programming metaphors". The making of metaphors, and indeed the entire > debate about programming the world of Second Life, is not the solve provence > of coders. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/0c3cdf42/attachment.htm From kerdezixe at gmail.com Tue Jun 10 11:14:00 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:14:03 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> 2008/6/9 Jason Giglio : > > Who cares? A small utility anyone can write in a few hours can do this > today. > *NOT* anyone, just "any coder willing to spend some time on it". Writing a software to decode the current cache isn't that much complex than decoding a XOR'd texture cache. A lot of software protection can be unlocked replacing a JNZ with a JNC instruction, extremly simple, but most people simply can't do that. But the question is : does the current obfuscation have any impact on cache performance ? As far as i remember, we agreed that the current cache have a very little impact on performance and most of the cpu time is spent in decoding j2c. The current cache is working, have a very little perfomance impact, and provide enough protection against script-kiddies. The probleme is in the jpeg2000 decoding performance. -- F4FQM Kerunix Flan Laurent Laborde From kerdezixe at gmail.com Tue Jun 10 11:31:04 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:31:07 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484E5AAE.5030507@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> <484E5AAE.5030507@signpostmarv.name> Message-ID: <8a1bfe660806101131h6c18cf1hf338a00ff4b2f4a1@mail.gmail.com> 2008/6/10 SignpostMarv Martin : > > Problem 1) Sim gets renamed. Does the UUID stay the same ? Use case: > metaverse development company X gets hired to develop a sim for company Y. > company X owns the sim while the work is being done (with an inconspicuous > name so as to avoid PR issues), company X then transfers ownership of sim to > company Y. Company Y has name of sim changed. No assets within the sim are > changed. > > Problem 2) beta grid vs main grid (and LL's SL vs OpenSim). Use case: aside > from visitors, region A is identical on both grids. region B has a few > differences (one or two buildings weren't yet erected at the time the beta > grid snapshot was made). region C is completely different- few if none > identical assets. > > Problem 3) region being withdrawn. Use case: short term events, like Burning > Life/ SL Birthday it's not really imporatnt. If the sim name, or sim uuid, change. The current cache will probably be useless and/or discarded and all texture downloaded again. So what ? Sim name rarelly change. it *may* happen and the textures will be downloaded again. End of problem. People clear their cache when any single problem occurs. - i lost an item : clear your cache - i lag : clear your cache - my returned object was lost : clear your cache - what's the meaning of life, anyway ? clear your cache - hippo ? clear cache ! - i can't login : clear your cache - i cleared my cache and i still have problems : clear it again the texture cache lifespan(is it the right english word ?) is so short that this kind of situation can be safely ignored, imho. Also, when a sim change name, that's probably because of ownership transfert, and the sim content is wiped anyway, so it's a good thing to discard the textures entries. -- F4FQM Kerunix Flan Laurent Laborde From dahliatrimble at gmail.com Tue Jun 10 11:34:49 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 11:35:12 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> Message-ID: If I wear my "as a user" hat, I'm not sure a small increase in cache performance is going to sway my opinion of the software. If, wearing my "content creator" hat , I see that there are no obstacles to anyone getting full permission access to my content, I'll probably assume that there is no benefit to me to spend a lot of time developing quality content. Sure, I can right click on an image in a web browser and save it, but if I were browsing a stock photo site I would only be able to save a watermarked thumbnail, and I wouldnt get the nice high resolution image until I agreed to the TOS and paid them, so the internet browser analogy doesn't hold water in that case. Further, noone is going to be inducted into the programmer hall of fame for writing a binary file to a disk. If you want to do something that is a benefit to the community, develop a method that improves cache performance, saves network bandwidth, and doesnt alienate a large portion of the user base. If you want to make a cache browser/exporter, then call it that. I see no reason that a standardized image format would necessarily be the highest performance choice for a cache. On Tue, Jun 10, 2008 at 11:14 AM, Laurent Laborde wrote: > 2008/6/9 Jason Giglio : > > > > Who cares? A small utility anyone can write in a few hours can do this > > today. > > > > *NOT* anyone, just "any coder willing to spend some time on it". > Writing a software to decode the current cache isn't that much complex > than decoding a XOR'd texture cache. > > A lot of software protection can be unlocked replacing a JNZ with a > JNC instruction, extremly simple, but most people simply can't do > that. > > But the question is : does the current obfuscation have any impact on > cache performance ? > As far as i remember, we agreed that the current cache have a very > little impact on performance and most of the cpu time is spent in > decoding j2c. > > The current cache is working, have a very little perfomance impact, > and provide enough protection against script-kiddies. > The probleme is in the jpeg2000 decoding performance. > > > -- > F4FQM > Kerunix Flan > Laurent Laborde > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/3732fca8/attachment-0001.htm From kerdezixe at gmail.com Tue Jun 10 11:57:49 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:57:52 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> Message-ID: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> 2008/6/10 Dahlia Trimble : > > Further, noone is going to be inducted into the programmer hall of fame for > writing a binary file to a disk. If you want to do something that is a > benefit to the community, develop a method that improves cache performance, > saves network bandwidth, and doesnt alienate a large portion of the user > base. If you want to make a cache browser/exporter, then call it that. I see > no reason that a standardized image format would necessarily be the highest > performance choice for a cache. There is one good reason to use a standardized image format and it's directly related to performance. I widely used open format have tons of coder working on the libraries to use this format and work on optimisation/performance. A library used by millions of users, including large corporate company, is most likely highly optimized, stable, reliable and secure. Just take a look at the discussion about "commercial jpeg2000 librarie" vs "openjpeg2k librarie". that's why we don't even talk about trying to improve the decoding libraries performance anymore : it was done already, and by external coders. If LL develop a custom image format, it will cost a lot of ressource to work on optimization, etc ... -- F4FQM Kerunix Flan Laurent Laborde From dahliatrimble at gmail.com Tue Jun 10 12:08:20 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 12:08:23 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: Only if your goal is interopability with external programs. If that is the goal, it should be stated. If the goal is to improve the performance of the viewer, then that goal should be weighed against user needs. On Tue, Jun 10, 2008 at 11:57 AM, Laurent Laborde wrote: > 2008/6/10 Dahlia Trimble : > > > > Further, noone is going to be inducted into the programmer hall of fame > for > > writing a binary file to a disk. If you want to do something that is a > > benefit to the community, develop a method that improves cache > performance, > > saves network bandwidth, and doesnt alienate a large portion of the user > > base. If you want to make a cache browser/exporter, then call it that. I > see > > no reason that a standardized image format would necessarily be the > highest > > performance choice for a cache. > > There is one good reason to use a standardized image format and it's > directly related to performance. > I widely used open format have tons of coder working on the libraries > to use this format and work on optimisation/performance. > > A library used by millions of users, including large corporate > company, is most likely highly optimized, stable, reliable and secure. > Just take a look at the discussion about "commercial jpeg2000 > librarie" vs "openjpeg2k librarie". > > that's why we don't even talk about trying to improve the decoding > libraries performance anymore : it was done already, and by external > coders. > If LL develop a custom image format, it will cost a lot of ressource > to work on optimization, etc ... > > -- > F4FQM > Kerunix Flan > Laurent Laborde > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/9eb317fc/attachment.htm From dahliatrimble at gmail.com Tue Jun 10 12:09:49 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 12:09:53 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: spelling correction: inter-operability On Tue, Jun 10, 2008 at 12:08 PM, Dahlia Trimble wrote: > Only if your goal is interopability with external programs. If that is the > goal, it should be stated. If the goal is to improve the performance of the > viewer, then that goal should be weighed against user needs. > > > On Tue, Jun 10, 2008 at 11:57 AM, Laurent Laborde > wrote: > >> 2008/6/10 Dahlia Trimble : >> > >> > Further, noone is going to be inducted into the programmer hall of fame >> for >> > writing a binary file to a disk. If you want to do something that is a >> > benefit to the community, develop a method that improves cache >> performance, >> > saves network bandwidth, and doesnt alienate a large portion of the user >> > base. If you want to make a cache browser/exporter, then call it that. I >> see >> > no reason that a standardized image format would necessarily be the >> highest >> > performance choice for a cache. >> >> There is one good reason to use a standardized image format and it's >> directly related to performance. >> I widely used open format have tons of coder working on the libraries >> to use this format and work on optimisation/performance. >> >> A library used by millions of users, including large corporate >> company, is most likely highly optimized, stable, reliable and secure. >> Just take a look at the discussion about "commercial jpeg2000 >> librarie" vs "openjpeg2k librarie". >> >> that's why we don't even talk about trying to improve the decoding >> libraries performance anymore : it was done already, and by external >> coders. >> If LL develop a custom image format, it will cost a lot of ressource >> to work on optimization, etc ... >> >> -- >> F4FQM >> Kerunix Flan >> Laurent Laborde >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/1b67d384/attachment.htm From darien_caldwell at comcast.net Tue Jun 10 12:57:13 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Tue Jun 10 12:57:20 2008 Subject: [sldev] How Far For Security? Message-ID: <061020081957.26755.484EDC990000ADFA00006883221654997604040A990B040E0CA1020A079D0E0B@comcast.net> -------------- Original message ---------------------- From: "John Hurliman" > On Tue, Jun 10, 2008 at 12:46 AM, Argent Stonecutter < > secret.argent@gmail.com> wrote: > > > On 2008-06-10, at 01:34, Jason Giglio wrote: > > > >> Argent Stonecutter wrote: > >> > >>> The corollary of (a) is "eliminate a huge portion of the SL economy, > >>> and possibly go out of business". > >>> > >> > >> > > Yes, because the entire economy collapsed the day after copybot came out. > >> > > > > Don't be silly. If copybot had not been broken, incomplete, and horribly > > inconvenient, if it been built into the standard client, with right click > > "show source" and "save as" that worked like "show source" and "save as" in > > a browser (because that IS what "treat it like the web" implies) in a > > browser and let you trivially grab all prims and assets in a convenient form > > for uploading as your own product, then... yes... it likely would have. > > > > > > Then why hasn't primpreview killed the SL economy? > http://www.youtube.com/watch?v=LfMNygcceAs maybe because nobody knows what it is, what it does, or where to get it? First time i've ever heard of it. -------------- next part -------------- An embedded message was scrubbed... From: "John Hurliman" Subject: Re: [sldev] How Far For Security? Date: Tue, 10 Jun 2008 16:35:38 +0000 Size: 3988 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/35344be1/attachment.eml From missannotoole at yahoo.com Tue Jun 10 13:06:41 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 10 13:06:44 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <880510.18376.qm@web59115.mail.re1.yahoo.com> Let us ensure we have the priorities straight. With Time Warner and other cable modem service providers preparing to implement bytes transferred caps it is imperative that the cache operation overall be improved to ensure there is no repetitive downloading of bytes. It simply will not matter if the bytes are obfuscated if the population of Secondlife is gutted by a large scale *perceived inability* to afford to participate. So instead of arguing about politics the emphasis should be on: 1. Increasing the size of the local cache 2. Enhancing the reliability and performance of this local cache I seriously doubt anyone would complain if some increased protection happened to fall out of those 2 priorities. However we generally know this possibility is unlikely unless it came in the form of some compression we have not yet considered. Save SL first. Then worry about the rest. If SL dies because of consumers *not being aware of their choices in service providers* then nothing really matters does it? That is where my opinion stands at this time. Any faster open source image compression libs out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/0f8e3d2f/attachment.htm From robla at lindenlab.com Tue Jun 10 13:29:37 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jun 10 13:29:45 2008 Subject: [sldev] Security issues/Thank you/Congratulations In-Reply-To: References: Message-ID: <484EE431.20902@lindenlab.com> Thanks for sending this. I can't personally take any credit for this, but (of the people I know at least semi-regularly read here) folks like Phoenix and Soft would well deserve to take a bow. Comments, complaints, and of course cheers and pats on the back about our security process are welcome here: https://wiki.secondlife.com/wiki/Talk:Security_issues Rob On 6/10/08 1:20 AM, Brandon Lockaby wrote: > > When I first started digging into the SL protocol, it seemed like just > about everything I tried to do uncovered a security issue. For awhile > I thought we were just doomed, I mean it :D Alot of you who work with > the protocol surely know the sort of thing I'm talking about! > > But right now I'm breathing a sigh of relief because from my point of > view, things have been changing fast! Granted, there are still issues, > and I'm sure they won't dry up just yet as I see an increasing number > of people deciding to work with the protocol lately, but as of now I > can honestly say I don't know a way to crash the official viewer or > ruin someone's business just by using the intended client/server > protocols on LL's grid. > > So I want to thank Linden Lab for responding so well to security > issues, and say congratulations! As far as I'm concerned the response > to these issues is stellar. And I want to extend thanks to everyone > who makes an effort to report security issues. I know many of these > people are probably nervous about talking publically about the things > they've seen but they deserve some recognition. Well here is a huge > THANK YOU to EVERYONE involved in helping improve Second Life in this > very important way! :D > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cenji.neutra at gmail.com Tue Jun 10 13:40:10 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 13:40:12 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484ED636.3060309@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> Message-ID: > Cenji Neutra wrote: > To my mind, the identifiers aren't resource locators (URLs). A URN does > seem like a nice idea though (goes looking for the URI RFC...) > On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter wrote: > XML namespaces ran into the same confusion, where the namespace identifiers > *typically* look like URLs but are often actually unresolvable because they > are "merely" namespace identifiers. The RDDL idea is to make them actually > resolvable URLs, where the intent is that they resolve to a rddl document > that describes the domain that the namespace models. The nice thing about > this approach is that it allows for a completely distributed solution: once > you've got the identifier, you can find out everything else you need to know > to connect without any sort of central registry. The point to make here is > that even in the URL case, the identifier is still just a reference not the > grid it names. > Yes, that is a nice property. The only problem with it is that it requires that everyone who controls the domains corresponding to the identifiers to implement the standard service. That would be like requiring hosts on the internet to run their own DNS name server for the subdomain below (if any). While they can certainly do that with the current DNS delegation mechanism, they're not required to do so - they can have an independent DNS service provider (who has no control over the hosts in the domain) for a whole set of hosts and subdomains if they wish. I hazard a guess that the current success of DNS wouldn't have come about if it had required everyone to implement it on many hosts from the outset. Perhaps it is possible to have the advantages of both systems. Perhaps we can use URIs and specifications that layer above that can require that for lookup, applications first query an extended DNS name. What I mean is, if the identifier is some URI containing "main.mygrid.net" then the application should first query a URL like "http://main.mygrid.net/grid.xml" (or whatever) and if it receives a 404 or other error (including a timeout) it should then try "http://main.mygrid.net.virtualworld.net/grid.xml" where "virtualworld.net" is the configured lookup service provider for that application (and any number of parties can opt to provide that kind of lookup service). That way, we can start providing a conforming service that works for all the existing grids (and new grids) even if they haven't implemented the standard. The 'timeout' could be a problem. Perhaps we should just use DNS to do a SRV record lookup of the domain and the absence of a record would indicate the service isn't supported, the presence of a SVN record can point to the URL of the actual XML. If there is no record, then a SRV record lookup on main.mygrid.net.virtualworld.net (or whatever) is performed instead. Thinking out loud there :) -Cenji. From dmahalko at gmail.com Tue Jun 10 14:29:52 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 10 14:29:55 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") Message-ID: I am of the opinion that this discussion belongs on the developer list, because as yet we still don't seem to know what is the best direction to take regarding the handling of cached assets. The current somewhat obfuscated solution isn't the greatest in terms of performance but it is there and it works for now. We and need to figure out what direction to go if that is going to change. I see the coder-geeks complaining about people like me not "contributing code" and so our participation is deemed worthless, but you cannot launch straight off into writing code without knowing what it is you're supposed to be doing, or if LL is philosophically in support of adding it into the client codebase. I will mention that on the old SL forums years ago I was discussing the possibility of a 3D video card with a dedicated, isolated memory space and a public/private key DRM model. Textures would be sent from the grid to the client in a pre-encrypted form, stored in this encrypted state in the client cache, and only decoded inside the protected memory space of the 3D card. By pairing this with HDCP this would create a secured digital pathway for assets to be reasonably protected from theft. Of course this was attacked in the forums as untenable and that "it will be hacked and you cannot stop it", which is not the point. The point is that it creates a similarly locked front door metaphor. As a thief you must be willing to go to some measures to break this protection in order to steal the content protected inside, and which gives a lawyer a definite case for prosecution since it isn't like the files sit in a raw format in a folder just waiting for Picasa to stumble across it and unknowingly catalog it. Since there are now only two significant players in the 3D card market, nVidia and ATI, it would be relatively easy for a copy protection mechanism to enter the marketplace and silently slip into place, as is already happening now as HDCP is replacing old non-HDCP cards. The overall performance may suffer somewhat due to the heavy encryption, but this would give content creators the legal protection they need to prosecute potential asset thieves. Besides with 3D cards now pushing 1 gigabyte and more of onboard memory plus ultra-high power processing, it's not like there would be a huge step back in performance. Perhaps a dedicated decryption pipeline could be developed so that there is no performance taken away from the main 3D chipset. And, with no need to obfuscate the downloaded cached assets, they can be written directly to that fast massive terabyte local folder-based disk cache with no need for obfuscation. Perhaps as GPU power continues to increase, more than textures could be encrpyted. Perhaps the whole asset system could be encrpyted and most of the client code run inside the protected space with few ways to send raw decrypted asset data back out. It would be interesting to see if a "write-only" physical memory could be created, where the only way to verify data was written correctly into the protected space is via a return path that can only provide a checksum on the written data. If LL wanted a protected asset pathway, this is probably the way forward, though it would take a few years to be implemented and rolled out to the public. I could see the MPEG-V people possibly also being interested in this for content protection purposes. - Scalar Tardis / Dale Mahalko On Tue, Jun 10, 2008 at 1:05 PM, JB Kraft wrote: > I apologize to the list if this particular discussion is somewhat too > philosophical and out of bounds to its purpose but I feel strongly about it > as both a programmer and a musician and think it bears the consideration of > other approaches from both the the litigators asking the programmer to be > locksmiths and the programmers somewhat naively seeing information as > something that "wants to be free". Knowledge may want to be free but I'd > rather you gave me a few cents for my information/music somehow. :) From sldev at catznip.com Tue Jun 10 14:48:43 2008 From: sldev at catznip.com (Kitty) Date: Tue Jun 10 14:45:55 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: Wouldn't that just make it impossible to still take snapshots in SL? Or something like machinema? It also wouldn't stop texture UUID grabbing/reuse, so would it actually make any significant difference that's worth what you'd be giving up? Infringement isn't a technological problem, it's a legal problem. From me at signpostmarv.name Tue Jun 10 15:17:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 15:17:10 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: <484EFD63.3020504@signpostmarv.name> Dale Mahalko wrote: > I will mention that on the old SL forums years ago I was discussing > the possibility of a 3D video card with a dedicated, isolated memory > space and a public/private key DRM model. Textures would be sent from > the grid to the client in a pre-encrypted form, stored in this > encrypted state in the client cache, and only decoded inside the > protected memory space of the 3D card. By pairing this with HDCP this > would create a secured digital pathway for assets to be reasonably > protected from theft. > > Of course this was attacked in the forums as untenable and that "it > will be hacked and you cannot stop it", which is not the point. The > point is that it creates a similarly locked front door metaphor. As a > thief you must be willing to go to some measures to break this > protection in order to steal the content protected inside, and which > gives a lawyer a definite case for prosecution since it isn't like the > files sit in a raw format in a folder just waiting for Picasa to > stumble across it and unknowingly catalog it. > > Since there are now only two significant players in the 3D card > market, nVidia and ATI, it would be relatively easy for a copy > protection mechanism to enter the marketplace and silently slip into > place, as is already happening now as HDCP is replacing old non-HDCP > cards. > > The overall performance may suffer somewhat due to the heavy > encryption, but this would give content creators the legal protection > they need to prosecute potential asset thieves. Besides with 3D cards > now pushing 1 gigabyte and more of onboard memory plus ultra-high > power processing, it's not like there would be a huge step back in > performance. Wouldn't that lock out every single person and/or device that doesn't have a supporting graphics card ? DRM for 3D apps on the scale of Second Life is rather inefficient and pointless, and would vastly restrict the adoption of SL. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/6a57f2e1/smime.bin From cenji.neutra at gmail.com Tue Jun 10 15:25:27 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 15:25:29 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EFCD4.6080508@isn-oldenburg.de> References: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> <484EFCD4.6080508@isn-oldenburg.de> Message-ID: > Basically you get all of this with either ASN.1 OIDs, X.500 DNs or URNs. > Define a format and than define the resolver that maps IDs to services. No > need to invent something new (just an URN scheme and a spec for a resolver > for that scheme). We'll certainly look at those options. No point needlessly reinventing things - the very reason we threw this out for comment. Thanks for your input. -Cenji. From vexstreeter at gmail.com Tue Jun 10 15:49:12 2008 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue Jun 10 15:49:43 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> Message-ID: <484F04E8.3070201@gmail.com> Cenji Neutra wrote: >> Cenji Neutra wrote: >> To my mind, the identifiers aren't resource locators (URLs). A URN does >> seem like a nice idea though (goes looking for the URI RFC...) >> >> > On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter wrote: > >> XML namespaces ran into the same confusion, where the namespace identifiers >> *typically* look like URLs but are often actually unresolvable because they >> are "merely" namespace identifiers. The RDDL idea is to make them actually >> resolvable URLs, where the intent is that they resolve to a rddl document >> that describes the domain that the namespace models. The nice thing about >> this approach is that it allows for a completely distributed solution: once >> you've got the identifier, you can find out everything else you need to know >> to connect without any sort of central registry. The point to make here is >> that even in the URL case, the identifier is still just a reference not the >> grid it names. >> >> > > Yes, that is a nice property. The only problem with it is that it > requires that everyone who controls the domains corresponding to the > identifiers to implement the standard service. Well, the implication is that the organization running grid X would both own the domain name X and IFF they want the grid to be publicly resolvable would put a grid description document at X. For instance case 1: public SL grid id = "http://grid.secondlife.com/agni" resolved contents of id: Second Life https://login.agni.lindenlab.com/cgi-bin/login.cgi ... etc case 2: my private grid id="http://myprivatemetaverse.org/" resolved contents of id: HTTP 404 error > Perhaps it is possible to have the advantages of both systems. > Perhaps we can use URIs and specifications that layer above that can > require that for lookup, applications first query an extended DNS > name. Two recommendations: - that there be no "search" required to resolve - it either resolves or it doesn't. You might do it on initial discovery, but generally it is a way to advertise your grid in a more structured and useful way than a wiki page, definitely not in the critical path for client boot. - if published, the grid information should be *static*, that is, as a design goal, it ought to define the specific grid in a pretty deep way so you don't need to retrieve it ever again. Use dns to resolve major grid services, etc. Most clients would ship with a set of grid references, e.g. something like Gareth Ellison's supergrid (http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) Cheers, Vex From sllists at boroon.dasgupta.ch Tue Jun 10 15:59:13 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jun 10 15:59:18 2008 Subject: [sldev] Trusted Computing, anyone? (was: 3D cards with DRM support) In-Reply-To: References: Message-ID: <484F0741.1000709@boroon.dasgupta.ch> Dale Mahalko schrieb: > I will mention that on the old SL forums years ago I was discussing > the possibility of a 3D video card with a dedicated, isolated memory > space and a public/private key DRM model. Textures would be sent from > the grid to the client in a pre-encrypted form, stored in this > encrypted state in the client cache, and only decoded inside the > protected memory space of the 3D card. By pairing this with HDCP this > would create a secured digital pathway for assets to be reasonably > protected from theft. Why does this make me remember Seg's message here? https://lists.secondlife.com/pipermail/sldev/2007-September/005111.html Oh well, guess it must be the lafkon link at the end of the message. (Yeah, I admit that's propaganda. But I think the point is valid.) Taking away the users' control over hardware they've bought is IMHO morally as questionable as is illegally copying content. A small hurdle (as the current obfuscation) can't hurt, so that nobody breaks the law without even noticing himself. Everything else is either futile or will bring too much collateral damage with it (sometimes even both). Boroondas From kwerks.sl at gmail.com Tue Jun 10 16:08:04 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 16:08:06 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484F04E8.3070201@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> <484F04E8.3070201@gmail.com> Message-ID: <7b61e3970806101608t2b8bd081ua7e87dc7fd9e09b7@mail.gmail.com> This is something, XML wise, I was trying to nudge the viewer toward with http://jira.secondlife.com/browse/VWR-7531. LL (Mani) felt LLSD was the better course specifically. I remain dubious to that format myself but updated the patch nonetheless to accommodate. I realize it not specific to the grid notation format in this thread but just thought I'd mention it here in case someone wants to comment there as there is some overlap. regards JB On Tue, Jun 10, 2008 at 6:49 PM, Vex Streeter wrote: > Cenji Neutra wrote: > >> Cenji Neutra wrote: >>> To my mind, the identifiers aren't resource locators (URLs). A URN does >>> seem like a nice idea though (goes looking for the URI RFC...) >>> >>> >>> >> On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter >> wrote: >> >> >>> XML namespaces ran into the same confusion, where the namespace >>> identifiers >>> *typically* look like URLs but are often actually unresolvable because >>> they >>> are "merely" namespace identifiers. The RDDL idea is to make them >>> actually >>> resolvable URLs, where the intent is that they resolve to a rddl document >>> that describes the domain that the namespace models. The nice thing about >>> this approach is that it allows for a completely distributed solution: >>> once >>> you've got the identifier, you can find out everything else you need to >>> know >>> to connect without any sort of central registry. The point to make here >>> is >>> that even in the URL case, the identifier is still just a reference not >>> the >>> grid it names. >>> >>> >>> >> >> Yes, that is a nice property. The only problem with it is that it >> requires that everyone who controls the domains corresponding to the >> identifiers to implement the standard service. >> > Well, the implication is that the organization running grid X would both > own the domain name X and IFF they want the grid to be publicly resolvable > would put a grid description document at X. > > For instance > case 1: public SL grid > id = "http://grid.secondlife.com/agni" > resolved contents of id: > > Second Life > https://login.agni.lindenlab.com/cgi-bin/login.cgi > ... > etc > > > case 2: my private grid > id="http://myprivatemetaverse.org/" > resolved contents of id: HTTP 404 error > > > Perhaps it is possible to have the advantages of both systems. >> Perhaps we can use URIs and specifications that layer above that can >> require that for lookup, applications first query an extended DNS >> name. >> > Two recommendations: > - that there be no "search" required to resolve - it either resolves or it > doesn't. You might do it on initial discovery, but generally it is a way to > advertise your grid in a more structured and useful way than a wiki page, > definitely not in the critical path for client boot. > - if published, the grid information should be *static*, that is, as a > design goal, it ought to define the specific grid in a pretty deep way so > you don't need to retrieve it ever again. Use dns to resolve major grid > services, etc. Most clients would ship with a set of grid references, e.g. > something like Gareth Ellison's supergrid ( > http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) > > Cheers, > Vex > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/792fb9f6/attachment.htm From cenji.neutra at gmail.com Tue Jun 10 16:23:41 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 16:23:43 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484F04E8.3070201@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> <484F04E8.3070201@gmail.com> Message-ID: On Tue, Jun 10, 2008 at 6:49 PM, Vex Streeter wrote: > Well, the implication is that the organization running grid X would both own > the domain name X and IFF they want the grid to be publicly resolvable would > put a grid description document at X. Right, which is something we don't want to *require* in order to facilitate adoption, but something that should be the defacto case if the scheme is adopted in the future (and hence the 'fast path'). That is to say, we want public grids to be resolvable even if the organization running the grid hasn't implemented the scheme (provided the resolver service knows about it of course). Right now, based on the feedback received, we're leaning toward a URN syntax for the 2nd draft. As for URN resolution (not encompassed by the current spec), having the URN be a URL would certainly be simplest, but to satisfy my requirement above, there has to be more to it than that. As you say, having any kind of complex lookup in the critical path of client startup should be avoid if possible. However, the resolution process we'll propose separately and implement will almost certainly use DNS in some way. Thanks, -Cenji. > > For instance > case 1: public SL grid > id = "http://grid.secondlife.com/agni" > resolved contents of id: > > Second Life > https://login.agni.lindenlab.com/cgi-bin/login.cgi > ... > etc > > > case 2: my private grid > id="http://myprivatemetaverse.org/" > resolved contents of id: HTTP 404 error > > >> Perhaps it is possible to have the advantages of both systems. >> Perhaps we can use URIs and specifications that layer above that can >> require that for lookup, applications first query an extended DNS >> name. > > Two recommendations: > - that there be no "search" required to resolve - it either resolves or it > doesn't. You might do it on initial discovery, but generally it is a way to > advertise your grid in a more structured and useful way than a wiki page, > definitely not in the critical path for client boot. > - if published, the grid information should be *static*, that is, as a > design goal, it ought to define the specific grid in a pretty deep way so > you don't need to retrieve it ever again. Use dns to resolve major grid > services, etc. Most clients would ship with a set of grid references, e.g. > something like Gareth Ellison's supergrid > (http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) > > Cheers, > Vex > From loom at loomiverse.net Tue Jun 10 17:55:57 2008 From: loom at loomiverse.net (Loom) Date: Tue Jun 10 17:55:59 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <880510.18376.qm@web59115.mail.re1.yahoo.com> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: On 11/06/2008, Ann Otoole wrote: > > Let us ensure we have the priorities straight. > With Time Warner and other cable modem service providers preparing to > implement bytes transferred caps it is imperative that the cache operation > overall be improved to ensure there is no repetitive downloading of bytes. > > It simply will not matter if the bytes are obfuscated if the population of > Secondlife is gutted by a large scale *perceived inability* to afford to > participate. > > Save SL first. Then worry about the rest. > If SL dies because of consumers *not being aware of their choices in > service providers* then nothing really matters does it? > I realise that you have used the word "perceived" in there but I would like to suggest that usage caps are not going to kill secondlife. Personally, I don't agree with the idea of usage caps, however in Australia we have lived with them for quite a while. >From the march 2008 economic stats, there were 12,245 active Australian users or about 0.057% of the population, who clocked up an average of 47 hours each - using usage capped internet connections. Compare that with the US where 194,899 active users (0.064% of the population) clocked up an average of 59 hours each. At worst, SL may take a hit in usage, but suggesting that it will die is imho an extreme view which is more in the line of fearmongering than rational analysis. Loom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/70d710a4/attachment.htm From sakkaku at gmail.com Tue Jun 10 18:05:12 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue Jun 10 18:05:15 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> On Tue, Jun 10, 2008 at 7:55 PM, Loom wrote: > > > On 11/06/2008, Ann Otoole wrote: >> >> Let us ensure we have the priorities straight. >> With Time Warner and other cable modem service providers preparing to >> implement bytes transferred caps it is imperative that the cache operation >> overall be improved to ensure there is no repetitive downloading of bytes. >> >> It simply will not matter if the bytes are obfuscated if the population of >> Secondlife is gutted by a large scale *perceived inability* to afford to >> participate. >> >> Save SL first. Then worry about the rest. >> If SL dies because of consumers *not being aware of their choices in >> service providers* then nothing really matters does it? > > I realise that you have used the word "perceived" in there but I would like > to suggest that usage caps are not going to kill secondlife. > > Personally, I don't agree with the idea of usage caps, however in Australia > we have lived with them for quite a while. > > From the march 2008 economic stats, there were 12,245 active Australian > users or about 0.057% of the population, who clocked up an average of 47 > hours each - using usage capped internet connections. > > Compare that with the US where 194,899 active users (0.064% of the > population) clocked up an average of 59 hours each. > > At worst, SL may take a hit in usage, but suggesting that it will die is > imho an extreme view which is more in the line of fearmongering than > rational analysis. > > Loom The idea is to plan ahead to avoid running full on into a wall. There is no point in bickering over weather or not people are able to play SL, it is to realize that people ARE capped and MAY be impaired by SL. Why not improve the caching such that the asset servers are hammered less, people have to use less bandwidth and therefor have a more enjoyable experience. From nchase at earthlink.net Tue Jun 10 18:08:30 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Tue Jun 10 18:08:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: <484F258E.1000305@earthlink.net> Loom wrote: > I realise that you have used the word "perceived" in there but I would > like to suggest that usage caps are not going to kill secondlife. I don't know what the usage caps are link in Australia, but in my last house I had Direcway and using SL for more than an hour or two a day was impossible. If I did, i would blow through my entire quota and would be unable to use the Internet AT ALL for 24 hours. Seriously. I'm currently on cable modem and breathing easy, but I'm getting ready to move again and it is literally a requirement that the new house have some kind of "real" broadband, rather than satellite, because I absolutely cannot function on SL with a cap. ---- Nick From lenglish5 at cox.net Tue Jun 10 18:36:03 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 18:36:06 2008 Subject: [sldev] Login SL Using Java Client In-Reply-To: References: Message-ID: <484F2C03.20307@cox.net> Waseem Azhar wrote: > Hi, > > I am writing java SL client. Currently I am stuck with > login-to-simulator case. Using xml-rpc I am able to get authenticated > with xml response from server. But when I send UseCircuitCode packet > to simulator on UDP connection, I get no response from the Simulator. > > Can anyone help ? Have you looked at what the Python code is doing? http://wiki.secondlife.com/wiki/Presence_Code_Python If you watch the packets from the SL viewer, you'll see that acks for these packets don't start coming in for a while, so you have to send the first two or three packets wihout waiting for the ack. In order to be sure that you have a good circuit for use with CAPs, you must wait for an ack, but the first 2 or 3 packets won't ack you until after you send the last one in the sequence, or so it appears. This is probably not intended behavior... Lawson From dmahalko at gmail.com Tue Jun 10 18:46:19 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 10 18:46:22 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: On Tue, Jun 10, 2008 at 4:48 PM, Kitty wrote: > Wouldn't that just make it impossible to still take snapshots in SL? Or > something like machinema? A protected output channel that only produces watermarked snapshots would help to prevent asset theft. In the case of screen recorders, perhaps there would be a way to watermark the entire screen continuously in real-time so that any captures are already protected. (Is it possible to watermark an image "captured" by photographing the screen with a digital camera?) With regard to GL-Intercept, perhaps a modification of OpenGL could appear, called "ClosedGL" or "DRM-GL", which functions only inside the encrypted space and without direct output capability to local system memory. > It also wouldn't stop texture UUID grabbing/reuse, so would it actually make > any significant difference that's worth what you'd be giving up? The overall texture-access system might need to be changed to accommodate a more secure environment. Why should you have access to textures you don't own? It is currently done this way because the client must be able to request textures for every object you see in world, and the asset farm doesn't explicitly know in advance what you "need to see". But the current design model could be changed for a future virtual world. The current model is geared for heavy bandwidth usage and light cache usage, where primitives are separate from their textures, so that the prims can load first and textures appear later. If local caching can be enhanced to be huge and fast to reduce the network dependency, then there is no need for a primitive to be separate from its component textures. Put the primitive and all its textures into a single encrypted asset package that gets stuck in the local cache. When it is to be displayed, this package is loaded into the protected space and the included assets are used with the primitive -- but the user of the client does not have access to those textures to copy them, and doesn't know the UUIDs either since those are inside the package and not externally revealed. To load an object just requires a simple internal reference list, and doesn't need UUID references. "Stored texture at position 1 is applied to all faces of primitive in position 2, in this package." Under such a model, the clients don't even need to know individual UUIDs of objects within a package, to be able to manipulate the package contents. The LL sims can change a texture on a prim's face, by reference to the encrypted package ID: "Apply texture #2 to prim #4 in package X. Change the transparency of prim #23 in package Y." UUIDs may be used in the scripting for simplicity, but becomes an abstract reference for the client, which only knows the encrypted package ID. This does not add additional processing per client, since all clients can use the same offset references to items within a package, and the package is the same across all clients, so the references can be saved into the asset data in the LL asset farm when the encrypted package is created or edited by the asset owner. Encrypted asset packages containing textures, linksets, prims, and sounds would also better fit the multiverse model since there is no need for a global asset farm to store all "your" stuff. Your avatar could cross over to another space with all its protected data held within this single asset package. For this design, the asset downloads would be larger, as unified packages. But if the cache size were in the tens to hundreds of gigabytes, and fast and efficient, then only a single download is needed and that package does not change or need to be redownloaded unless the content creator modifies the package in some way, which requires a new updated package in the cache and expiring the old one. So the initial visit to somewhere would need the assets to load completely before the objects can appear, but the asset packages would never need to download again after that initial visit, if sufficient disk cache space is available. Some form of the current open-access texture UUID system could continue to be supported, but would be redesigned to explicitly warn content creators that their work will be unprotected and can be easily stolen if they use the old asset mechanism. - Scalar Tardis / Dale Mahalko From loom at loomiverse.net Tue Jun 10 19:12:21 2008 From: loom at loomiverse.net (Loom) Date: Tue Jun 10 19:12:23 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> Message-ID: On 11/06/2008, Matthew Underwood wrote: > > On Tue, Jun 10, 2008 at 7:55 PM, Loom wrote: > > > > > > On 11/06/2008, Ann Otoole wrote: > >> > >> Let us ensure we have the priorities straight. > >> With Time Warner and other cable modem service providers preparing to > >> implement bytes transferred caps it is imperative that the cache > operation > >> overall be improved to ensure there is no repetitive downloading of > bytes. > >> > >> It simply will not matter if the bytes are obfuscated if the population > of > >> Secondlife is gutted by a large scale *perceived inability* to afford to > >> participate. > >> > >> Save SL first. Then worry about the rest. > >> If SL dies because of consumers *not being aware of their choices in > >> service providers* then nothing really matters does it? > > > > I realise that you have used the word "perceived" in there but I would > like > > to suggest that usage caps are not going to kill secondlife. > > > > Personally, I don't agree with the idea of usage caps, however in > Australia > > we have lived with them for quite a while. > > > > From the march 2008 economic stats, there were 12,245 active Australian > > users or about 0.057% of the population, who clocked up an average of 47 > > hours each - using usage capped internet connections. > > > > Compare that with the US where 194,899 active users (0.064% of the > > population) clocked up an average of 59 hours each. > > > > At worst, SL may take a hit in usage, but suggesting that it will die is > > imho an extreme view which is more in the line of fearmongering than > > rational analysis. > > > > Loom > > > The idea is to plan ahead to avoid running full on into a wall. There > is no point in bickering over weather or not people are able to play > SL, it is to realize that people ARE capped and MAY be impaired by SL. > Why not improve the caching such that the asset servers are hammered > less, people have to use less bandwidth and therefor have a more > enjoyable experience. > > No argument there, I'm simply point out that an "OMG usage caps will kill SL" attitude is not necessarliy a reasonable stance to take. A simple and I believe strong argument for both better cache and texture decoding code is that it has to be faster than downloading an asset from somewhere else on the internet every single time it is needed. The fatser the code, the better the SL experience for anyone. In a sense, the paranoia about caps being introduced in the US will potentially make SL better for everyone if it means that cache performance is improved. Loom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/0a205fab/attachment.htm From loom at loomiverse.net Tue Jun 10 19:15:30 2008 From: loom at loomiverse.net (Loom) Date: Tue Jun 10 19:15:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484F258E.1000305@earthlink.net> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> <484F258E.1000305@earthlink.net> Message-ID: On 11/06/2008, Nicholas Chase wrote: > > > > Loom wrote: > > I realise that you have used the word "perceived" in there but I would >> like to suggest that usage caps are not going to kill secondlife. >> > > I don't know what the usage caps are link in Australia, but in my last > house I had Direcway and using SL for more than an hour or two a day was > impossible. If I did, i would blow through my entire quota and would be > unable to use the Internet AT ALL for 24 hours. > > Seriously. > > I'm currently on cable modem and breathing easy, but I'm getting ready to > move again and it is literally a requirement that the new house have some > kind of "real" broadband, rather than satellite, because I absolutely cannot > function on SL with a cap. > > ---- Nick > I don't know what sattellite broadband caps are like in Australia, but I'd expect that they must be more restrictive than say cable or DSL, since we are talking about an even more limited resource. Loom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/d3bb84eb/attachment.htm From secret.argent at gmail.com Tue Jun 10 19:56:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 19:54:33 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <507C4C7F-AE35-4CB9-99D1-48911594EFF3@gmail.com> > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to have them > confused with DNS domain names. For example, "com.secondlife.agni" > could be the identifier for the SL main grid. There are also specific > identifier types for VW components, such as SLGOGP's "agent domains" > and "region domains". Haven't had time to look at it yet, but that certainly sounds like a good start to me. From secret.argent at gmail.com Tue Jun 10 19:59:33 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 19:58:06 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA60A.4050909@gmail.com> References: <484EA60A.4050909@gmail.com> Message-ID: <73429819-1E7F-421C-9629-3018579DBFA1@gmail.com> On 2008-06-10, at 11:04, Jason Giglio wrote: > Why? What's the point in reversing them? That's a pretty standard thing to do in creating custom identifiers based on domain names. There are a number of other systems that do this the same way to indicate that this is an *identifier*, but not an addressible site. The effect of using URIs for identifiers in XML DSDs has been pretty heavy traffic on the sites specified from naive programmers who thought they needed to fetch a DSD every time they parsed it. From secret.argent at gmail.com Tue Jun 10 20:06:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 20:05:33 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: <972617A3-E31B-4EFB-B742-503A5313286B@gmail.com> On 2008-06-10, at 11:35, John Hurliman wrote: > Then why hasn't primpreview killed the SL economy? It ignores permissions? It's part of the SL browser? It's distributed by Linden Labs? I specifically described a situation where the standard SL browser acted just like a standard web browser, with the ability to download everything, scripts and all, into a replicable working copy of an object, just like any web browser worth its salt can do to a webpage. That is, if SL was "just like the internet", the Linden economy as it is now would simply not exist. I didn't mean nor say anything more than that. From secret.argent at gmail.com Tue Jun 10 20:18:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 20:16:44 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> Message-ID: <3B66AB77-7EA3-4F76-B90D-FE731DDDF28B@gmail.com> On 2008-06-10, at 13:34, Dahlia Trimble wrote: > If I wear my "as a user" hat, I'm not sure a small increase in > cache performance is going to sway my opinion of the software. The changes being suggested, at least the version I'm proposing, would make a huge difference to cache performance. > If, wearing my "content creator" hat , I see that there are no > obstacles to anyone getting full permission access to my content, And they wouldn't remove any of the current obstacles to anyone getting full permission access to your content. From secret.argent at gmail.com Tue Jun 10 20:22:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 20:20:44 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: On 2008-06-10, at 13:57, Laurent Laborde wrote: > If LL develop a custom image format, it will cost a lot of ressource > to work on optimization, etc ... The 'custom image format' under discussion is just "dump the decoded texture in whatever format it exists in memory, along with associated metadata, with a constant-cost obfuscation layer such as XORing the content with some constant secret." There is no optimization necessary, because there's no codec, and miminal overhead: it's a straight copy and a tight "XOR" loop. Even simple RLL encoding is more overhead. From secret.argent at gmail.com Tue Jun 10 20:59:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 20:58:14 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: I would like to suggest that people who are really gung-ho on strong DRM read "Persistence" by Karl Schroeder. From lenglish5 at cox.net Tue Jun 10 22:49:09 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 22:49:11 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484EB482.2050407@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> <484EB482.2050407@signpostmarv.name> Message-ID: <484F6755.9070606@cox.net> SignpostMarv Martin wrote: > John Hurliman wrote: >> Then why hasn't primpreview killed the SL economy? >> http://www.youtube.com/watch?v=LfMNygcceAs > > ^this is the kind of interface I was referring to for the iPhone. > > ~ Marv. Check out the 3D twitch game demos for iPhone 2. There's no reason to use such a primitive interface for the iPhone 2. Certainly, not every smartphone can do what the iPhone does, but it will have to be implemented in objC anyway, so its not going to be some Sleek rehash, I'm confident. Lawson From loom at loomiverse.net Tue Jun 10 23:08:57 2008 From: loom at loomiverse.net (Loom) Date: Tue Jun 10 23:09:00 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: On 11/06/2008, Dale Mahalko wrote: > > How does the encrypted cached copy of my house which is stored in your cache on your PC know whether to show my front door as open or closed? or whether the windows are currently shaded or not? you'd have to timeout prim packages in the cache every time I opened my front door, closed it or changed my windows from opaque to transparent and back again. It might be possible for every object in my cache to open an encrytped tunnel back to a sim to record updates, but realistically, that level of DRM inspired security is just going to introduce more problems than it solves. Loom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/f4517849/attachment.htm From tateru.nino at gmail.com Tue Jun 10 23:47:03 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 23:47:51 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <880510.18376.qm@web59115.mail.re1.yahoo.com> <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> Message-ID: <484F74E7.9020107@gmail.com> Loom wrote: > > On 11/06/2008, *Matthew Underwood* > wrote: > > On Tue, Jun 10, 2008 at 7:55 PM, Loom > wrote: > > > > > > On 11/06/2008, Ann Otoole > wrote: > >> > >> Let us ensure we have the priorities straight. > >> With Time Warner and other cable modem service providers > preparing to > >> implement bytes transferred caps it is imperative that the > cache operation > >> overall be improved to ensure there is no repetitive > downloading of bytes. > >> > >> It simply will not matter if the bytes are obfuscated if the > population of > >> Secondlife is gutted by a large scale *perceived inability* to > afford to > >> participate. > >> > >> Save SL first. Then worry about the rest. > >> If SL dies because of consumers *not being aware of their > choices in > >> service providers* then nothing really matters does it? > > > > I realise that you have used the word "perceived" in there but I > would like > > to suggest that usage caps are not going to kill secondlife. > > > > Personally, I don't agree with the idea of usage caps, however > in Australia > > we have lived with them for quite a while. > > > > From the march 2008 economic stats, there were 12,245 active > Australian > > users or about 0.057% of the population, who clocked up an > average of 47 > > hours each - using usage capped internet connections. > > > > Compare that with the US where 194,899 active users (0.064% of the > > population) clocked up an average of 59 hours each. > > > > At worst, SL may take a hit in usage, but suggesting that it > will die is > > imho an extreme view which is more in the line of fearmongering than > > rational analysis. > > > > Loom > > > The idea is to plan ahead to avoid running full on into a wall. There > is no point in bickering over weather or not people are able to play > SL, it is to realize that people ARE capped and MAY be impaired by SL. > Why not improve the caching such that the asset servers are hammered > less, people have to use less bandwidth and therefor have a more > enjoyable experience. > > No argument there, I'm simply point out that an "OMG usage caps will > kill SL" attitude is not necessarliy a reasonable stance to take. > > A simple and I believe strong argument for both better cache and > texture decoding code is that it has to be faster than downloading an > asset from somewhere else on the internet every single time it is > needed. The fatser the code, the better the SL experience for anyone. > In a sense, the paranoia about caps being introduced in the US will > potentially make SL better for everyone if it means that cache > performance is improved. > Caps would certainly cause each user to reevaluate how they spend their network traffic, in what proportion and how often. From tateru.nino at gmail.com Tue Jun 10 23:49:50 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 23:50:38 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484F258E.1000305@earthlink.net> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> <484F258E.1000305@earthlink.net> Message-ID: <484F758E.8080807@weblogsinc.com> Nicholas Chase wrote: > > > Loom wrote: > >> I realise that you have used the word "perceived" in there but I >> would like to suggest that usage caps are not going to kill secondlife. > > I don't know what the usage caps are link in Australia, but in my last > house I had Direcway and using SL for more than an hour or two a day > was impossible. If I did, i would blow through my entire quota and > would be unable to use the Internet AT ALL for 24 hours. > > Seriously. > > I'm currently on cable modem and breathing easy, but I'm getting ready > to move again and it is literally a requirement that the new house > have some kind of "real" broadband, rather than satellite, because I > absolutely cannot function on SL with a cap. On our maximum available plan, we can manage about 6 hours of SL per day, depending on exactly how much data has to be pulled back. Twelve if I keep to a skybox most of the time. Divided up among the family, we have to balance our usage carefully each and every day to avoid running short at the end of the month. -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jun 11 00:31:36 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 11 00:32:24 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA60A.4050909@gmail.com> References: <484EA60A.4050909@gmail.com> Message-ID: <484F7F58.8040004@gmail.com> Jason Giglio wrote: > Cenji Neutra wrote: > >> http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec >> >> In short, we're proposing using a domain-name-like system for >> identifiers, but with the components reversed so as not to have them >> confused with DNS domain names. For example, "com.secondlife.agni" >> could be the identifier for the SL main grid. There are also specific >> identifier types for VW components, such as SLGOGP's "agent domains" >> and "region domains". >> > > Why? What's the point in reversing them? Actually it isn't all that long ago that about half of internet domain names were that way around (while the other half were the other way). For resolution purposes it makes start with the TLD first, since that's the order you actually _operate_ on domain names. However, human usage won, and humans prefer to work the other way around, since they would be typing and reading them all the time. From darien_caldwell at comcast.net Wed Jun 11 00:51:13 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jun 11 00:51:10 2008 Subject: [sldev] Cache politics: performance vs obfuscation References: <484CEFFD.4060408@gmail.com><8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com><8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: <21BEBD9B86734E078439593E44517237@a644000> Argent wins the thread. Most are either completely downplaying any sort of deterrent to theft and actually encouraging it, while the other side is proposing ridiculously complex encryption specifications which would severely harm the ability of SL to function. Argent's proposal is balanced enough to make everyone happy. Sure, anyone with can get past a "Hello World" program will be able to break it. But the point is, 90% of SL users can't get that far. So as a deterrent, it will prevent casual misappropriation of restricted materials. On the other end, it won't severely hamper anyone from doing whatever 'ubercool' stuff they want to do. It gets my vote. ----- Original Message ----- From: "Argent Stonecutter" To: "Laurent Laborde" Cc: "Second Life Developer Mailing List" Sent: Tuesday, June 10, 2008 8:22 PM Subject: Re: [sldev] Cache politics: performance vs obfuscation > On 2008-06-10, at 13:57, Laurent Laborde wrote: >> If LL develop a custom image format, it will cost a lot of ressource >> to work on optimization, etc ... > > The 'custom image format' under discussion is just "dump the decoded > texture in whatever format it exists in memory, along with associated > metadata, with a constant-cost obfuscation layer such as XORing the > content with some constant secret." > > There is no optimization necessary, because there's no codec, and miminal > overhead: it's a straight copy and a tight "XOR" loop. Even simple RLL > encoding is more overhead. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dahliatrimble at gmail.com Wed Jun 11 00:58:16 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Jun 11 00:58:18 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: Following this path may be quite difficult. Many countries including the US have laws restricting the export of encryption hardware and software. Unless it is a trivial process to acquire the necessary approvals, I dont see this as a viable alternative for a company with an international customer base. On Tue, Jun 10, 2008 at 2:29 PM, Dale Mahalko wrote: > I am of the opinion that this discussion belongs on the developer > list, because as yet we still don't seem to know what is the best > direction to take regarding the handling of cached assets. The current > somewhat obfuscated solution isn't the greatest in terms of > performance but it is there and it works for now. We and need to > figure out what direction to go if that is going to change. > > I see the coder-geeks complaining about people like me not > "contributing code" and so our participation is deemed worthless, but > you cannot launch straight off into writing code without knowing what > it is you're supposed to be doing, or if LL is philosophically in > support of adding it into the client codebase. > > > I will mention that on the old SL forums years ago I was discussing > the possibility of a 3D video card with a dedicated, isolated memory > space and a public/private key DRM model. Textures would be sent from > the grid to the client in a pre-encrypted form, stored in this > encrypted state in the client cache, and only decoded inside the > protected memory space of the 3D card. By pairing this with HDCP this > would create a secured digital pathway for assets to be reasonably > protected from theft. > > Of course this was attacked in the forums as untenable and that "it > will be hacked and you cannot stop it", which is not the point. The > point is that it creates a similarly locked front door metaphor. As a > thief you must be willing to go to some measures to break this > protection in order to steal the content protected inside, and which > gives a lawyer a definite case for prosecution since it isn't like the > files sit in a raw format in a folder just waiting for Picasa to > stumble across it and unknowingly catalog it. > > Since there are now only two significant players in the 3D card > market, nVidia and ATI, it would be relatively easy for a copy > protection mechanism to enter the marketplace and silently slip into > place, as is already happening now as HDCP is replacing old non-HDCP > cards. > > The overall performance may suffer somewhat due to the heavy > encryption, but this would give content creators the legal protection > they need to prosecute potential asset thieves. Besides with 3D cards > now pushing 1 gigabyte and more of onboard memory plus ultra-high > power processing, it's not like there would be a huge step back in > performance. > > Perhaps a dedicated decryption pipeline could be developed so that > there is no performance taken away from the main 3D chipset. And, with > no need to obfuscate the downloaded cached assets, they can be written > directly to that fast massive terabyte local folder-based disk cache > with no need for obfuscation. > > Perhaps as GPU power continues to increase, more than textures could > be encrpyted. Perhaps the whole asset system could be encrpyted and > most of the client code run inside the protected space with few ways > to send raw decrypted asset data back out. > > It would be interesting to see if a "write-only" physical memory could > be created, where the only way to verify data was written correctly > into the protected space is via a return path that can only provide a > checksum on the written data. > > If LL wanted a protected asset pathway, this is probably the way > forward, though it would take a few years to be implemented and rolled > out to the public. I could see the MPEG-V people possibly also being > interested in this for content protection purposes. > > - Scalar Tardis / Dale Mahalko > > > On Tue, Jun 10, 2008 at 1:05 PM, JB Kraft wrote: > > I apologize to the list if this particular discussion is somewhat too > > philosophical and out of bounds to its purpose but I feel strongly about > it > > as both a programmer and a musician and think it bears the consideration > of > > other approaches from both the the litigators asking the programmer to be > > locksmiths and the programmers somewhat naively seeing information as > > something that "wants to be free". Knowledge may want to be free but I'd > > rather you gave me a few cents for my information/music somehow. :) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/aed37507/attachment.htm From dmahalko at gmail.com Wed Jun 11 01:12:02 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 11 01:12:06 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: On Wed, Jun 11, 2008 at 1:08 AM, Loom wrote: > How does the encrypted cached copy of my house which is stored in your cache > on your PC know whether to show my front door as open or closed? or whether > the windows are currently shaded or not? you'd have to timeout prim > packages in the cache every time I opened my front door, closed it or > changed my windows from opaque to transparent and back again. Only major state changes that would replace the previous cached package, such as adding or removing assets to the package. The positioning of prims in a linkset in a package would be encrypted, but the positions and rotations of individual prims would not because each separate prim is already in its own package, or are all copies of one cached package. Your door would form one package. When someone arrives at your home, the door package positioning is sent to the client exactly like how the positioning and rotations of linksets are loaded into the world now.. Package states such as your window transparency could be handled as a "default setting" encoded into the package. If your windows are fully transparent in the default state, but right now they are 50%, and then sim just informs the client of the minor differences when rezzing the world. "Show asset package 'BayWindow' at position v, rotation r, and also, set face 3 and 7 of prim 5 in package to current state of 50% transparent." The default stored package state could be accessible via scripting to quickly revert it "back to normal": llResetPackageState(); If there were a way to directly create multiple different states into an encrypted package, and naming or numbering those saved states, then you have the beginnings of a fast client-side animation system -- duplicated on the sim of course, but less network traffic needed to update the client object state. The client would just need to be informed via a script to use this extra state data that is already stored in the package. The stored states would have access to all primitive and texture parameters for content in the package, so moving objects around would be much quicker and smoother than going through a long chain of SetPrimitiveParam / SetTexture / SetPos commands sent from the server. If the texture positions and prim movements are relatively linear between saved states, then the client could even have the option to tween betweeen states as if they were keyframes, permitting smooth animations without the jerking and stuttering of complex animated objects the way it works now. All components that need to be moved around, resized, retextured, etc, for each of these states are already in the client-side package, so knowing UUIDs of items in the package is not necessary. The package contents are all relative, with a single UUID needed for the package. It wouldn't even be necessary for primitives in a package to be part of a linkset, just so long as they're inside the normal 10x10x10 workspace around the center of the package. The package becomes just more of a special folder, like a tar-archive that SL understands as a general container for the objects inside, and which can be moved around independent of each other from one stored state to the next.. - Scalar Tardis / Dale Mahalko From dmahalko at gmail.com Wed Jun 11 01:34:00 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 11 01:34:02 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: Heh, sorry for these long rambling essays. This issue has been on my mind for a very long time. My main point is that a DRM-compatible asset storage method doesn't need to be a detriment to the virtual world at all. It could actually offer improvements over how the current system functions, providing new ways to efficiently control and animate objects without lots of server and network overhead like we normally have to deal with now. The tradeoff would be a slightly slower downloads before the packaged object can appear in-world, but with faster function and usability once downloaded since it permits massive, fast local caching. In addition to compressing the textures and audio in a package, the prims and other raw data in packages could be compressed before being sent to the client, to further improve download speed. These concepts of: - object packagaing and package compression - hiding of UUIDs and using relative references to objects in a package - stored package states, animation, and tweening All could be implemented under the current system, but there wouldn't be a thorough way to protect the assets held inside these packages with the current lack of 3D DRM. But at least the base functionality could be used and developed until such time that 3D cards with DRM start to become available. When the DRM switchover woud start to occur, users may not necessarily notice much difference except that the asset packages are now not so easy to hack and extract due to the phased-in asset encryption. - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Wed Jun 11 02:04:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 11 02:04:58 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: <484F9537.7000309@gmail.com> Dale Mahalko wrote: > Heh, sorry for these long rambling essays. This issue has been on my > mind for a very long time. > > > My main point is that a DRM-compatible asset storage method doesn't > need to be a detriment to the virtual world at all. > Except that DRM does not work, at all. That you seem to think it does shows a fundamental misunderstanding of the way cryptography works. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080611/52c5638d/smime.bin From danteferret at gmail.com Wed Jun 11 02:21:09 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Jun 11 02:21:10 2008 Subject: [sldev] spam Message-ID: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> Has anyone been getting spam emails through [sldev-commits] lately? I was to stupid to look if it actualy came through the list or just had the tag before deleting them. If it did NOT come through the list itself I would be more concerned, becuase that would mean spammers are somehow getting our email addresses from the list. The spam was standard make your penis bigger type. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/d4536432/attachment.htm From robin.cornelius at gmail.com Wed Jun 11 02:33:40 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 11 02:33:38 2008 Subject: [sldev] spam In-Reply-To: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> Message-ID: <484F9BF4.6030000@gmail.com> Dante Tucker wrote: > Has anyone been getting spam emails through [sldev-commits] lately? I > was to stupid to look if it actualy came through the list or just had > the tag before deleting them. > > If it did NOT come through the list itself I would be more concerned, > becuase that would mean spammers are somehow getting our email addresses > from the list. > None made it to me but i've got one caught up in my anti spam system. This list posting settings may need a tweak, or if its a subscribed user they need un-subscribing. I think default mailman settings allow posts my non members which is a very bad move in many cases. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080611/be04512d/signature.pgp From secret.argent at gmail.com Wed Jun 11 04:15:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 11 04:14:32 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484F7F58.8040004@gmail.com> References: <484EA60A.4050909@gmail.com> <484F7F58.8040004@gmail.com> Message-ID: <71D396C2-7BE6-4C21-8E94-8E94DEED751A@gmail.com> On 2008-06-11, at 02:31, Tateru Nino wrote: > Actually it isn't all that long ago that about half of internet > domain names were that way around (while the other half were the > other way). The backwards domain names were on the UK academic network JANET. The Internet Domain Name System never used names like that, and JANET used all kinds of hacks to try and handle things either way. They broke down when they ran into the conflict between Computer Science departments and the "cs" top level domain... should it reverse "cs.uni.edu" or not? From alexander.treptow at zweitgeist.com Wed Jun 11 04:26:16 2008 From: alexander.treptow at zweitgeist.com (alexander.treptow) Date: Wed Jun 11 04:26:36 2008 Subject: [sldev] New graphics card with old Viewer Message-ID: <484FB658.4090006@zweitgeist.com> I think i got a big problem. I have a viewer (version 1.18.1.2) that got some changes by me. Now i got a new graphics card: gforce 8500gt The current version of the viewer runs on it without any problems but with my older edited viewer i m not able to start SL. My changed viewer says that i need a newer driver, but its the newest i've found. Is there any way to add graphic card support on the older version or to update it easily to a newer one without doing all the stuff i changed a second time? Thanks for help, alex From tom at streamsense.net Wed Jun 11 05:04:04 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Jun 11 05:04:11 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: <484F9537.7000309@gmail.com> References: <484F9537.7000309@gmail.com> Message-ID: <484FBF34.4050508@streamsense.net> Jason Giglio wrote: > > Except that DRM does not work, at all. That you seem to think it does > shows a fundamental misunderstanding of the way cryptography works. > > -Jason > Agreed. Plus you only have to look at the way HDCP has been adopted by the hardware manufacturers and general public (read: not at all unless you buy Sony hardware) to know that nobody wants this crap in their hardware. I've said it before, and i'll say it again, your content has already been stolen. Time to innovate and adapt. ~Tom From carjay at gmx.net Wed Jun 11 05:13:38 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Jun 11 05:13:23 2008 Subject: [sldev] New graphics card with old Viewer In-Reply-To: <484FB658.4090006@zweitgeist.com> References: <484FB658.4090006@zweitgeist.com> Message-ID: <484FC172.7020107@gmx.net> Hello Alexander, > > The current version of the viewer runs on it without any problems but > with my older edited viewer i m not able to start SL. > My changed viewer says that i need a newer driver, but its the newest > i've found. It's a bit mysterious like this, did you investigate in the sources how and why the message appears? Did the log give some ideas? Regards, Carsten From tongb at ohio.edu Wed Jun 11 05:49:45 2008 From: tongb at ohio.edu (Bruce Tong) Date: Wed Jun 11 05:49:50 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> Message-ID: <4f335a50806110549g172b513auf6470c9300f0eda6@mail.gmail.com> 1. There's plenty of incentive to make data transfers efficient even without the notion of data transfer caps by ISPs. We all suffer network lag, plus it all translates into capacity costs and queuing at LL's end too. It's not a matter of "if", but of "how." 2. I agree with those who desire a modest attempt at "protecting" user assets that might get cached. I don't think the bar has to be set so high as to make it an extensive amount of processing. Discussion: If I find a .JPG sitting on my computer, I have no problems with personal use. If I have to write some code or find a tool to decode it (even if decoding it was trivial) then it tugs on my conscience. That may not be rational, but that's how I feel. Maybe it's the idea of sitting in court and testifying "yes, I wrote software to decode the image" or "yes, I downloaded some software to decode the image" versus "I just found it on my computer ready to use." Besides, if they're really JPGs, won't some OS's waste time making cute little thumbnails? :) Wilton Lundquist -- Bruce Tong Software Engineer Office of Information Technology Ohio University From alexander.treptow at zweitgeist.com Wed Jun 11 08:14:10 2008 From: alexander.treptow at zweitgeist.com (alexander.treptow) Date: Wed Jun 11 08:14:29 2008 Subject: [sldev] New graphics card with old Viewer References: 484FB658.4090006@zweitgeist.com Message-ID: <484FEBC2.2060306@zweitgeist.com> //------------------------ > The current version of the viewer runs on it without any problems but > with my older edited viewer i m not able to start SL. > My changed viewer says that i need a newer driver, but its the newest > i've found. It's a bit mysterious like this, did you investigate in the sources how and why the message appears? Did the log give some ideas? //------------------------ Yes i changed the sources what messages send and what appears, cause i only wanted to view my avatar and animate it without seeing anything else in the place. In the log i've found nothing :/ greets From darien_caldwell at comcast.net Wed Jun 11 10:55:54 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Wed Jun 11 10:55:59 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <061120081755.14074.485011AA000933BB000036FA221558639404040A990B040E0CA1020A079D0E0B@comcast.net> On a related note, I would like to ask Linden Lab, if a better cache system was developed by someone for inclusion in the viewer, what is the likelihood that such a patch would be accepted? Is LL willing to do any/some/all of the things suggested or is all this discussion for naught? Are there any hard requirements to make a new cache system acceptable for the production viewer, or any things which would absolutely preclude a particular cache system from being accpeted? From gwardell at gwsystemsdns.net Wed Jun 11 11:43:17 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Wed Jun 11 11:43:25 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4f335a50806110549g172b513auf6470c9300f0eda6@mail.gmail.com> Message-ID: <013b01c8cbf3$03bb7f10$a400000a@gwsystems2.com> > > Besides, if they're really JPGs, won't some OS's waste time making > cute little thumbnails? :) > Not if you use an extension other than .jpg (I just checked) Besides, that only happens if you view the directory with Windows Explorer. It should have no effect on the OpenFile api. Gary From robla at lindenlab.com Wed Jun 11 13:47:56 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jun 11 13:47:59 2008 Subject: [sldev] spam In-Reply-To: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> Message-ID: <485039FC.6080306@lindenlab.com> On 6/11/08 2:21 AM, Dante Tucker wrote: > Has anyone been getting spam emails through [sldev-commits] lately? I > was to stupid to look if it actualy came through the list or just had > the tag before deleting them. > > If it did NOT come through the list itself I would be more concerned, > becuase that would mean spammers are somehow getting our email > addresses from the list. Sorry, looks like I had probably misconfigured the list when I was debugging an earlier problem. I've fixed the configuration, and with any luck, any emails that aren't from ^.*@svn.secondlife.com will be bounced. Rob From lenglish5 at cox.net Wed Jun 11 14:00:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jun 11 14:00:16 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change Message-ID: <48503CDE.9060007@cox.net> Yesterday, I submitted this jira for a new permissions feature, which launched a firestorm of discussion, some of which showed that many people had either not read, or at least, had not understood what I was proposing. http://jira.secondlife.com/browse/MISC-1272 I submitted it yesterday because of last week's demo of the test-code that Zha Ewry IBM wrote for OpenSim to implement the new Open Grid Protocol login, which allowed Zha and Tess LInden and Layla Linden to log into the Linden Lab Aditi test grid via the prototype Agent Domain server and end up on a private IBM-hosted OpenSim using the code written by Zha. This, as I've called it, is the "dawn of the new virtual world internet," which is, IMHO, pretty darned groundbreaking. http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ Historical issues aside, it points out the fact that the new inter-grid will soon be upon us and that we need to start serious discussion of what asset sharing (or non-sharing) will be like on the new VW Internet. However, LL's public discussion, letalone implementation, of asset permissions is way behind reality and falling further behind as we speak. Already, copying systems are available that allow people to copy full permissions content from Second Life to some arbitrary OpenSim. On my part, I assumed that this was perfectly OK, but Lillie Yifu, in AWGroupies IM, pointed out that owners of a copyright generally don't give up all rights for their intellectual property to be distributed via new venues and methods, just because that venue/method didn't exist when they made their original agreement. Therefore, strictly speaking, even the copying of full permissions items to another virtual world like an OpenSim, without explicit permission, is a violation of copyright law. The following jira tries to address the issue in the most conservative, uncontroversial way, by making explicit the legal situation that [I believe] already exists with the current TOS concerning trans-grid copying. IOW, as per Lillie Yiful's suggestion, a new permission system has to be implemented as soon as possible that applies one of the following three options to each existing set of permission flags: Creation Grid Only [name of grid goes here] /Trusted Grid [not currently defined, may end up being an explicit list or pointers to one or more lists or names, such as "name: Trusted Linden Grid Network" or "name: avatar-name's garage GRID-ID: blahblah" /any grid. The default for this new, emergency system, must be "Creation Grid Only" and all new content and all existing content gets this permission applied automatically. In other words, NOTHING can leave Second Life without the explicit permission of the content creator. NOTHING. The fact that many builds and items might be open permissions and the creator is no longer involved in Second Life doesn't change the legal reality: they haven't given permission for their content to leave the SL grid and therefore it must remain in Second Life until they log back into their account and say differently. I flagged the jira as "critical" because I believe that it is. I said it had to be done immediately because, it really should have been done months ago in order to prepare content creators for the reality of the new meta-grid. A further provision of this new flag system should be to allow the ability of all content creators to bulk change the grid permission flags of every existing content that they have created, once per item. If they slip up and open permissions on something they didn't mean to, oh well. It may be impossible for LL to implement this feature, but I'm certain that if it is possible, it will create havok to let it be used more than once per item. Obviously many details have to be worked out about what nested items with differing flags mean, etc., but that should have been discussed and vetted and tested months and months ago. The fact that we have a window of a few months before cross-grid TP goes live doesn't give us months of time to discuss these issues. The truly public discussion needed to start within weeks of the first AWG meeting last year and it didn't. Now, programmers acting in good faith, have written products and sold them that violate the existing TOS and copyright law, and it is no longer a simple "SHOULD" but a "MUST" to have these discussions and implement at least a minimal grid-permissions system. as soon as possible. Two months ago would have been about right. http://jira.secondlife.com/browse/MISC-1272 Create a set of permissions flags immediately that identifies "creation grid only [grid name]"/"trusted gird"/"any grid" to apply to all existing permissions settings with "creation [grid name] grid as the default setting With the demonstration last week of logging into a private OpenSim from Second Life, the permissions issues of a "meta grid" are now real and have to be addressed immediately by Linden Lab. The simplest case will be to assume that a content creator did NOT intend for his or her creation to leave the Second Life grid, and the permissions system must reflect this for all existing and future content. If the creator does not set the permission explicitly, the setting is "Creation Grid Only [grid name]" In other words, all existing and new content created in Second LIfe must now be flagged "Creation Grid Only [Second LIfe Grid]", until the creator explicitly changes the flag. References: http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ https://wiki.secondlife.com/wiki/AWGroupies-2008-06-10 10 June 2008 Zero LInden Office hour chat log From thordain at thordain.com Wed Jun 11 14:09:28 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jun 11 14:09:30 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <21BEBD9B86734E078439593E44517237@a644000> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> Message-ID: > > Argent wins the thread. Most are either completely downplaying any sort of > deterrent to theft and actually encouraging it, while the other side is > proposing ridiculously complex encryption specifications which would > severely harm the ability of SL to function. > > Argent's proposal is balanced enough to make everyone happy. Sure, anyone > with can get past a "Hello World" program will be able to break it. But the > point is, 90% of SL users can't get that far. So as a deterrent, it will > prevent casual misappropriation of restricted materials. On the other end, > it won't severely hamper anyone from doing whatever 'ubercool' stuff they > want to do. Agreed. Using a slightly obfuscated raw texture format for cache will prevent the usage of the cache files in any image editor (as written to disk), and should speed up decoding in the client. As an additional measure, LL could consider changing the XOR key with every major release and clearing the cache (many versions do anyways). At least this would force all the pirates to re-download their "decoder software" every month or so. I do have to agree with Strife that the amount of benefit for such a large overhaul might be minimal. There are clearly more important things that LL wants to be working on. As it is written, the cache system works. The same thing cannot be said of other portions of the platform, and I think they are trying to divert the majority of their resources to these other critical issues. As far as the proposal for implementing asymmetric encryption for assets... It's a moot point until a major graphics chipset vendors starts working with it. Even if Linden Labs were to convince NVidia to create such functionality, it would likely be years before it appeared on the market, and nearly a decade before LL could say "OK....we're turning off support for non-secure cards". Not to mention the asset server would have to custom encrypt every single texture request with the client's graphics card's public key. This would increase the asset server's work load by an order of magnitude, and last time I checked ..... we don't want that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/27699903/attachment.htm From danteferret at gmail.com Wed Jun 11 14:53:14 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Jun 11 14:53:24 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> Message-ID: <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> The only problem with changing the key every release is a lot of people don't use the latest version. Then theres people like myself that use there own custom build. On Wed, Jun 11, 2008 at 5:09 PM, Thordain Curtis wrote: > Argent wins the thread. Most are either completely downplaying any sort of >> deterrent to theft and actually encouraging it, while the other side is >> proposing ridiculously complex encryption specifications which would >> severely harm the ability of SL to function. >> >> Argent's proposal is balanced enough to make everyone happy. Sure, anyone >> with can get past a "Hello World" program will be able to break it. But the >> point is, 90% of SL users can't get that far. So as a deterrent, it will >> prevent casual misappropriation of restricted materials. On the other end, >> it won't severely hamper anyone from doing whatever 'ubercool' stuff they >> want to do. > > > Agreed. Using a slightly obfuscated raw texture format for cache will > prevent the usage of the cache files in any image editor (as written to > disk), and should speed up decoding in the client. As an additional > measure, LL could consider changing the XOR key with every major release and > clearing the cache (many versions do anyways). At least this would force > all the pirates to re-download their "decoder software" every month or so. > > I do have to agree with Strife that the amount of benefit for such a large > overhaul might be minimal. There are clearly more important things that LL > wants to be working on. As it is written, the cache system works. The same > thing cannot be said of other portions of the platform, and I think they are > trying to divert the majority of their resources to these other critical > issues. > > As far as the proposal for implementing asymmetric encryption for > assets... It's a moot point until a major graphics chipset vendors starts > working with it. Even if Linden Labs were to convince NVidia to create such > functionality, it would likely be years before it appeared on the market, > and nearly a decade before LL could say "OK....we're turning off support for > non-secure cards". Not to mention the asset server would have to custom > encrypt every single texture request with the client's graphics card's > public key. This would increase the asset server's work load by an order of > magnitude, and last time I checked ..... we don't want that. > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/c03b3858/attachment.htm From thordain at thordain.com Wed Jun 11 15:39:12 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jun 11 15:39:19 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> Message-ID: On Wed, Jun 11, 2008 at 5:53 PM, Dante Tucker wrote: > The only problem with changing the key every release is a lot of people > don't use the latest version. Then theres people like myself that use there > own custom build. > > The system for downloading assets (using an un-obfuscated JPEG2000 format) would remain unchanged. The asset would be XOR "encrypted" on the client end before being stored in cache on disk. This would have no effect on custom builds or old versions. If you continued to use a viewer six months after it's release, your machine's cache would continue to use the same key. If you used a custom build, ditto. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/5f109f84/attachment-0001.htm From jayden.beresford at gmail.com Wed Jun 11 16:22:11 2008 From: jayden.beresford at gmail.com (Sean Heying) Date: Wed Jun 11 16:22:40 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> >> >> Besides, if they're really JPGs, won't some OS's waste time making >> cute little thumbnails? :) >> > Not if you use an extension other than .jpg > (I just checked) > Besides, that only happens if you view the directory with Windows Explorer. It should have no effect > on the OpenFile api. > Gary You have assumed Windows ;) OS X and Linux do not care what the extension is. They create pretty little thumbnails based on the header of the file. From jayden.beresford at gmail.com Wed Jun 11 16:22:11 2008 From: jayden.beresford at gmail.com (Sean Heying) Date: Wed Jun 11 16:22:50 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> >> >> Besides, if they're really JPGs, won't some OS's waste time making >> cute little thumbnails? :) >> > Not if you use an extension other than .jpg > (I just checked) > Besides, that only happens if you view the directory with Windows Explorer. It should have no effect > on the OpenFile api. > Gary You have assumed Windows ;) OS X and Linux do not care what the extension is. They create pretty little thumbnails based on the header of the file. From me at signpostmarv.name Wed Jun 11 16:51:14 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Jun 11 16:51:20 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> Message-ID: <485064F2.4030409@signpostmarv.name> Why not get the key via caps ? Then the key can be changed on the fly, perhaps even during the same session. ~ Marv. Dante Tucker wrote: > The only problem with changing the key every release is a lot of > people don't use the latest version. Then theres people like myself > that use there own custom build. > > On Wed, Jun 11, 2008 at 5:09 PM, Thordain Curtis > > wrote: > > Argent wins the thread. Most are either completely downplaying > any sort of deterrent to theft and actually encouraging it, > while the other side is proposing ridiculously complex > encryption specifications which would severely harm the > ability of SL to function. > > Argent's proposal is balanced enough to make everyone happy. > Sure, anyone with can get past a "Hello World" program will be > able to break it. But the point is, 90% of SL users can't get > that far. So as a deterrent, it will prevent casual > misappropriation of restricted materials. On the other end, > it won't severely hamper anyone from doing whatever 'ubercool' > stuff they want to do. > > > Agreed. Using a slightly obfuscated raw texture format for cache > will prevent the usage of the cache files in any image editor (as > written to disk), and should speed up decoding in the client. As > an additional measure, LL could consider changing the XOR key with > every major release and clearing the cache (many versions do > anyways). At least this would force all the pirates to > re-download their "decoder software" every month or so. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/dfd88cb8/smime.bin From tateru.nino at gmail.com Wed Jun 11 21:25:33 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 11 21:26:25 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> References: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> Message-ID: <4850A53D.4060901@weblogsinc.com> Sean Heying wrote: >>> Besides, if they're really JPGs, won't some OS's waste time making >>> cute little thumbnails? :) >>> >>> > > >> Not if you use an extension other than .jpg >> (I just checked) >> > > >> Besides, that only happens if you view the directory with Windows Explorer. It should have no effect >> on the OpenFile api. >> > > >> Gary >> > > You have assumed Windows ;) OS X and Linux do not care what the > extension is. They create pretty little thumbnails based on the header > of the file. But as raw image data, there *is* no header for the OS to detect. -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jun 11 21:27:05 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 11 21:27:57 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <485064F2.4030409@signpostmarv.name> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> <485064F2.4030409@signpostmarv.name> Message-ID: <4850A599.6080408@weblogsinc.com> Every encoded asset would have to be recoded. You'd also need to then mark which assets had been recoded and which had not. "On the fly" in this case would mean "Stop and rewrite hundreds of megabytes of data before continuing" SignpostMarv Martin wrote: > Why not get the key via caps ? Then the key can be changed on the fly, > perhaps even during the same session. > > ~ Marv. > > Dante Tucker wrote: >> The only problem with changing the key every release is a lot of >> people don't use the latest version. Then theres people like myself >> that use there own custom build. >> >> On Wed, Jun 11, 2008 at 5:09 PM, Thordain Curtis >> > wrote: >> >> Argent wins the thread. Most are either completely downplaying >> any sort of deterrent to theft and actually encouraging it, >> while the other side is proposing ridiculously complex >> encryption specifications which would severely harm the >> ability of SL to function. >> >> Argent's proposal is balanced enough to make everyone happy. >> Sure, anyone with can get past a "Hello World" program will be >> able to break it. But the point is, 90% of SL users can't get >> that far. So as a deterrent, it will prevent casual >> misappropriation of restricted materials. On the other end, >> it won't severely hamper anyone from doing whatever 'ubercool' >> stuff they want to do. >> >> >> Agreed. Using a slightly obfuscated raw texture format for cache >> will prevent the usage of the cache files in any image editor (as >> written to disk), and should speed up decoding in the client. As >> an additional measure, LL could consider changing the XOR key with >> every major release and clearing the cache (many versions do >> anyways). At least this would force all the pirates to >> re-download their "decoder software" every month or so. >> > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From thordain at thordain.com Wed Jun 11 21:40:36 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jun 11 21:40:39 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4850A599.6080408@weblogsinc.com> References: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> <485064F2.4030409@signpostmarv.name> <4850A599.6080408@weblogsinc.com> Message-ID: On Thu, Jun 12, 2008 at 12:27 AM, Tateru Nino wrote: > Every encoded asset would have to be recoded. You'd also need to then mark > which assets had been recoded and which had not. "On the fly" in this case > would mean "Stop and rewrite hundreds of megabytes of data before > continuing" > > SignpostMarv Martin wrote: > >> Why not get the key via caps ? Then the key can be changed on the fly, >> perhaps even during the same session. >> >> Ya... using the method described in preceding messages, changing the key on the fly would be a terrible idea. Once the cache is cleared you'll want to maintain the same key until (at the very least) a new client is installed or the user manually clears the cache. I suppose a new key could be generated each time a client is installed (or the user clears the cache), but then this key would have to be stored somewhere, which adds little to no extra security over using a globally used key per major client revision. Remember, this type of "protection" is designed to stop only casual attempts at asset piracy. By storing the assets in a non-standard format and obfuscating their contents you are ensuring that a person can't just browse the directory and throw a file into Gimp or Photoshop. Doing much more than this is like adding 4 extra deadbolts to your front door. You might stop some trivial thug from kicking in your door and nabbing your laptop real quick, but for a skilled thief it'll just take them a bit longer to pick them all (or go in through your window). In the end, the idea here is to speed up cache retrieval and image decoding, while at the same time continuing to offer some measure of deterrence against would-be thieves -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/2e4fcc05/attachment-0001.htm From jayden.beresford at gmail.com Wed Jun 11 21:58:07 2008 From: jayden.beresford at gmail.com (Sean Heying) Date: Wed Jun 11 21:58:10 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4850A53D.4060901@weblogsinc.com> References: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> <4850A53D.4060901@weblogsinc.com> Message-ID: <5756afe60806112158j58ae1c03qd6e873f9d56e155d@mail.gmail.com> And raw images as well as being faster add yet another veneer/illusion of security for the casual ripper. My vote goes to store the images that way. In terms of the ongoing side-conversation on quota (which is the term we use in Australia for monthly metered data Allowance)... It will not kill SL despite what gloom and doom the naysayers are prophesising. My own use over the last 18 months has been about 50% of my quota. For my first 2 months I hit the cap and was forced onto 64kbit speeds... I then learnt not to download bit torrent files and wast my quota. A more efficient cache will help, but likewise, reducing your draw to 96M from 512M until the cache is made bigger/faster/better means you are pulling in a fraction of the textures and objects. Sean. On Thu, Jun 12, 2008 at 2:25 PM, Tateru Nino wrote: > > > Sean Heying wrote: >>>> >>>> Besides, if they're really JPGs, won't some OS's waste time making >>>> cute little thumbnails? :) >>>> >>>> >> >> >>> >>> Not if you use an extension other than .jpg >>> (I just checked) >>> >> >> >>> >>> Besides, that only happens if you view the directory with Windows >>> Explorer. It should have no effect >>> on the OpenFile api. >>> >> >> >>> >>> Gary >>> >> >> You have assumed Windows ;) OS X and Linux do not care what the >> extension is. They create pretty little thumbnails based on the header >> of the file. > > But as raw image data, there *is* no header for the OS to detect. > > -- > Tateru Nino > http://www.massively.com/ > > From gigstaggart at gmail.com Wed Jun 11 22:59:14 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 11 22:59:19 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change In-Reply-To: <48503CDE.9060007@cox.net> References: <48503CDE.9060007@cox.net> Message-ID: <4850BB32.20201@gmail.com> Lawson English wrote: > http://jira.secondlife.com/browse/MISC-1272 I believe everything you want is already addressed in RFC3514. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/386c8ed7/smime.bin From lenglish5 at cox.net Wed Jun 11 23:00:33 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jun 11 23:00:36 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change In-Reply-To: <4850BB32.20201@gmail.com> References: <48503CDE.9060007@cox.net> <4850BB32.20201@gmail.com> Message-ID: <4850BB81.5010502@cox.net> Jason Giglio wrote: > Lawson English wrote: > >> http://jira.secondlife.com/browse/MISC-1272 >> > > I believe everything you want is already addressed in RFC3514. > > -Jason > Jira has a RFC category now? Lawson From dmahalko at gmail.com Thu Jun 12 01:57:53 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu Jun 12 01:57:55 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> Message-ID: On Wed, Jun 11, 2008 at 4:09 PM, Thordain Curtis wrote: > As far as the proposal for implementing asymmetric encryption for assets... > It's a moot point until a major graphics chipset vendors starts working with > it. Even if Linden Labs were to convince NVidia to create such > functionality, it would likely be years before it appeared on the market, > and nearly a decade before LL could say "OK....we're turning off support for > non-secure cards". This market segment is in its infancy and there is still time for technologies to develop. At one time people wondered if specialized 3D cards would have any market at all, and now they are practically essential. In terms of deployment time, the big market players are able to bide their time, for years if necessary, for their DRM to get out into the marketplace. Did you know those SD memory cards contain a DRM content management system? SD doesn't mean "SanDisk".. it means "Secure Digital", but their DRM is not being used for anything yet, and probably will stay dormant until SD becomes the de-facto memory card standard. We seem to be moving in that direction, with SD winning out over most other formats. > Not to mention the asset server would have to custom > encrypt every single texture request with the client's graphics card's > public key. This would increase the asset server's work load by an order of > magnitude, and last time I checked ..... we don't want that. Heh that is not how most DRM works. Distributed media using mass-market DRM has all the same encoding, so the devices share the same private keys and all use the same public keys. So there's no need to encode data to match just one 3D card. The data would be encoded once and work across all 3D cards using the same public keys. Having a different public/private key for each DRM device? That is possible but would require the stream be specifically encoded to match that device, and as you say it would be several orders of magnitude more work for the asset servers. I am only talking about the first type, where the data would be encrypted once and sent to all users in the same pre-encrypted state. - Scalar Tardis / Dale Mahalko From chris.collins at uc.edu Thu Jun 12 01:58:43 2008 From: chris.collins at uc.edu (Chris Collins) Date: Thu Jun 12 01:58:54 2008 Subject: [sldev] SLEDcc 2008 Update and CFP Extension Message-ID: <200806120858.EHC23821@mprelay3.uc.edu> Hi all, Thought this may be of interest to those of you involved in the development community. In particular, the "Products & Tools" strand and "The Sleddies" awards competition might be relevant to your work if your project addresses particular needs of the educational community or is being used in teaching and learning on the grid. Thanks! - Chris/Fleep >Date: Wed, 11 Jun 2008 20:00:30 -0400 >To: educators@lists.secondlife.com >From: Chris Collins >Subject: SLEDcc 2008 Update and CFP Extension > > >Hi all, > >With apologies for cross-posting.. The Second >Life Education Community Conference 2008 >planning team has been hard at work and we have >several important updates for you: > >The main SLEDcc 2008 website is now available at >http://sledcc.wikispaces.com. This will be your >one-stop-shop for important information about >the SLEDcc conference, in Tampa or in Second >Life. Please note: SLEDcc is part of the >official Second Life Community Convention ( >http://slconvention.org). Registration fees >cover both the SLEDcc and SLCC >events! Conference registration and fees only >apply to those going to SLEDcc/SLCC in Tampa, >in-world only participants do not need to register or pay any fees. > >The Call for Proposals deadline has been >extended to June 17, 2008. See the CFP below or >view the complete details on the website. Don't >want to do a big paper presentation? No >problem! The SLED Sparks and Speed Mentoring >formats are designed for rapid information >sharing. Can't go to Tampa? No >problem! SLEDcc will have presentations in >Second Life as well as real life. You'd really >rather show off a great build or project than do >a presentation? No problem! "The Sleddies" >award competition might be just the thing for >you. See the CFP below or the website for more details. > >There are many low overhead ways that you can >help with the conference, from putting a >link/logo to the SLEDcc website from your own >blog or webpage, to volunteering for a few hours >in Tampa or in Second Life - we can use your >help! See the Volunteer Opportunities page and >the SLEDcc Social Media page on the website to >find out how you can join the team. > > >In addition to these updates, the website also >has more information about "The Sleddies" Award >competition, sponsorship information, and much >more. Please take a few moments to have a look >around and if you have any feedback, let us know. > >Thanks for your continued support and we look >forward to seeing you in Tampa or in SL this September! > >Sincerely, > >Chris Collins (SL: Fleep Tuque) >Hilary Mason (SL: Ann Enigma) >Jonathon Richter (SL: Wainbrave Bernal) > >Co-Chairs, Second Life Education Community Conference 2008 >Member of the Second Life Community Convention 2008 >September 5 - 7, 2008 in Tampa, FL and in Second Life >http://sledcc.wikispaces.com >sledcc08@googlegroups.com > > > > > >Call for Proposals - Second Life Education Community Conference 2008 >September 5 - 7, 2008 in Tampa, Florida and the virtual world of Second Life >http://sledcc.wikispaces.com > >The SLEDcc is a peer-reviewed academic >conference, with emphasis upon evidence-based >practices and scholarly work that leads to >innovation and the identification of best >practices for teaching and learning in the >Second Life virtual 3D environment. It is also >designed to maximize the opportunities afforded >by the Second Life medium itself ? and the >advantages of meeting face-to-face for an >exchange that cannot (yet) be recreated in the digital milieu. > >Whether you wish to participate at SLEDcc in >Tampa, Florida or in the virtual world of Second >Life ? please consider presenting and participating at SLEDcc 2008! > >Sections of the CFP: > >Select a Conference Strand >Select a Session Format >How to Submit a Proposal >Resources for Attendees of your Session >Dates to Remember > > >Select a Conference Strand > >SLEDcc invites proposals that will address the >following themes, or ?strands? (please select >one). The examples following the Strand >Description are just a few ways your proposal >might explore the theme. NOTE: While your >project or presentation might fit within more >then one Strand Theme, please be judicious and >select the single, most appropriate. > >Games and Simulations (Red Strand): >as significant, particular ways to engage >learners within Second Life. This Strand will >showcase the array of useful and effective ways >that the SLED community engages users in game and/or simulation environments. > > * In what ways are SLED designers engaging > learners in games, role-plays, and simulations? > * What are the game development issues that > educators-as-designers should know in their > creation of engaging SLED materials? > * How do designers, educators, scripters, > and builders collaborate most effectively to > create a ?killer educational game? in Second Life? > > >Mixed Reality Learning (Orange Strand): >as ways to bridge the so-called ?real world? and >the interface of a multi-user virtual >environment as powerful as Second Life. This >Strand will demonstrate the variety of ways that >education in SL can be powerfully connected to >things happening in RL ? as well as ways that >other media can add value to the SLED experience. > > * What approaches to Mixed-Reality Learning > work best? What are the obstacles to overcome? > What are some innovative ways to bring SL into the Real World? > * What skills in the real world can be > modeled in Second Life that might transfer > best? What are some difficult areas for such transfer? > * How do educators use multiple media types > to best channel and enhance value to the Second Life experience? > > >Theory, Research, & Practice (Yellow Strand): >as evidence-based practices to engage users of >Second Life in creating intended learning >outcomes, whether in formal or informal >settings. Theoretical Frameworks from a variety >of perspectives will be entertained in this >Strand of SLEDcc ? with emphasis on practical and scholarly application. > > * What does a successful Design-Based > Research experiment in Second Life look like? > Other qualitative or quantitative frameworks > that work well (or not) in Second Life? > * How do researchers adequately frame > educational work in Second Life to gather data > relevant to particular kinds of learning outcomes? > * What meta-analyses of the literature on > Multi-User Virtual Environments should every educator in Second Life know? > > >Differentiated Learning: International, Diverse, >and Special Populations (Green Strand): >as celebrating the many nationalities, cultures, >ways of knowing, and educational efforts >specific to particular kinds of learners in Second Life. > > * What are we learning in Second Life in > Japan? Brazil? Europe? Australia? > * How do we effectively teach students in > Second Life who do not speak our primary language? > * How do SLED designers create learning > experiences for people of many backgrounds and skill levels? > * What innovative approaches are emerging > to engage exceptional students (e.g. learning > disabilities and/or gifted education) in Second Life learning? > > >Projects and Events (Blue Strand): >as a milieu for teaching and learning, SLEDcc >showcases an amazing breadth of specific >projects and events that educators are creating. > > * By examining a cross-section of SLED > Projects, provide the audience with a ?best > practices? overview and assessment for engaging learners in SL. > * Provide an in-depth look at a particular > SLED Project created by your group or > organization and highlight the ?lessons learned?, challenges, and ?next steps?. > * What is the ?magic formula? for creating > an engaging, successful SLED event? > > >Educational Tools and Products (Purple Strand): >with the vast array of tools and products for >free or for sale in Second Life, SLEDcc can help >develop capacity for the newcomer and the >experienced practitioner alike to make informed choices. > > * Outline the technical specifications, > design process, and creation of a functional > SLED tool for the would-be designers and educational consumers in SL. > * Showcase a compare and contrast session, > looking at the variety of tools used for a > particular purpose and hold a discussion with the audience. > * Hold a workshop on a SLED tool or product > of your choice ? providing support and > specialized integration assistance as needed. > > > >Select a Session Format > >Whether you decide to present live in Tampa or >virtual in Second Life, you?ll have a chance to >participate with the attendees of each ? and >many sessions will be taped and available for viewing / download later. > >Workshop Format (Tampa or SL) >Get ?face-to-face and hands-on? instruction from >experts in Tampa or in Second Life! Workshops >will be held in a separate room at the Tampa >venue and participants will bring their own >laptops. Workshops will be either 90 minute or 3 >hour sessions (? day) and have a maximum of 25 participants. > > * Pre-conference workshops will be held on > September 4th. These workshops are specifically > for ?Newbies? to Second Life, to prepare them > for the SLEDcc! Newbie Specialists, please > propose something for this pre-conference day long event! > * We recommend at least two facilitators for each workshop. > * Facilitators need to provide all handouts > and related materials for attendees. > * Accepted workshop proposers will receive > 50% of all workshop fees beyond those recouped > for administrative purposes; the other 50% will > go toward a fund to provide token compensation > for the volunteer staff of SLEDcc. > > >SLED Sparks Format (Tampa or SL) >Present 20 slides in 2 minutes on a SLED topic of your choice. > >Speed Mentoring Format (Tampa or SL) >Teach skills in an informal, practical fashion - by roundtable. > >Paper Presentation Format (Tampa or SL) >Presentations supported by more rigorous findings. > >Special Second Life Only Format Options > > * The SLEDccademy Awards ? "The Sleddies > Competition?: Select a Strand Theme and develop > a SLED build or event in that category. > Submissions will be open for judging by the > Second Life education community who register to > participate in voting. (Note: Participants need > not register to attend SLEDcc in Tampa to vote > on submissions.) Winners will be announced at a > special ceremony at SLEDcc in Tampa. All > winning entries will be verified by an > Independent Review Board, verifying the popular > vote assessments prior to sponsored prize packages being distributed. > > * Poster Sessions - Create a display of > your SLED project, event, or institution for display in-world only. > > >Have other ideas for something creative in >Second Life? Email sledcc@gmail.com to begin a >dialogue with the planning committee. > > >How to Submit a Proposal > >Proposals should (SLED Sparks and Speed >Mentoring session proposals not included): > >1. Clearly state the problem or issue that your >proposal will address and to which Strand Theme it relates. >2. Indicate how your work has effectively addressed that problem or issue. >3. Indicate the outcomes participants should >expect from your session and examples of how you >will facilitate achievement of those outcomes. >4. Describe the strategies you will use to >engage participants in discussing, analyzing, >synthesizing, and applying the information you will share. >5. Describe how your work might be applied to a >particular or multiple sectors of education, >i.e. K-12, large universities, community >colleges, adult education, Second Life-specific, etc. >6. Include links to relevant Web sites or >electronic copies of the materials you will >share (electronic copies of materials can be provided later). > >Be aware that we will provide access to Tampa >and inworld SLEDcc participants to ask questions >and discuss how the work might be used to help >students achieve essential learning outcomes >(threaded discussions). We strongly encourage >all presenters to be active in the SLEDcc Group >on the RezEd website at http://www.rezed.org/group/sledcc2008. > >Submission Length & Format >The length and format of your proposal will be >determined by the Session Format you have selected: > > * Workshops: Please submit a brief abstract > (400-800 words), including a short statement of > the key lesson attendees will take away from the presentation. > * SLED Sparks: Please provide a brief > paragraph extolling your 2 minute lesson. > * Speed Mentoring: Please provide no more > than one page explaining your speed mentoring proposal. > * Paper Presentation: Please submit an > extended abstract of no more than 2000 words > (full papers will be due for selected proposals > due by August 22 at sledcc @ gmail.com for > inclusion in the SLEDcc Proceedings ? further > instruction to be notified by email). > * Inworld Poster Presentation: Please > submit a brief abstract (400-800 words), > including a short statement of the key lesson > attendees will take away from the presentation. > * The Sleddies Competition: Please refer to > the SLEDcc 2008 Website at > http://sledcc.wikispaces.com/ for more > information on guidelines, assessment rubrics > for each strand, and procedures for the Awards. > > >Sending the Proposal >In order to have your proposal considered, >please submit it by June 17th, 2008 to >sledcc@gmail.com using the following guidelines: > >Your proposal should be in MS Word format and >submitted via email. The file name should >include the name of the primary author followed >by .doc extension. If you are submitting >multiple proposals, please add a unique number >to each filename. e.g. my_name1.doc and >my_name2.doc. Include the author's name, title, >contact info, and short bio (use the 1st or >primary author?s name only in the filename) > >If you are submitting to present in Tampa, FL, >your email should use the subject line "Tampa SLEDcc 08". > >If you are submitting to present in Second Life, >your email should use the subject line "Inworld SLEDcc 08". > > >Deadline: All proposals to present at either the >SLEDcc in Tampa or inworld must be received by June 17th, 2008. > >Notification: You will receive a message >indicating receipt of your proposal when it is submitted. > >Acceptance: You will receive notification of the >status of your proposal by Monday, July 8, 2008. > >Registration Fees: All presenters and workshop >facilitators attending SLEDcc in Tampa, FL are >responsible for the appropriate conference >registration, fees, travel, and hotel expenses. >Please be sure all presenters added to your >proposal have this information and can be >available to present at anytime during the SLCC >in September 5 ? 7 (or Sept 4, if a pre-conference workshop is proposed). > > > >Resources for Attendees of Your Session >Conference attendees like to have resource >materials from sessions they attend ? whether >inworld or live in Tampa. While we encourage all >presenters in ANY format to post their materials >to the SLEDcc wiki at >http://sledcc.wikispaces.com/ we recommend, for >those proposing in Tampa, approximately 75 >printed handouts for conference-goers. > >Please remember that by submitting a proposal, >you agree to register for the appropriate venue >(inworld or live in Tampa) if the proposal is >accepted and inform your co-facilitators about >the proposals status and the need for all >presenters to pay respective conference fees if presenting live in Tampa. > > >Dates to Remember >June 17th : SLEDcc Proposals due by email to sledcc@gmail.com >July 8th: Submitters notified of status of proposals >August 1st: SLEDccademy Award entries open for voting >August 22nd: Accepted Paper Presentations >(Inworld and Live in Tampa, both) due by email, >5:00 p.m. SLT (Pacific Daylight Time). >September 4th: Newbie Pre-Conference workshop >September 5 ? 7: SLEDcc! > > >All accepted SLEDcc proposals will be notified >by July 8th. Presenters will be invited to add >their materials to the SLEDcc wiki at http://sledcc.wikispaces.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/fa80cb67/attachment-0001.htm From gigstaggart at gmail.com Thu Jun 12 02:18:28 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 12 02:18:34 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: <4850E9E4.50408@gmail.com> Argent Stonecutter wrote: > There is no optimization necessary, because there's no codec, and > miminal overhead: it's a straight copy and a tight "XOR" loop. Even > simple RLL encoding is more overhead. If we are going to use stupid and ineffective token measures to obfuscate, then we shouldn't waste time XORing the entire file. Pre-pending the NUL character, ASCII 0, onto the beginning of file will prevent it from being recognized as valid by pretty much everything. I tested it, it works. Nothing could open a jpg that I prepended ASCII 0 onto the beginning of. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/deb971ee/smime.bin From kirstenlee.cinquetti at googlemail.com Thu Jun 12 02:56:42 2008 From: kirstenlee.cinquetti at googlemail.com (Kirstenlee Cinquetti) Date: Thu Jun 12 02:56:45 2008 Subject: [sldev] Cmake - Vs2003 Message-ID: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> Just a quick question has anyone had any success building viewers with the new cmake setup on Vs2003 ? I have managed to build and run some very very badly borked viewers using the new system, but the wiki is horrendously poor and misleading information wise and the results im getting from the builds is unsatisfactory to say the least. Is the preferred system Vs2005 or 2008 now? Regards K -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/97653f15/attachment.htm From tateru.nino at gmail.com Thu Jun 12 03:34:46 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 12 03:35:35 2008 Subject: [sldev] Cmake - Vs2003 In-Reply-To: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> References: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> Message-ID: <4850FBC6.2030209@weblogsinc.com> No luck at all here with vs2003. Kirstenlee Cinquetti wrote: > Just a quick question has anyone had any success building viewers with > the new cmake setup on Vs2003 ? I have managed to build and run some > very very badly borked viewers using the new system, but the wiki is > horrendously poor and misleading information wise and the results im > getting from the builds is unsatisfactory to say the least. > Is the preferred system Vs2005 or 2008 now? Regards K > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From dmahalko at gmail.com Thu Jun 12 03:42:00 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu Jun 12 03:42:02 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4850E9E4.50408@gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> Message-ID: And how does Profoky Neva feel about this issue? Oh look, here's a blog post about this very sl-dev thread. It's too bad Profoky isn't interested in particupating directly, but here's a link so Profoky views can be included. Warning, strong language and high emotion. I think she is a little upset about this discussion, and in particular with Giglio's cavalier opinions about intellectual property. June 09, 2008: How They Talk About You: "I tire of people moaning about IP security" http://secondthoughts.typepad.com/second_thoughts/2008/06/how-they-talk-a.html - Scalar Tardis / Dale Mahalko From secret.argent at gmail.com Thu Jun 12 05:35:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 12 05:34:08 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> Message-ID: On 2008-06-11, at 16:09, Thordain Curtis wrote: > I do have to agree with Strife that the amount of benefit for such > a large overhaul might be minimal. There are clearly more > important things that LL wants to be working on. As it is written, > the cache system works. I don't agree. The current cache system barely works: it caches on the order of one percent of the content it needs to for anyone on a high latency or low bandwidth link, and it has a high enough overhead that for a low latency high bandwidth link just redownloading can be faster than the current cache... which is allegedly one reason it's limited to 1GB. From secret.argent at gmail.com Thu Jun 12 05:37:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 12 05:35:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> <4d211a610806111453w38413137q4f413cf282d03689@mail.gmail.com> Message-ID: <902676AF-5106-4428-B03C-6611E2231F6B@gmail.com> On 2008-06-11, at 16:53, Dante Tucker wrote: > The only problem with changing the key every release is a lot of > people don't use the latest version. Then theres people like myself > that use there own custom build. That won't have any impact... the obfuscation is handled by the client in this model. The key can even be randomly generated on install. From gigstaggart at gmail.com Thu Jun 12 05:35:24 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 12 05:35:40 2008 Subject: [sldev] Cmake - Vs2003 In-Reply-To: <4850FBC6.2030209@weblogsinc.com> References: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> <4850FBC6.2030209@weblogsinc.com> Message-ID: <4851180C.9090609@gmail.com> Tateru Nino wrote: >> getting from the builds is unsatisfactory to say the least. >> Is the preferred system Vs2005 or 2008 now? Regards K 2008 is failing on the compiled parts of boost the viewer uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/136f5120/smime-0001.bin From secret.argent at gmail.com Thu Jun 12 05:40:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 12 05:39:05 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <5756afe60806112158j58ae1c03qd6e873f9d56e155d@mail.gmail.com> References: <5756afe60806111622i36434285m5d3cc111f99db54b@mail.gmail.com> <4850A53D.4060901@weblogsinc.com> <5756afe60806112158j58ae1c03qd6e873f9d56e155d@mail.gmail.com> Message-ID: <81D1F370-990E-4757-B51F-EADA0E3A0C82@gmail.com> On 2008-06-11, at 23:58, Sean Heying wrote: > For my first 2 months I hit the cap and was forced onto 64kbit > speeds... I then learnt not to download bit torrent files and wast > my quota. That would be fine. The scheme proposed by the cable companies here is that when you hit the cap you don't even find out about it until you get a huge bill the next month. From zak.escher at gmail.com Thu Jun 12 05:40:44 2008 From: zak.escher at gmail.com (Zak Escher) Date: Thu Jun 12 05:40:57 2008 Subject: [sldev] Compiling SL client Message-ID: <4851194C.9000504@gmail.com> I have tried to compile the SL client using the version control repository and cmake. I have gotten different errors an three different machines. Last night, I was able to get farther through the process than I have before, but I still received the following error in VS2005. 1>------ Build started: Project: secondlife-bin, Configuration: Release Win32 ------ 1>Performing Pre-Build Event... 1>Opening solution: E:/Documents/sl_1_19_1_14/linden/indra/build-VC80/SecondLife.sln 1>Looking for existing VisualStudio instance... 1>Looking for project secondlife-bin... 1>Found project: secondlife-bin 1>Setting working directory 1>E:\Documents\sl_1_19_1_14\linden\indra\build-VC80\newview\secondlife-bin.vcproj 1>Finished! 1>Performing Pre-Link Event... 1>master: http://secondlife.com/app/message_template/master_message_template.msg 1>current: E:\Documents\sl_1_19_1_14\linden\scripts\messages\message_template.msg 1>--- PASS --- 1>Same 1> 1> 1>Linking... 1>LINK : fatal error LNK1181: cannot open input file 'fmodvc.lib' 1>Build log was saved at "file://e:\Documents\sl_1_19_1_14\linden\indra\build-VC80\newview\secondlife-bin.dir\Release\BuildLog.htm" 1>secondlife-bin - 1 error(s), 0 warning(s) 2>------ Skipped Build: Project: ALL_BUILD, Configuration: Release Win32 ------ 2>Project not selected to build for this solution configuration ========== Build: 0 succeeded, 1 failed, 23 up-to-date, 1 skipped ========== I have used the build instructions at http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) and I have the fmodvc.lib library in E:\Documents\sl_1_19_1_14\linden\libraries\i686-win32\lib_debug and E:\Documents\sl_1_19_1_14\linden\libraries\i686-win32\lib_release. I'm building on Windows Vista Ultimate (32-Bit) and am running Visual Studio as an administrator. Any help would be appreciated. From gigstaggart at gmail.com Thu Jun 12 05:43:38 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 12 05:43:42 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> Message-ID: <485119FA.6070109@gmail.com> Dale Mahalko wrote: > I think she is a little upset about this discussion, and in particular > with Giglio's cavalier opinions about intellectual property. Actually, I take copyright, trademarks, and patents very seriously. I was the driving force behind starting the LSL wiki over from scratch on wiki.secondlife.com, because the old wiki had uncertain copyright terms, and couldn't be mirrored without potentially infringing on copyright. I was also opposed to integrating vivox with the viewer, because it is difficult to distribute it without infringing on the patented codec. My cavalier attitude is toward people who are ignorant of the basic nature of computers... they copy data. You can't teach a bear to not be a bear, and you can't prevent a computer from copying data. That's a separate issue from the ethics of actually infringing on a copyright. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/a751656f/smime.bin From secret.argent at gmail.com Thu Jun 12 05:46:37 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 12 05:45:10 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <21BEBD9B86734E078439593E44517237@a644000> Message-ID: On 2008-06-12, at 03:57, Dale Mahalko wrote: > Did you know those SD memory cards contain a DRM content management > system? SD doesn't mean "SanDisk".. it means "Secure Digital", Which is why a lot of people stuck with MMC... the DRM made the first generation of SD cards slower and less reliable than MMC. > but their DRM is not being used for anything yet, Um, yes, it is. It's been used for encrypted distribution of software for Palm OS. Which was a total failure even though it was at the time the de-facto standard memory card for Palms. > and probably will stay > dormant until SD becomes the de-facto memory card standard. We seem to > be moving in that direction, with SD winning out over most other > formats. Actually, USB seems to be the winner. Have you read "Persistence" or "Rainbow's End"? From secret.argent at gmail.com Thu Jun 12 05:55:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 12 05:54:06 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4850E9E4.50408@gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> Message-ID: <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> On 2008-06-12, at 04:18, Jason Giglio wrote: > Pre-pending the NUL character, ASCII 0, onto the beginning of file > will > prevent it from being recognized as valid by pretty much everything. Um, Jason, I already proposed simply prepending the metadata to the file for that purpose. Yes, the additional XOR step is not much additional security. We all know that. Storing the data in internal format instead of a standard file format is a more important part... both for obscurity and for efficiency. The xor step is free, though, since it is just as fast as a simple block copy on any modern processor, and you need to do that copy anyway unless you're obsessively careful with alignment. > I tested it, it works. Nothing could open a jpg that I prepended > ASCII > 0 onto the beginning of. I think "dd bs=1 skip=1" is probably insufficiently obscure. From robin.cornelius at gmail.com Thu Jun 12 06:06:41 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 12 06:06:38 2008 Subject: [sldev] Cmake - Vs2003 In-Reply-To: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> References: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> Message-ID: <48511F61.6060604@gmail.com> Kirstenlee Cinquetti wrote: > Just a quick question has anyone had any success building viewers with > the new cmake setup on Vs2003 ? I have managed to build and run some > very very badly borked viewers using the new system, but the wiki is > horrendously poor and misleading information wise and the results im > getting from the builds is unsatisfactory to say the least. > Is the preferred system Vs2005 or 2008 now? Regards K > I have successfully build on VS2003.NET. As its the only non express version i have its the only one that can complete every build step with out an error. What actual problems are you having? If the viewer is built correctly then any brokennees is probbaly not cmake related at this stage but could well reflect the fact that this is the (post qa)development tip branch so can be broken at a given instance in time. Feel free to update the wiki as you go. There are only about 2 pages on cmake so far anyway and the documentation does need updating as we go. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/3b069947/signature.pgp From gigstaggart at gmail.com Thu Jun 12 06:15:58 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 12 06:16:04 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> Message-ID: <4851218E.6000802@gmail.com> Argent Stonecutter wrote: >> I tested it, it works. Nothing could open a jpg that I prepended >> ASCII >> 0 onto the beginning of. > > I think "dd bs=1 skip=1" is probably insufficiently obscure. That's inherently a slippery slope, you do realize that, right? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/f29608a6/smime-0001.bin From soft at lindenlab.com Thu Jun 12 06:26:28 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 12 06:26:32 2008 Subject: [sldev] Cmake - Vs2003 In-Reply-To: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> References: <6724a2330806120256l3f443eabu24784e2b59a7b32a@mail.gmail.com> Message-ID: On Thu, Jun 12, 2008 at 4:56 AM, Kirstenlee Cinquetti wrote: > Just a quick question has anyone had any success building viewers with the > new cmake setup on Vs2003 ? I have managed to build and run some very very > badly borked viewers using the new system, but the wiki is horrendously poor > and misleading information wise and the results im getting from the builds > is unsatisfactory to say the least. > Is the preferred system Vs2005 or 2008 now? Regards K My VS2003 cmake build completes, but dies rather obtusely at startup. We're having a discussion right now about whether we continue supporting VS2003, or whether it's VS2005 and VS2008 from here on out. This will be resolved before cmake hits a release candidate, of course. If you have any arguments for or against keeping VS2003 support, it would be helpful to hear them. There isn't any mature cmake documentation yet either. If anyone wants to take a swing at it, that would be great. This needs to happen before cmake hits an RC as well. From soft at lindenlab.com Thu Jun 12 06:30:32 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 12 06:30:43 2008 Subject: VS2005 + cmake - was Re: [sldev] Compiling SL client Message-ID: The location of the libraries has moved. For Windows, you need to copy fmod and Quicktime to slightly different locations: linden/libraries/i686-win32/lib_release -> linden/libraries/i686-win32/lib/release linden/libraries/i686-win32/lib_debug -> linden/libraries/i686-win32/lib/debug On Thu, Jun 12, 2008 at 7:40 AM, Zak Escher wrote: > I have tried to compile the SL client using the version control repository > and cmake. I have gotten different errors an three different machines. Last > night, I was able to get farther through the process than I have before, but > I still received the following error in VS2005. > > 1>------ Build started: Project: secondlife-bin, Configuration: Release > Win32 ------ > 1>Performing Pre-Build Event... > 1>Opening solution: > E:/Documents/sl_1_19_1_14/linden/indra/build-VC80/SecondLife.sln > 1>Looking for existing VisualStudio instance... > 1>Looking for project secondlife-bin... > 1>Found project: secondlife-bin > 1>Setting working directory > 1>E:\Documents\sl_1_19_1_14\linden\indra\build-VC80\newview\secondlife-bin.vcproj > 1>Finished! > 1>Performing Pre-Link Event... > 1>master: > http://secondlife.com/app/message_template/master_message_template.msg > 1>current: > E:\Documents\sl_1_19_1_14\linden\scripts\messages\message_template.msg > 1>--- PASS --- > 1>Same > 1> > 1> > 1>Linking... > 1>LINK : fatal error LNK1181: cannot open input file 'fmodvc.lib' > 1>Build log was saved at > "file://e:\Documents\sl_1_19_1_14\linden\indra\build-VC80\newview\secondlife-bin.dir\Release\BuildLog.htm" > 1>secondlife-bin - 1 error(s), 0 warning(s) > 2>------ Skipped Build: Project: ALL_BUILD, Configuration: Release Win32 > ------ > 2>Project not selected to build for this solution configuration > ========== Build: 0 succeeded, 1 failed, 23 up-to-date, 1 skipped ========== > > I have used the build instructions at > http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) and I have > the fmodvc.lib library in > E:\Documents\sl_1_19_1_14\linden\libraries\i686-win32\lib_debug and > E:\Documents\sl_1_19_1_14\linden\libraries\i686-win32\lib_release. I'm > building on Windows Vista Ultimate (32-Bit) and am running Visual Studio as > an administrator. > > Any help would be appreciated. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Thu Jun 12 06:35:07 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 12 06:35:06 2008 Subject: VS2005 + cmake - was Re: [sldev] Compiling SL client In-Reply-To: References: Message-ID: <4851260B.4060608@gmail.com> Soft wrote: > The location of the libraries has moved. For Windows, you need to copy > fmod and Quicktime to slightly different locations: > > linden/libraries/i686-win32/lib_release -> > linden/libraries/i686-win32/lib/release > linden/libraries/i686-win32/lib_debug -> linden/libraries/i686-win32/lib/debug > Should you be copying quicktime around at all? i though the cmake looked at the default install location of the quicktime API? fmod yes as its just a zip file for the api. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/9162f054/signature.pgp From sldev at catznip.com Thu Jun 12 12:12:30 2008 From: sldev at catznip.com (Kitty) Date: Thu Jun 12 12:09:38 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change In-Reply-To: <48503CDE.9060007@cox.net> References: <48503CDE.9060007@cox.net> Message-ID: > The default for this new, emergency system, must be "Creation > Grid Only" > and all new content and all existing content gets this > permission applied automatically. In other words, NOTHING can > leave Second Life without the explicit permission of the > content creator. NOTHING. The fact that many builds and items > might be open permissions and the creator is no longer > involved in Second Life doesn't change the legal > reality: they haven't given permission for their content to > leave the SL grid and therefore it must remain in Second Life > until they log back into their account and say differently. There's already a "trust" agreement between LL and IBM, content is already leaving the SL grid for third-party servers. If your claim of "not legal" has any basis then that agreement is in desperate need of revising. More realistically, the ramifications will no doubt have been looked at by lawyers on both sides and weren't a problem to keep from having the agreement in place so there should be nothing that stands in the way of making all content "creation and trusted grids" by default. If you can't give consumers access to things they bought regardless of whatever sim they're on, you might as well bury "open grid" fantasies because there will be no point. Creator rights do matter, but so do consumer rights, any solution will have to be a compromise between the two - often opposing - needs because both groups need each other. Just because assets are currently being transferred to the sim doesn't mean that's the only way, a lot of content on web pages comes from half a dozen different servers which the browser fetches independently. The analogy only goes so far obviously, but there's no reason assets *have* to be sent across grids, simulate them on their native grid and let the viewer combine it all together. The current system was obviously never intended to operate in a shared environment of non-LL operated sims/grids, don't waste time trying to fit a square block into a round hole just because you want your shiny new toy *now* but go back to the drawing board and design something new and solid from the ground up that meets all the current and forseeable future requirements. It'll have to happen at some point anyway, it might as well be now so you can start with a solid foundation to build on. From mrfrans at gmail.com Thu Jun 12 12:19:36 2008 From: mrfrans at gmail.com (Frans) Date: Thu Jun 12 12:19:40 2008 Subject: [sldev] spam In-Reply-To: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> Message-ID: <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> > > If it did NOT come through the list itself I would be more concerned, > becuase that would mean spammers are somehow getting our email addresses > from the list. This list is public and googleble. So spammer are likely getting your email from this list. https://lists.secondlife.com/pipermail/sldev/ -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/9efa31ef/attachment.htm From missannotoole at yahoo.com Thu Jun 12 12:30:25 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 12 12:30:28 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change Message-ID: <343092.33439.qm@web59101.mail.re1.yahoo.com> >From: Kitty >More realistically, the ramifications will no doubt have been looked at by >lawyers on both sides and weren't a problem to keep from having the >agreement in place so there should be nothing that stands in the way of >making all content "creation and trusted grids" by default. Somehow I doubt any lawyers looked at it at all. Bringing in the suits usually delays such an endeavor for months because the lawyers really do perform due diligence. So I think it is quite reasonable to require LL to have their general counsel speck on this topic and explain what was done and what agreements are in place and exactly how LL assumed the right to distribute IP owned by others outside of the Secondlife Service under the terms of the TOS is restricted to the Secondlife Grid. (Note there is a built in loophole in what I just said) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/c821b775/attachment.htm From darien_caldwell at comcast.net Thu Jun 12 13:03:17 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Thu Jun 12 13:03:24 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change Message-ID: <061220082003.11391.485181050002792F00002C7F221652585604040A990B040E0CA1020A079D0E0B@comcast.net> -------------- Original message ---------------------- From: "Kitty" > > More realistically, the ramifications will no doubt have been looked at by > lawyers on both sides and weren't a problem to keep from having the > agreement in place so there should be nothing that stands in the way of > making all content "creation and trusted grids" by default. There is one very big thing standing in the way of making all content "creation and trusted grids" by default. And that is the rights of the creator. Failure to recognize those rights will have consequences, perhaps legal, most certainly social. Once word gets out that LL doesn't honor the rights of the creators of the IP on it's servers, SL will lose out. I don't have to practice my art here, I choose to. I can just as easily go to other venues and be creative in admittedly different forms, but at least, these forms are more IP protective. What makes SL unique is that you can be creative, be collaborative, share your work with others, and still have relative levels of protection of that work. If those protections are thrown to the wind, it will lose it's appeal for many, as it will be little different from the Internet we have now. It would be very shortsighted of Linden Lab to toss aside the one crucial improvement over the Internet which they have created, protection and accountability (however limited it may be). Sure, 3D is nice, but you can go to IMVU for that (smirks). I'll say it again, creative, collaborative, accessible, and yet protected, do not alter this formula. It's the magic recipe that makes SL so appealing. From sldev at catznip.com Thu Jun 12 13:07:45 2008 From: sldev at catznip.com (Kitty) Date: Thu Jun 12 13:04:52 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change In-Reply-To: <343092.33439.qm@web59101.mail.re1.yahoo.com> References: <343092.33439.qm@web59101.mail.re1.yahoo.com> Message-ID: <301F5406A5C648D693EADBAF6A0A7DE5@devbits.intra> What provision currently covers distribution of IP to non-LL viewers actually? Unless I'm missing something, section 1.1 defines the "service" as *including* the software that Linden Lab provides which would make any LL viewer an inherent part of the "service". So why isn't sending out textures to non-LL viewers a violation? *confuzzled* I'm not trying to start a silly argument, I'm genuinely curious. If non-LL viewers aren't part of the service but if sending content over to them doesn't create any legal problems, why would a non-LL operated sim be any different? So I think it is quite reasonable to require LL to have their general counsel speck on this topic and explain what was done and what agreements are in place and exactly how LL assumed the right to distribute IP owned by others outside of the Secondlife Service under the terms of the TOS is restricted to the Secondlife Grid. (Note there is a built in loophole in what I just said) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/c9abaa01/attachment.htm From missannotoole at yahoo.com Thu Jun 12 13:20:10 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 12 13:20:13 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change Message-ID: <849746.9518.qm@web59109.mail.re1.yahoo.com> The Service is the Secondlife grid, asset servers, support system, etc. The viewer(s) only render within that service. Why are you having such a hard time with the reality that the TOS specifically states the content is restricted to use within the Secondlife Service? have you already begun taking content out of the Secondlife Service without a license? ----- Original Message ---- From: Kitty To: Ann Otoole Cc: Second Life Developer Mailing List Sent: Thursday, June 12, 2008 4:07:45 PM Subject: RE: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change What provision currently covers distribution of IP to non-LL viewers actually? Unless I'm missing something, section 1.1 defines the "service" as *including* the software that Linden Lab provides which would make any LL viewer an inherent part of the "service". So why isn't sending out textures to non-LL viewers a violation? *confuzzled* I'm not trying to start a silly argument, I'm genuinely curious. If non-LL viewers aren't part of the service but if sending content over to them doesn't create any legal problems, why would a non-LL operated sim be any different? So I think it is quite reasonable to require LL to have their general counsel speck on this topic and explain what was done and what agreements are in place and exactly how LL assumed the right to distribute IP owned by others outside of the Secondlife Service under the terms of the TOS is restricted to the Secondlife Grid. (Note there is a built in loophole in what I just said) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/6146dbbc/attachment.htm From sldev at catznip.com Thu Jun 12 14:03:13 2008 From: sldev at catznip.com (Kitty) Date: Thu Jun 12 14:00:21 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change In-Reply-To: <849746.9518.qm@web59109.mail.re1.yahoo.com> References: <849746.9518.qm@web59109.mail.re1.yahoo.com> Message-ID: <50BAA6646539455EAE70F3CDDA9AD182@devbits.intra> ""Second Life" is the multi-user online service offered by Linden Lab, including the software provided to you by Linden Lab (collectively, the "Linden Software") and the online environments that support the service, including without limitation... (snip) ... the software that is provided by Linden Lab and installed on the local computer or other device you use to access the Servers and thereby view or otherwise access the Second Life environment (the "Viewer")... *snip*... The Servers, Viewer, APIs, Websites and any other Linden Software collectively constitute the "Service" as used in this Agreement. " Because your definition of the service isn't consistant with how I read it which is why I asked. To me it reads like the LL supplied viewer is an integral and inseparable part of the service. Since noone is making a problem of the fact that content is being sent to software that isn't provided by Linden Lab, I'm obviously missing something obvious. And if it's not covered by the TOS why is one a problem when the other isn't? Or what would preclude LL from offering an API that deals with handing out assets across grids since it would fall within the existing agreement. As far as interconnected grids go I think it's a ridiculous idea and not worth all the time that's being put into it, but if it *has* to exist then I would want access to everything I paid for within reason (obviously sending assets to untrusted grids simply won't work) just like you're trying to make sure that your opinion is represented. If someone is making content to sell then in my opinion they traded their absolute rights as creator when they extended a license to the use of that content to someone else for payment and the buyer's rights shouldn't just be outright ignored. You might have created it, but you also profitted from it by selling it to others, *both* parties should be considered and not just one who gets to impose additional limitations long after the sale was completed (unless you're willing to refund anyone who doesn't agree with the new acceptable use license you're laying down). As a specific example: say you created my skin. You should expect that there will be mechanisms in place that prevent it from being distributed or resold, but at the same time that shouldn't come at the expense of me actually getting to use the skin I paid you for. An acceptable compromise to me is "creation and trusted grids" (with the assumption that trusted grids treat permissions the same way LL does). Maybe you just want to take money from consumers and give nothing in return, but not everyone will see it that way and it doesn't have anything to do with what you're implying. The Service is the Secondlife grid, asset servers, support system, etc. The viewer(s) only render within that service. Why are you having such a hard time with the reality that the TOS specifically states the content is restricted to use within the Secondlife Service? have you already begun taking content out of the Secondlife Service without a license? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/77f0f4df/attachment-0001.htm From robla at lindenlab.com Thu Jun 12 14:09:56 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 12 14:09:58 2008 Subject: [sldev] [POLICY] Our lawyers are not on this mailing list In-Reply-To: <343092.33439.qm@web59101.mail.re1.yahoo.com> References: <343092.33439.qm@web59101.mail.re1.yahoo.com> Message-ID: <485190A4.6080802@lindenlab.com> On 6/12/08 12:30 PM, Ann Otoole wrote: > Somehow I doubt any lawyers looked at it at all. Bringing in the suits > usually delays such an endeavor for months because the lawyers really > do perform due diligence. > > So I think it is quite reasonable to require LL to have their general > counsel speck on this topic and explain what was done and what > agreements are in place and exactly how LL assumed the right to > distribute IP owned by others outside of the Secondlife Service under > the terms of the TOS is restricted to the Secondlife Grid. (Note there > is a built in loophole in what I just said) Normally, I would issue this offlist, but it's clear this thread is well on its way to being out of control, so I'm going to quote the mailing list policy directly: > This mailing list is for discussing problems and ideas that software > developers can directly address and for collaboration on solutions and > improvements, not for turning Linden Lab development staff into > proxies to reach other parts of Linden Lab (e.g. legal, executive, > human resources, etc). Please read the policies of this mailing list here: https://wiki.secondlife.com/wiki/SLDev If you have a legal concern as a customer of Linden Lab, you should contact us by the means outlined in our terms of service. Rob From missannotoole at yahoo.com Thu Jun 12 14:19:53 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 12 14:19:55 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change Message-ID: <602593.6221.qm@web59101.mail.re1.yahoo.com> From: Kitty >Maybe you just want to take money from consumers and give nothing in return, >but not everyone will see it that way and it doesn't have anything to do with what you're implying. Your looking for love in all the wrong places kitty. Your not going to find it by trying to change an intelligent discourse into a flame war to defend something you may be doing that is not allowed under the current TOS. LL allows open source viewers to connect to and render content inside the Secondlife Service. LL has not been granted nor has requested a license to transmit or distribute content outside of the Service nor has LL created an arrangement to bring external grids under the umbrella of the TOS (the loophole). When you connect a viewer to the service you are bound by the TOS. The TOS applies only to the Service. This is why SL IMs can be published outside the service and it is not a TOS/CS violation albeit rude and bad form to do so. You do not have a license to 3D render and display SL licensed content outside of SL under the existing TOS that protects the rights of creators inside Secondlife. Argue all you want but your not going to change a thing. Only lawyers and LL will make any relevant changes. This entire discussion on rights/licenses is useless until LL brings the lawyers into it. On the other hand there is nothing wrong with discussing the technology that may one day become usable when the legal issues are worked out by lawyers and reflected in various TOS's and EULA's. Since the coders here seem to take exception to the ide of their precious sex pose ball or projectile weapon code being taken from SL then maybe a more fruitful discussion/debate should focus on how to transfer the scripts out. Because this is all worthless unless it all gets to transfer between grids. So come on out coders. Time for you to start working up ways for your content to get taken from Secondlife. If scripts are not allowed to go then neither is any other content. It is all or nothing because it is not a true compatible grid if the widgets don't work. Or is there a problem with two faced discussion here? Oh its perfectly fine for *your* content to be taken but not *my* scripts. Nuh uh. Sorry. that will not stand. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/d7569e6e/attachment.htm From GordonWendt at gmail.com Thu Jun 12 14:42:20 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu Jun 12 14:42:23 2008 Subject: [sldev] spam In-Reply-To: <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> Message-ID: <493033a70806121442nd632c5l5e49adec602f5cc5@mail.gmail.com> The archives page at least should be made noindex for each list should probably be index,nofollow that way they can be easily found via google (which is a good thing) but the links to the subpages and archives won't be automatically followed by compliant bots (which is a bad thing). -G.W. On Thu, Jun 12, 2008 at 3:19 PM, Frans wrote: > If it did NOT come through the list itself I would be more concerned, >> becuase that would mean spammers are somehow getting our email addresses >> from the list. > > > This list is public and googleble. So spammer are likely getting your email > from this list. > https://lists.secondlife.com/pipermail/sldev/ > > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/a1a38ede/attachment.htm From lenglish5 at cox.net Thu Jun 12 15:25:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 12 15:25:09 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-grid permissions change In-Reply-To: <48503CDE.9060007@cox.net> References: <48503CDE.9060007@cox.net> Message-ID: <4851A242.704@cox.net> Lawson English wrote: > > > http://jira.secondlife.com/browse/MISC-1272 This was really meant to be a pointer to the jira, not an invitation to take the jira discussion into SLDEV, sorry. Lawson From gigstaggart at gmail.com Thu Jun 12 17:23:41 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 12 17:23:46 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change In-Reply-To: <50BAA6646539455EAE70F3CDDA9AD182@devbits.intra> References: <849746.9518.qm@web59109.mail.re1.yahoo.com> <50BAA6646539455EAE70F3CDDA9AD182@devbits.intra> Message-ID: <4851BE0D.4090501@gmail.com> Kitty wrote: > Because your definition of the service isn't consistant with how I read it > which is why I asked. To me it reads like the LL supplied viewer is an > integral and inseparable part of the service. Since noone is making a It's kind of pointless to debate this. The TOS was written at a time when the viewer was not open source. Instead of actually fixing the TOS to encompass the reality of an open source client and grid, they kept all of the existing clauses and just added a little exception, "notwithstanding the foregoing you may... use an open source viewer and create a viewer as the open source license allows" (paraphrased). Because the existing claims of the TOS weren't changed, there's some major problems like the ones you pointed out. The bottom line is the TOS is not "by design". Its more "by laziness". Debating "what is meant" is kinda pointless, when no one at Linden Lab has considered what is meant by it (in this context) in several years. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/b9f19086/smime.bin From danteferret at gmail.com Thu Jun 12 17:40:36 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 12 17:40:43 2008 Subject: [sldev] spam In-Reply-To: <493033a70806121442nd632c5l5e49adec602f5cc5@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> <493033a70806121442nd632c5l5e49adec602f5cc5@mail.gmail.com> Message-ID: <4d211a610806121740n24ac94b3v21a66080d81cc7b6@mail.gmail.com> No one posts to sldev-commits except soft and a few other lindens that I know of. I don't see how everyone is saying the members email addresses can be gotten from it's archive. On Thu, Jun 12, 2008 at 5:42 PM, Gordon Wendt wrote: > The archives page at least should be made noindex for each list should > probably be index,nofollow that way they can be easily found via google > (which is a good thing) but the links to the subpages and archives won't be > automatically followed by compliant bots (which is a bad thing). > > -G.W. > > > On Thu, Jun 12, 2008 at 3:19 PM, Frans wrote: > >> If it did NOT come through the list itself I would be more concerned, >>> becuase that would mean spammers are somehow getting our email addresses >>> from the list. >> >> >> This list is public and googleble. So spammer are likely getting your >> email from this list. >> https://lists.secondlife.com/pipermail/sldev/ >> >> >> -- >> Jeroen Frans >> The Vesuvius Group >> http://www.thevesuviusgroup.com >> http://www.linkedin.com/in/mrfrans >> SL: Frans Charming >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/841e583d/attachment-0001.htm From GordonWendt at gmail.com Thu Jun 12 17:49:57 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu Jun 12 17:50:00 2008 Subject: [sldev] spam In-Reply-To: <4d211a610806121740n24ac94b3v21a66080d81cc7b6@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> <493033a70806121442nd632c5l5e49adec602f5cc5@mail.gmail.com> <4d211a610806121740n24ac94b3v21a66080d81cc7b6@mail.gmail.com> Message-ID: <493033a70806121749l5a80a6f0ka949d53808fa75d1@mail.gmail.com> You can get anyone who's posted's email address from the list archives although it's protected by a very weak anti spam measure, one which can be easily removed fyi. An example is the top portion of the archive page for this thread, with your previous post being the latest post at the top, note your email address on the second line, while using at surrounded by spaces will prevent spammers who don't know how to use find/replace that fact along with the fact that the page is archived by google makes any email address you use to post to this list essentially publicly known. -G.W. ------- [sldev] spam *Dante Tucker* danteferret at gmail.com *Thu Jun 12 17:40:36 PDT 2008* - Previous message: [sldev] spam - Next message: [sldev] New graphics card with old Viewer - *Messages sorted by:* [ date ] [ thread ] [ subject ] [ author ] ------------------------------ No one posts to sldev-commits except soft and a few other lindens that I know of. I don't see how everyone is saying the members email addresses can be gotten from it's archive. On Thu, Jun 12, 2008 at 5:42 PM, Gordon Wendt > wrote: >* The archives page at least should be made noindex for each list should *>* probably be index,nofollow that way they can be easily found via google *>* (which is a good thing) but the links to the subpages and archives won't be *>* automatically followed by compliant bots (which is a bad thing). *>* *>* -G.W.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/5f0017ea/attachment.htm From robla at lindenlab.com Thu Jun 12 17:50:08 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 12 17:50:11 2008 Subject: [sldev] FYI: evaluating Webkit Message-ID: <4851C440.2090407@lindenlab.com> Hi folks, FYI, you may notice we're sponsoring some work to evaluate Webkit as a possible replacement for Mozilla. Alp Toker at Nuanti is working on this work, and has blogged about it here: http://www.atoker.com/blog/2008/06/12/webkit-meta-a-new-standard-for-in-game-web-content/ We're sponsoring this initial work because, based on our cursory evaluation, we have good reason to believe that switching to Webkit will result in performance, stability, and maintainability gains. However, we don't know that for sure, so we're investing a little bit to see what Webkit as an integrated component would look like. As you can see, Alp has been integrating Webkit into uBrowser which makes an apples-to-apples comparison feasible for us. There's a separate dev and announcement list for this project available at the link above. If you're interested in this work, that's a good place to go for updates. Rob From thordain at thordain.com Thu Jun 12 18:33:27 2008 From: thordain at thordain.com (Thordain Curtis) Date: Thu Jun 12 18:33:29 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change In-Reply-To: <602593.6221.qm@web59101.mail.re1.yahoo.com> References: <602593.6221.qm@web59101.mail.re1.yahoo.com> Message-ID: Wow...thought I was reading comments from the "Official Linden Blog" there for a second... Just some perspective. This list will never be taken seriously if it cannot provide discussion in a professional format. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/11f511af/attachment.htm From noemail at sl-dev.info Thu Jun 12 18:33:31 2008 From: noemail at sl-dev.info (sl-dev) Date: Thu Jun 12 18:33:51 2008 Subject: [sldev] for um Message-ID: <4851CE6B.6080501@sl-dev.info> a while ago a few ppl posted about wanting a forum or something. the .info domains r on sale for 99 Cents so i cashed out 192 shiney lindens an got http://sl-dev.info k thanks bye From danteferret at gmail.com Thu Jun 12 19:12:27 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 12 19:12:30 2008 Subject: [sldev] spam In-Reply-To: <493033a70806121749l5a80a6f0ka949d53808fa75d1@mail.gmail.com> References: <4d211a610806110221tae42fa4s7d077772b32f1828@mail.gmail.com> <7765f2c60806121219y30f79c6eq3919515a66323ab1@mail.gmail.com> <493033a70806121442nd632c5l5e49adec602f5cc5@mail.gmail.com> <4d211a610806121740n24ac94b3v21a66080d81cc7b6@mail.gmail.com> <493033a70806121749l5a80a6f0ka949d53808fa75d1@mail.gmail.com> Message-ID: <4d211a610806121912y758cee03o2d98e5664383bbbc@mail.gmail.com> Yes, I was not confused. The mailing list in question is sldev-commits, not sldev. And really the problem was already addresed and fixed by... Rob. I think this thread can end now. On Thu, Jun 12, 2008 at 8:49 PM, Gordon Wendt wrote: > You can get anyone who's posted's email address from the list archives > although it's protected by a very weak anti spam measure, one which can be > easily removed fyi. An example is the top portion of the archive page for > this thread, with your previous post being the latest post at the top, note > your email address on the second line, while using at surrounded by spaces > will prevent spammers who don't know how to use find/replace that fact along > with the fact that the page is archived by google makes any email address > you use to post to this list essentially publicly known. > > -G.W. > > > ------- > > [sldev] spam *Dante Tucker* danteferret at gmail.com > > *Thu Jun 12 17:40:36 PDT 2008* > > - Previous message: [sldev] spam > > - Next message: [sldev] New graphics card with old Viewer > > - *Messages sorted by:* [ date ] [ > thread ] [ > subject ] [ > author ] > > ------------------------------ > > No one posts to sldev-commits except soft and a few other lindens that I > know of. I don't see how everyone is saying the members email addresses can > be gotten from it's archive. > > On Thu, Jun 12, 2008 at 5:42 PM, Gordon Wendt > wrote: > > >* The archives page at least should be made noindex for each list should > *>* probably be index,nofollow that way they can be easily found via google > *>* (which is a good thing) but the links to the subpages and archives won't be > *>* automatically followed by compliant bots (which is a bad thing). > *>* > *>* -G.W.* > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/0b22b277/attachment.htm From jayden.beresford at gmail.com Thu Jun 12 21:54:34 2008 From: jayden.beresford at gmail.com (Sean Heying) Date: Thu Jun 12 21:54:38 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <5756afe60806122154g2e826658v9f2f86461e59bc05@mail.gmail.com> From: "Dale Mahalko" > And how does Profoky Neva feel about this issue? Oh look, here's a > blog post about this very sl-dev thread. It's too bad Profoky isn't > interested in particupating directly, but here's a link so Profoky > views can be included. Warning, strong language and high emotion. She/He did participate a few days back Cat Cotton @ Ravenglassrentals is Profoky From sldev at bitparts.org Thu Jun 12 22:57:49 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Thu Jun 12 22:58:02 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands Message-ID: <48520C5D.4040703@bitparts.org> Leaving aside the politics and hoping to clear up any misunderstandings, I'd like to summarize what I believe the conclusions are as far as how I, at least, would like to move forward. This is a technical summary, and is still open to discussion (of course) - and, it's how I plan to attempt to fumble my way through the code (wish me luck). It's late, and I don't have Visual Studio open to reference the real names of data files & functions right now, so I'm going from memory - be kind. CURRENTLY: The texture cache stores compressed JPG2000 versions, as received from the region/asset server, in two files - the index data (UUID & such) and header for the JPG2000 data stored in a flat file array of structures (texture.cache), with the remaining image data stored in the cache/textures/x/uuid files. When pulled from the cache, the header data is retrieved, then the remaining bulk of the data is pulled from the individual texture cache file, decoded, and returned to whatever called it as a llRawImage object. MY PLAN: When receiving a texture from the region/asset server, it would be first decoded, then store the llRawImage data - the first x number of bytes (however many are currently used for JPG2000 texture headers) in the texture.cache file, with the remaining data stored in the cache/textures/x/uuid files. The index may also include such data as the dimensions of the texture and total file size (normally in the JPG2000 header, if I'm not mistaken). When pulled from the cache, the "header" data are retrieved from the texture.cache, with the remainder coming from the individual file. No further decoding is necessary. I also plan on finding the code that hard-limits the cache to 1gb and upping that to as much as 100gb - although changing the value to something less would be possible via the gui with a simple modification of the XML file. The immediate impact I can see of these changes is a massive increase in the render speed for previously-cached textures - although there may be some slowdown for new textures, if the JPG2000 format is designed to allow decoding to proceed from a low-resolution to a higher resolution as the file is downloaded the first time. If I'm wrong about that, please correct me (as with anything in this post). In other words, the texture will not progressively decode as it's downloading - it will have to download completely before it is decoded. This is all very first-stage planning - I presume that the cache discard algorithm will have to be tweaked for larger caches, as well as checking the memory footprint required by the larger cache (not sure how much is stored in memory). Changes to the prioritization of downloading may also be necessary to get the most benefit from this, although I strongly suspect that moving to http delivery of textures will necessitate radical changes in that area as well. Down the line, we might be able to look at decoding on-the-fly new textures, then writing the raw image data to the cache when it's completely downloaded. For that matter, I don't see why it's not possible for the cache to store both JPG2000-encoded and raw files in the cache at the same time, with an image format indicator as part of the texture.cache data. This could theoretically pave the way for caching files delivered in other formats - PNG, TGA, etc, should that ever become a potential benefit. I'm not sure if I see a benefit from XORing the raw texture data - granted, it's much less processor-intensive than decoding is, but it's still an extra step, and the system described herein would be just as obfuscated as the existing system. OK - don't be brutal, but please, poke holes - point me where I'm wrong, TECHNICALLY. I get enough politics every evening from the news. Thanks! - Not a Linden, and not wanting to be a Linden, Buckaroo Mu From dahliatrimble at gmail.com Thu Jun 12 23:48:34 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Jun 12 23:48:37 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: Some initial technical thoughts... I suspect that there may be quite a few factors that affect the speed of retrieving raw image data from a hard disk, the operating system and file systems in use, whether disk compression is in place, the transfer rate and seek time of the disk hardware, the size and efficiency of the disk cache, how badly fragmented the drive is, how many other processes on the machine are competing for disk access.... I'm sure there are more. You may want to offer easy to use end-user options for enabling and controlling your proposed changes and do some testing on a few different machines. I suspect that in a multi-core multi-threading setup you may have equal or better results by storing the jpeg2000 files as they currently are stored and maybe changing the criteria for cached textures being deleted so they arent downloaded so often. good luck! :) On Thu, Jun 12, 2008 at 10:57 PM, Buckaroo Mu wrote: > Leaving aside the politics and hoping to clear up any misunderstandings, > I'd like to summarize what I believe the conclusions are as far as how I, at > least, would like to move forward. This is a technical summary, and is still > open to discussion (of course) - and, it's how I plan to attempt to fumble > my way through the code (wish me luck). It's late, and I don't have Visual > Studio open to reference the real names of data files & functions right now, > so I'm going from memory - be kind. > > CURRENTLY: The texture cache stores compressed JPG2000 versions, as > received from the region/asset server, in two files - the index data (UUID & > such) and header for the JPG2000 data stored in a flat file array of > structures (texture.cache), with the remaining image data stored in the > cache/textures/x/uuid files. When pulled from the cache, the header data is > retrieved, then the remaining bulk of the data is pulled from the individual > texture cache file, decoded, and returned to whatever called it as a > llRawImage object. > > MY PLAN: When receiving a texture from the region/asset server, it would be > first decoded, then store the llRawImage data - the first x number of bytes > (however many are currently used for JPG2000 texture headers) in the > texture.cache file, with the remaining data stored in the > cache/textures/x/uuid files. The index may also include such data as the > dimensions of the texture and total file size (normally in the JPG2000 > header, if I'm not mistaken). When pulled from the cache, the "header" data > are retrieved from the texture.cache, with the remainder coming from the > individual file. No further decoding is necessary. I also plan on finding > the code that hard-limits the cache to 1gb and upping that to as much as > 100gb - although changing the value to something less would be possible via > the gui with a simple modification of the XML file. > > The immediate impact I can see of these changes is a massive increase in > the render speed for previously-cached textures - although there may be some > slowdown for new textures, if the JPG2000 format is designed to allow > decoding to proceed from a low-resolution to a higher resolution as the file > is downloaded the first time. If I'm wrong about that, please correct me (as > with anything in this post). In other words, the texture will not > progressively decode as it's downloading - it will have to download > completely before it is decoded. > > This is all very first-stage planning - I presume that the cache discard > algorithm will have to be tweaked for larger caches, as well as checking the > memory footprint required by the larger cache (not sure how much is stored > in memory). Changes to the prioritization of downloading may also be > necessary to get the most benefit from this, although I strongly suspect > that moving to http delivery of textures will necessitate radical changes in > that area as well. Down the line, we might be able to look at decoding > on-the-fly new textures, then writing the raw image data to the cache when > it's completely downloaded. For that matter, I don't see why it's not > possible for the cache to store both JPG2000-encoded and raw files in the > cache at the same time, with an image format indicator as part of the > texture.cache data. This could theoretically pave the way for caching files > delivered in other formats - PNG, TGA, etc, should that ever become a > potential benefit. > > I'm not sure if I see a benefit from XORing the raw texture data - granted, > it's much less processor-intensive than decoding is, but it's still an extra > step, and the system described herein would be just as obfuscated as the > existing system. > > OK - don't be brutal, but please, poke holes - point me where I'm wrong, > TECHNICALLY. I get enough politics every evening from the news. Thanks! > > - Not a Linden, and not wanting to be a Linden, > Buckaroo Mu > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/496c57bf/attachment.htm From alexander.treptow at zweitgeist.com Thu Jun 12 23:50:12 2008 From: alexander.treptow at zweitgeist.com (alexander.treptow) Date: Thu Jun 12 23:50:19 2008 Subject: [sldev] New graphics card with old Viewer In-Reply-To: <485011EC.8000903@lindenlab.com> References: 484FB658.4090006@zweitgeist.com <484FEBC2.2060306@zweitgeist.com> <485011EC.8000903@lindenlab.com> Message-ID: <485218A4.3040803@zweitgeist.com> Yes i have tried reinstalling them several times and installed my version on other pcs. With ATI graphic cards there is no problem, but i got the same problem with a nvidia 7600gt and a 6600. alex Palmer Truelson (Zen Linden) schrieb: > Have you tried reinstalling the nvidia drivers? I've had problems > before where a bad install of nvidia drivers caused GL to claim that > it didn't support multitexturing, and then popped up a requires new > driver message. Reinstalling the drivers cleared it up. I changed > the message log somewhere in 1.19.1 or 1.20 to mention this possibility. > > PT > > > alexander.treptow wrote: >> //------------------------ >>> The current version of the viewer runs on it without any problems >>> but with my older edited viewer i m not able to start SL. >>> My changed viewer says that i need a newer driver, but its the >>> newest i've found. >> >> >> It's a bit mysterious like this, did you investigate in the sources >> how and why the message appears? >> >> Did the log give some ideas? >> //------------------------ >> >> Yes i changed the sources what messages send and what appears, cause >> i only wanted to view my avatar and animate it without seeing >> anything else in the place. >> >> In the log i've found nothing :/ >> >> greets >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Fri Jun 13 00:02:38 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jun 13 00:02:41 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <48521B8E.5070506@gmail.com> Buckaroo Mu wrote: > Leaving aside the politics and hoping to clear up any misunderstandings, > I'd like to summarize what I believe the conclusions are as far as how > I, at least, would like to move forward. This is a technical summary, > and is still open to discussion (of course) - and, it's how I plan to > attempt to fumble my way through the code (wish me luck). It's late, and > I don't have Visual Studio open to reference the real names of data > files & functions right now, so I'm going from memory - be kind. It was on my todo list but any chance of maybe starting a wiki page to document the technical discussion. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080613/5f0f97ee/signature.pgp From matthew.dowd at hotmail.co.uk Fri Jun 13 02:27:49 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jun 13 02:27:52 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change In-Reply-To: <4851BE0D.4090501@gmail.com> References: <849746.9518.qm@web59109.mail.re1.yahoo.com> <50BAA6646539455EAE70F3CDDA9AD182@devbits.intra> <4851BE0D.4090501@gmail.com> Message-ID: It is kind of pointless anyway - even if the TOS were consistent! My arguments are in the jira entry - but in short, a coherent case can be made that any export to other grids restrictions in either the LL TOS or a content creators EULA may be a contract of adhesion violating a consumer's rights under fair use (and I'm talking about someone using content from one grid in another - not piracy). Apple iTunes gives a good example of a system intended to allow third party purchased on the platform to be available only on that platform (and content providers presumedly signed up on that basis), whose legality has been challenged. Now, whether you agree with that argument or not is sort of irrelevant - this is enough related case law on both sides, that the case would be taken seriously by the courts, and the eventual outcome is by no means certain. So at the moment, all that can be said is that such export restrictions in the TOS and EULA *may* be legally binding, or *may* be unenforceable or even illegal in themselves! Matthew > Date: Thu, 12 Jun 2008 20:23:41 -0400> From: gigstaggart@gmail.com> To: sldev@catznip.com> Subject: Re: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change> CC: sldev@lists.secondlife.com> > Kitty wrote:> > Because your definition of the service isn't consistant with how I read it> > which is why I asked. To me it reads like the LL supplied viewer is an> > integral and inseparable part of the service. Since noone is making a> > It's kind of pointless to debate this.> > The TOS was written at a time when the viewer was not open source.> Instead of actually fixing the TOS to encompass the reality of an open> source client and grid, they kept all of the existing clauses and just> added a little exception, "notwithstanding the foregoing you may... use> an open source viewer and create a viewer as the open source license> allows" (paraphrased). _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080613/16e99f25/attachment.htm From gigstaggart at gmail.com Fri Jun 13 03:11:46 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 13 03:11:51 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <485247E2.8030202@gmail.com> Buckaroo Mu wrote: > MY PLAN: When receiving a texture from the region/asset server, it would > be first decoded, then store the llRawImage data - the first x number of > bytes (however many are currently used for JPG2000 texture headers) in > the texture.cache file, with the remaining data stored in the > cache/textures/x/uuid files. The index may also include such data as the Why continue to break it up? Just put the raw files whole on the disk. A reason that JPEG2000 has separate headers is because you can bite off a fixed chunk at the beginning of the file and use that as a low rez FPO while the rest is decoding. Raw data is not progressive like wavelet data is, so breaking the file up makes little sense. If we are talking about longer-term and larger caches, having a single centralized header file is probably not the way you want to go for scalability. > The immediate impact I can see of these changes is a massive increase in > the render speed for previously-cached textures - although there may be > some slowdown for new textures, if the JPG2000 format is designed to > allow decoding to proceed from a low-resolution to a higher resolution > as the file is downloaded the first time. If I'm wrong about that, > please correct me (as with anything in this post). In other words, the > texture will not progressively decode as it's downloading - it will have > to download completely before it is decoded. Keep in mind the option of enabling re-encoding to S3TC before saving to disk. Video cards handle S3TC natively, but it would affect quality. You should probably do what you want to do here before we throw another angle into it, but try to leave the door open for saving as S3TC compressed using the video card hardware to encode and decode. > This is all very first-stage planning - I presume that the cache discard > algorithm will have to be tweaked for larger caches, as well as checking We discussed this WAY back in the day. Right now I believe it's just using LRU, there are more effective discard algorithms out there. > the memory footprint required by the larger cache (not sure how much is > stored in memory). Changes to the prioritization of downloading may also Yes, be careful here. People perceive a growing in-memory cache as a "memory leak". > image format indicator as part of the texture.cache data. This could > theoretically pave the way for caching files delivered in other formats > - PNG, TGA, etc, should that ever become a potential benefit. I would not worry about that at this point. I would turn texture.cache into XML to store pure metadata, and not the headers, as above. Then you can always add more properties if the need arises. > I'm not sure if I see a benefit from XORing the raw texture data - > granted, it's much less processor-intensive than decoding is, but it's > still an extra step, and the system described herein would be just as > obfuscated as the existing system. I would benchmark it with no obfuscation first, and then use that as a baseline when adding any sort of obfuscation. If you feel like it's not obfuscated enough once you don't break up the file into two parts, then the XOR with a constant is another option. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080613/b874a2d2/smime-0001.bin From gigstaggart at gmail.com Fri Jun 13 03:17:37 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 13 03:17:41 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <48524941.4090006@gmail.com> Sorry for the duplicate reply. Something else to consider is zlib type simple compression. It is likely actually faster to zlib compress and write that to disk, than to write full raw files. And PNG is basically flate/zlib. But that would definitely require XOR obfuscation. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080613/3ac38c12/smime.bin From secret.argent at gmail.com Fri Jun 13 03:43:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 13 03:42:15 2008 Subject: [sldev] Off-grid avatars (Re: [DANGER DANGER DANGER etc...]) In-Reply-To: References: <48503CDE.9060007@cox.net> Message-ID: I have posted my followup to this issue to the Jira. It's pretty simple, and I think on later thought it might be possible to make *avatars* portable to a fair degree without moving data between grids, but it will require some careful rethinking of how attachments work and limiting the capabilities of "off-grid" attachments. I'm not watching that Jira, because I anticipate the volume of spam on it to be completely out of control, but I've bookmarked it and will keep an eye on it. I think that the discussion of how you could support off-grid avatars without transferring data between grids is on-topic here but I'll wait for Linden confirmation before continuing the technical discussion. From secret.argent at gmail.com Fri Jun 13 03:54:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 13 03:52:53 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <63ADBC8C-4320-40DF-84F0-14C868D57D75@gmail.com> On 2008-06-13, at 00:57, Buckaroo Mu wrote: > MY PLAN: When receiving a texture from the region/asset server, it > would be first decoded, then store the llRawImage data - the first > x number of bytes (however many are currently used for JPG2000 > texture headers) in the texture.cache file, with the remaining data > stored in the cache/textures/x/uuid files. What is the advantage of retaining the texture.cache file? Simply a place to store small textures? > The immediate impact I can see of these changes is a massive > increase in the render speed for previously-cached textures - > although there may be some slowdown for new textures, if the > JPG2000 format is designed to allow decoding to proceed from a low- > resolution to a higher resolution as the file is downloaded the > first time. That is a major reason for using JPEG2000. > If I'm wrong about that, please correct me (as with anything in > this post). In other words, the texture will not progressively > decode as it's downloading - it will have to download completely > before it is decoded. I don't think you should consider abandoning progressive decoding, it would be too big a break in the system. Possible alternatives: * Don't bother caching textures on disk until they have completely downloaded. * Cache incompletely downloaded textures separately. From tao.takashi at googlemail.com Fri Jun 13 04:54:45 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Fri Jun 13 04:54:48 2008 Subject: [sldev] [POLICY] Our lawyers are not on this mailing list In-Reply-To: <485190A4.6080802@lindenlab.com> References: <343092.33439.qm@web59101.mail.re1.yahoo.com> <485190A4.6080802@lindenlab.com> Message-ID: <23bbb49e0806130454r48230465se78cbc221044ab9e@mail.gmail.com> Hi! So what about creating more mailinglists then with these topics? Esp. legal seems to grow more and more important (also thanks to such changes like the TM policy thing or new things like OGP). I think these need an open discussion, not something hidden in some private email (as long as it's not a personal problem) -- Tao On Thu, Jun 12, 2008 at 11:09 PM, Rob Lanphier wrote: > On 6/12/08 12:30 PM, Ann Otoole wrote: >> >> Somehow I doubt any lawyers looked at it at all. Bringing in the suits >> usually delays such an endeavor for months because the lawyers really do >> perform due diligence. >> >> So I think it is quite reasonable to require LL to have their general >> counsel speck on this topic and explain what was done and what agreements >> are in place and exactly how LL assumed the right to distribute IP owned by >> others outside of the Secondlife Service under the terms of the TOS is >> restricted to the Secondlife Grid. (Note there is a built in loophole in >> what I just said) > > Normally, I would issue this offlist, but it's clear this thread is well on > its way to being out of control, so I'm going to quote the mailing list > policy directly: >> >> This mailing list is for discussing problems and ideas that software >> developers can directly address and for collaboration on solutions and >> improvements, not for turning Linden Lab development staff into proxies to >> reach other parts of Linden Lab (e.g. legal, executive, human resources, >> etc). > > Please read the policies of this mailing list here: > https://wiki.secondlife.com/wiki/SLDev > > If you have a legal concern as a customer of Linden Lab, you should contact > us by the means outlined in our terms of service. > > Rob > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From sheet.spotter at gmail.com Fri Jun 13 08:19:53 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Fri Jun 13 08:22:00 2008 Subject: [sldev] [VWR] VWR-6994 "Avatar Rendering Cost" blanks current hover text Message-ID: <001e01c8cd68$ef12d1e0$2a02a8c0@kenb> Earlier in the week the JIRA entry for this issue was updated with a detailed description of the underlying cause: http://jira.secondlife.com/browse/VWR-6994 Also included is a brief description of a possible solution. The issue remains unassigned, but has already been imported as DEV-14841. Sheet Spotter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080613/bd46452d/attachment.htm From robla at lindenlab.com Fri Jun 13 08:51:27 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 13 08:51:30 2008 Subject: [sldev] Off-grid avatars (Re: [DANGER DANGER DANGER etc...]) In-Reply-To: References: <48503CDE.9060007@cox.net> Message-ID: <1213372287.8633.28.camel@oopsy.hsd1.wa.comcast.net> On Fri, 2008-06-13 at 05:43 -0500, Argent Stonecutter wrote: > I have posted my followup to this issue to the Jira. It's pretty > simple, and I think on later thought it might be possible to make > *avatars* portable to a fair degree without moving data between > grids, but it will require some careful rethinking of how attachments > work and limiting the capabilities of "off-grid" attachments. > > I'm not watching that Jira, because I anticipate the volume of spam > on it to be completely out of control, but I've bookmarked it and > will keep an eye on it. > > I think that the discussion of how you could support off-grid avatars > without transferring data between grids is on-topic here but I'll > wait for Linden confirmation before continuing the technical discussion. It's on topic, but I think starting a related thread in the same style as the previous one is not going to be productive. I'd suggest putting a comment on the talk page of this page: http://wiki.secondlife.com/wiki/Agent_Domain Discussions on this mailing list tend to go in circles because people don't quote enough the original subject with enough context to stay on topic. (BTW, mindlessly letting the quoted thread accumulate in a top-reply doesn't count as providing context).? Also, few make an effort to direct conversations off list when they're spiraling out of control. Most generally don't make an effort to see if the topic was already discussed and documented on JIRA and/or Wiki. If this conversation does stay on-list, I sincerely hope that it stays within the list guidelines: http://wiki.secondlife.com/wiki/SLDev In particular, this guideline: > ?If a topic generates more than five replies in less than 24 hours, > it's time to redirect that conversation to one of our other tools, > either the wiki, the bug tracker, or a thread in the appropriate > forum. A certain unnamed individual has been guilty of making five replies to the same topic in 24 hours *all by himself*. ;-) Rob From lenglish5 at cox.net Fri Jun 13 09:56:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jun 13 09:56:24 2008 Subject: [sldev] [POLICY] Our lawyers are not on this mailing list In-Reply-To: <23bbb49e0806130454r48230465se78cbc221044ab9e@mail.gmail.com> References: <343092.33439.qm@web59101.mail.re1.yahoo.com> <485190A4.6080802@lindenlab.com> <23bbb49e0806130454r48230465se78cbc221044ab9e@mail.gmail.com> Message-ID: <4852A6B4.8080706@cox.net> Christian Scholz / Tao Takashi (SL) wrote: > Hi! > > So what about creating more mailinglists then with these topics? Esp. > legal seems to grow more and more important (also thanks to such > changes like the TM policy thing or new things like OGP). I think > these need an open discussion, not something hidden in some private > email (as long as it's not a personal problem) > > Zha talked to Eben Moglen, principle author of the GPLv3 some time ago, and she says he's interested in conducting or at least sponsoring in-world meetings on the issues of privacy, virtual ownership, etc., in virtual worlds. I think whatever venues arise out of those discussions will be the best place to go for discussions on those topics. Lawson From blindwanderer at gmail.com Fri Jun 13 10:04:30 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Fri Jun 13 10:04:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4851218E.6000802@gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> Message-ID: <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> Has anyone considered switching to JPEG XR? It's supposed to be faster and give better compression. I'm not advocating that images should be re-encoded, just that all new images would be uploaded in the JPEG XR format instead of JPEG2000. JPEG XR also does a good job of dealing with large images, allowing for decoding at various resolutions and sections of the image (this would be beneficial to SL). On Thu, Jun 12, 2008 at 9:15 AM, Jason Giglio wrote: > Argent Stonecutter wrote: >>> I tested it, it works. Nothing could open a jpg that I prepended >>> ASCII >>> 0 onto the beginning of. >> >> I think "dd bs=1 skip=1" is probably insufficiently obscure. > > That's inherently a slippery slope, you do realize that, right? > > -Jason > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From kelly at lindenlab.com Fri Jun 13 11:46:01 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Fri Jun 13 11:46:14 2008 Subject: [sldev] LSL HTTP In, http_server or http_request() status update Message-ID: <4852C069.6020606@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080613/7587ee13/attachment.htm From robla at lindenlab.com Fri Jun 13 15:43:30 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 13 15:43:32 2008 Subject: [sldev] [POLICY] Our lawyers are not on this mailing list In-Reply-To: <23bbb49e0806130454r48230465se78cbc221044ab9e@mail.gmail.com> References: <343092.33439.qm@web59101.mail.re1.yahoo.com> <485190A4.6080802@lindenlab.com> <23bbb49e0806130454r48230465se78cbc221044ab9e@mail.gmail.com> Message-ID: <4852F812.7000202@lindenlab.com> On 6/13/08 4:54 AM, Christian Scholz / Tao Takashi (SL) wrote: > So what about creating more mailinglists then with these topics? Esp. > legal seems to grow more and more important (also thanks to such > changes like the TM policy thing or new things like OGP). I think > these need an open discussion, not something hidden in some private > email (as long as it's not a personal problem) > If you really need to discuss this particular topic publicly, then do it here: https://jira.secondlife.com/browse/MISC-44 In general, here's the guidance I've consistently given: > If the topic is not specifically a Second Life development-related > topic (e.g. mailing list policy or a licensing discussion), it should > be redirected to the wiki, the bug tracker, or the appropriate forum > immediately. One post per 48 hours should be sufficient to bring it to > everyone's attention. ...which I copied and pasted from here: https://wiki.secondlife.com/wiki/SLDev For everyone's convenience, I've edited the list auto-footer to include the link. BTW, if you have comments to make about the posting guidelines, do it here: https://wiki.secondlife.com/wiki/Talk:SLDev Thanks Rob From dmahalko at gmail.com Fri Jun 13 17:10:53 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 13 17:10:55 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: On Fri, Jun 13, 2008 at 12:57 AM, Buckaroo Mu wrote: > I also plan on finding the code that hard-limits the cache to 1gb > and upping that to as much as 100gb To permit such a huge texture cache size, you will need to split off the VFS so that it has its own setting in the client preferences, separate from and just below the texture cache setting. As currently implemented the VFS size is 20% of the total cache size. A 20 gig VFS / RAM-disk will utterly kill your computer's performance and swap you to death. Some intelligent max size limit for the VFS would be nice so people who don't understand the consequences of allocating a 1 gig RAM-disk with only 512 meg of real memory don't shoot themselves in the foot... but then also allow the VFS to be large for people with lots of free memory (2-8 gig). - Scalar Tardis / Dale Mahalko From sldev at bitparts.org Fri Jun 13 19:06:08 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Fri Jun 13 19:06:21 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: References: <48520C5D.4040703@bitparts.org> Message-ID: <48532790.10508@bitparts.org> Dale Mahalko wrote: > On Fri, Jun 13, 2008 at 12:57 AM, Buckaroo Mu wrote: > >> I also plan on finding the code that hard-limits the cache to 1gb >> and upping that to as much as 100gb >> > > To permit such a huge texture cache size, you will need to split off > the VFS so that it has its own setting in the client preferences, > separate from and just below the texture cache setting. > > As currently implemented the VFS size is 20% of the total cache size. > A 20 gig VFS / RAM-disk will utterly kill your computer's performance > and swap you to death. > Ah! See, this is what I meant by "tell me where I'm wrong." I think you're exactly right, keep the VFS as a separate slider, and have the texture cache stored independently. Thanks for the input! -Buckaroo Mu From sldev at bitparts.org Fri Jun 13 19:18:33 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Fri Jun 13 19:18:50 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: References: <48520C5D.4040703@bitparts.org> Message-ID: <48532A79.1040104@bitparts.org> Dahlia Trimble wrote: > Some initial technical thoughts... > > I suspect that there may be quite a few factors that affect the speed > of retrieving raw image data from a hard disk, the operating system > and file systems in use, whether disk compression is in place, the > transfer rate and seek time of the disk hardware, the size and > efficiency of the disk cache, how badly fragmented the drive is, how > many other processes on the machine are competing for disk access.... I would believe that except for the experimentation I did with a ramdisk. Caching from a 1GB ramdisk, which effectively removes every proposed bottleneck, resulted in no perceptible increase in texture rendering whatsoever. Multiple cores & CPUs may very well lead to faster decoding, but it will still be the biggest factor. (If you missed my comments about that experiment, I upgraded my PC from 1.5GB to 3GB - so even with a 1GB ramdisk, effective usable memory went up by .5GB. The cache folder, set to a /cache folder on the ramdisk, did work as well as a normal drive - but did not show the improvement I would expect given the stupendous increase in access time and transfer speed.) -Buckaroo Mu From sldev at bitparts.org Fri Jun 13 19:22:19 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Fri Jun 13 19:22:32 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <63ADBC8C-4320-40DF-84F0-14C868D57D75@gmail.com> References: <48520C5D.4040703@bitparts.org> <63ADBC8C-4320-40DF-84F0-14C868D57D75@gmail.com> Message-ID: <48532B5B.1070907@bitparts.org> Argent Stonecutter wrote: > What is the advantage of retaining the texture.cache file? Simply a > place to store small textures? The texture.cache file, if I'm remembering correctly, stores "header" information - the dimensions, color depth, etc of the file. > I don't think you should consider abandoning progressive decoding, it > would be too big a break in the system. Possible alternatives: > > * Don't bother caching textures on disk until they have completely > downloaded. > * Cache incompletely downloaded textures separately. > Excellent suggestion, and I'm adding that to my plan. The "Don't bother caching textures ... until they have completely downloaded" bit. -Buckaroo Mu From secret.argent at gmail.com Fri Jun 13 19:38:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 13 19:37:21 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: References: <48520C5D.4040703@bitparts.org> Message-ID: <03B93F05-6D5D-40A0-B641-A223F224830C@gmail.com> On 2008-06-13, at 19:10, Dale Mahalko wrote: > To permit such a huge texture cache size, you will need to split off > the VFS so that it has its own setting in the client preferences, > separate from and just below the texture cache setting. I think abandoning the VFS for textures is desirable in any case. From secret.argent at gmail.com Fri Jun 13 19:41:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 13 19:39:44 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48532A79.1040104@bitparts.org> References: <48520C5D.4040703@bitparts.org> <48532A79.1040104@bitparts.org> Message-ID: On 2008-06-13, at 21:18, Buckaroo Mu wrote: > Dahlia Trimble wrote: >> I suspect that there may be quite a few factors that affect the >> speed of retrieving raw image data from a hard disk, the operating >> system and file systems in use, whether disk compression is in >> place, the transfer rate and seek time of the disk hardware, the >> size and efficiency of the disk cache, how badly fragmented the >> drive is, how many other processes on the machine are competing >> for disk access.... > I would believe that except for the experimentation I did with a > ramdisk. Agreed. I have a 4GB SATA battery backed SDRAM (not flash) disk, and putting the texture cache on that RAM disk primarily reduces the disk noise from my computer... it does not speed things up enormously. From dmahalko at gmail.com Fri Jun 13 21:03:30 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 13 21:03:32 2008 Subject: [sldev] How to google only the most current svn file versions? Message-ID: Well, I'm starting to do some lightweight code-hacking, mostly probing of the viewer source for all references to the VFS, which I'll then add to the wiki in case a real programmer should ever want to gut the VFS out and replace it with a huge, fast, XOR'd folder-based storage. Current Google search terms: site:http://svn.secondlife.com/trac/linden/browser/release/ vfs This alas shows every possible file revision, and I don't want to dig through all 1090 hits and hundreds of versions of the same files. Trying to include -"rev=" in the search terms so as to exclude the revisions... svn.secondlife.com/trac/linden/browser/release/indra/llvfs/llvfile.h?rev=173 ...just gives no results at all. What can I do to narrow this source-searching to the current fileset only? - Scalar Tardis / Dale Mahalko From robla at lindenlab.com Fri Jun 13 21:27:00 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 13 21:27:06 2008 Subject: [sldev] How to google only the most current svn file versions? In-Reply-To: References: Message-ID: <1213417620.7360.3.camel@oopsy.hsd1.wa.comcast.net> On Fri, 2008-06-13 at 23:03 -0500, Dale Mahalko wrote: > Well, I'm starting to do some lightweight code-hacking, mostly probing > of the viewer source for all references to the VFS, which I'll then > add to the wiki in case a real programmer should ever want to gut the > VFS out and replace it with a huge, fast, XOR'd folder-based storage. [...] > What can I do to narrow this source-searching to the current fileset > only? The most reliable thing to do is to download the code and search it that way (e.g. grep and find). However, if you insist on using Google, here's what works: "site:svn.secondlife.com/svn/linden/release vfs" Rob From dahliatrimble at gmail.com Fri Jun 13 21:28:11 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Jun 13 21:28:15 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: References: <48520C5D.4040703@bitparts.org> <48532A79.1040104@bitparts.org> Message-ID: I wasn't talking about how the current implementation performs, rather I was attempting to list the factors that *may* affect the improvements gained from a new design that stored *raw* (uncompressed) image data. Assuming such a design does not yet exist, it seems unlikely that it has been tested. On Fri, Jun 13, 2008 at 7:41 PM, Argent Stonecutter wrote: > On 2008-06-13, at 21:18, Buckaroo Mu wrote: > >> Dahlia Trimble wrote: >> >>> I suspect that there may be quite a few factors that affect the speed of >>> retrieving raw image data from a hard disk, the operating system and file >>> systems in use, whether disk compression is in place, the transfer rate and >>> seek time of the disk hardware, the size and efficiency of the disk cache, >>> how badly fragmented the drive is, how many other processes on the machine >>> are competing for disk access.... >>> >> > I would believe that except for the experimentation I did with a ramdisk. >> > > Agreed. I have a 4GB SATA battery backed SDRAM (not flash) disk, and > putting the texture cache on that RAM disk primarily reduces the disk noise > from my computer... it does not speed things up enormously. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080613/dec1377a/attachment-0001.htm From blindwanderer at gmail.com Fri Jun 13 22:32:24 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Fri Jun 13 22:32:28 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <03B93F05-6D5D-40A0-B641-A223F224830C@gmail.com> References: <48520C5D.4040703@bitparts.org> <03B93F05-6D5D-40A0-B641-A223F224830C@gmail.com> Message-ID: <89ca6da00806132232p375930c6k9afa9b2f5a700b4@mail.gmail.com> It's been a while since I've looked at how the cache stores images. In the days of old it would store them in packet form (which is to say before you could decode the image in the cache you had to remove the packet wrapping). What most people don't realize is that the client supports TGA images. If you just converted incoming images to TGA you wouldn't have to do anything fancy to the client to get it to use them. Basically after the image was finished downloading you would convert it and change the cache entry type. TGA for those who don't know is commonly used as a raw image format, it has a header but it is minimal. Strife On Fri, Jun 13, 2008 at 10:38 PM, Argent Stonecutter wrote: > On 2008-06-13, at 19:10, Dale Mahalko wrote: >> >> To permit such a huge texture cache size, you will need to split off >> the VFS so that it has its own setting in the client preferences, >> separate from and just below the texture cache setting. > > I think abandoning the VFS for textures is desirable in any case. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From gigstaggart at gmail.com Fri Jun 13 23:58:12 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 13 23:58:16 2008 Subject: [sldev] [AWG] [META] {EMERGENCY WILL ROBINSON] Jira for meta-gridpermissions change In-Reply-To: <4851BE0D.4090501@gmail.com> References: <849746.9518.qm@web59109.mail.re1.yahoo.com> <50BAA6646539455EAE70F3CDDA9AD182@devbits.intra> <4851BE0D.4090501@gmail.com> Message-ID: <48536C04.8040101@gmail.com> Jason Giglio wrote: > The bottom line is the TOS is not "by design". Its more "by laziness". > Debating "what is meant" is kinda pointless, when no one at Linden Lab > has considered what is meant by it (in this context) in several years. I would like to apologize for my poor choice of words in this message. I did not mean to imply that any particular person or department at Linden Lab was lazy. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080614/78ffdf00/smime.bin From dmahalko at gmail.com Sat Jun 14 02:39:48 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 14 02:39:50 2008 Subject: [sldev] How to google only the most current svn file versions? In-Reply-To: <1213417620.7360.3.camel@oopsy.hsd1.wa.comcast.net> References: <1213417620.7360.3.camel@oopsy.hsd1.wa.comcast.net> Message-ID: On Fri, Jun 13, 2008 at 11:27 PM, Rob Lanphier wrote: > The most reliable thing to do is to download the code and search it that > way (e.g. grep and find). However, if you insist on using Google, > here's what works: > "site:svn.secondlife.com/svn/linden/release vfs" FYI for anyone else trying to use Google's site search like this.... Google apparently hasn't spidered the whole source tree. This search does not include links to fundamental files like llappviewer.cpp So, I'll be downloading the source. :-) From waseemzhr at gmail.com Sat Jun 14 05:24:04 2008 From: waseemzhr at gmail.com (Waseem Azhar) Date: Sat Jun 14 05:24:05 2008 Subject: [sldev] Login SL Using Java Client In-Reply-To: <484F2C03.20307@cox.net> References: <484F2C03.20307@cox.net> Message-ID: Thanks for the help Lawson. On Wed, Jun 11, 2008 at 6:36 AM, Lawson English wrote: > Waseem Azhar wrote: > >> Hi, >> >> I am writing java SL client. Currently I am stuck with login-to-simulator >> case. Using xml-rpc I am able to get authenticated with xml response from >> server. But when I send UseCircuitCode packet to simulator on UDP >> connection, I get no response from the Simulator. >> >> Can anyone help ? >> > > Have you looked at what the Python code is doing? > > http://wiki.secondlife.com/wiki/Presence_Code_Python > > > If you watch the packets from the SL viewer, you'll see that acks for these > packets don't start coming in for a while, so you have to send the first two > or three packets wihout waiting for the ack. > > In order to be sure that you have a good circuit for use with CAPs, you > must wait for an ack, but the first 2 or 3 packets won't ack you until after > you send the last one in the sequence, or so it appears. > > This is probably not intended behavior... > > Lawson > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/798a3420/attachment.htm From gigstaggart at gmail.com Sat Jun 14 06:27:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jun 14 06:27:09 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> Message-ID: <4853C728.80700@gmail.com> Strife Onizuka wrote: > Has anyone considered switching to JPEG XR? It's supposed to be faster > and give better compression. I'm not advocating that images should be > re-encoded, just that all new images would be uploaded in the JPEG XR > format instead of JPEG2000. JPEG XR also does a good job of dealing > with large images, allowing for decoding at various resolutions and > sections of the image (this would be beneficial to SL). > "Faster" doesn't mean much if it's so obscure that highly optimized decoding libraries (that work on 3 platforms) don't exist. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080614/9297984d/smime.bin From zha.ewry at gmail.com Sat Jun 14 08:39:15 2008 From: zha.ewry at gmail.com (Zha Ewry) Date: Sat Jun 14 08:39:17 2008 Subject: [sldev] Login SL Using Java Client In-Reply-To: References: <484F2C03.20307@cox.net> Message-ID: <920d7d850806140839h3712285gfc3f1e2767eb9740@mail.gmail.com> I got the old XMLRPC code working for the first steps in java. If you want some examples of how the hashmaps work out, drop me an e-mali directly - Zha On Sat, Jun 14, 2008 at 8:24 AM, Waseem Azhar wrote: > > Thanks for the help Lawson. > > > > On Wed, Jun 11, 2008 at 6:36 AM, Lawson English wrote: > >> Waseem Azhar wrote: >> >>> Hi, >>> >>> I am writing java SL client. Currently I am stuck with login-to-simulator >>> case. Using xml-rpc I am able to get authenticated with xml response from >>> server. But when I send UseCircuitCode packet to simulator on UDP >>> connection, I get no response from the Simulator. >>> >>> Can anyone help ? >>> >> >> Have you looked at what the Python code is doing? >> >> http://wiki.secondlife.com/wiki/Presence_Code_Python >> >> >> If you watch the packets from the SL viewer, you'll see that acks for >> these packets don't start coming in for a while, so you have to send the >> first two or three packets wihout waiting for the ack. >> >> In order to be sure that you have a good circuit for use with CAPs, you >> must wait for an ack, but the first 2 or 3 packets won't ack you until after >> you send the last one in the sequence, or so it appears. >> >> This is probably not intended behavior... >> >> Lawson >> >> >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/b4716261/attachment-0001.htm From blindwanderer at gmail.com Sat Jun 14 09:26:55 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sat Jun 14 09:26:58 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4853C728.80700@gmail.com> References: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> Message-ID: <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> *cough* well it is new and hasn't been accepted as a standard as of yet, should be only a matter of time before we see third party libraries. Assuming we can get proper rendering support for JPEG XR, it would reduce posterization and color washout (which would be cool). I was more thinking of this as something to keep an eye on for the long term. I totally agree that for the short term it's not feasible. Strife On Sat, Jun 14, 2008 at 9:27 AM, Jason Giglio wrote: > Strife Onizuka wrote: >> Has anyone considered switching to JPEG XR? It's supposed to be faster >> and give better compression. I'm not advocating that images should be >> re-encoded, just that all new images would be uploaded in the JPEG XR >> format instead of JPEG2000. JPEG XR also does a good job of dealing >> with large images, allowing for decoding at various resolutions and >> sections of the image (this would be beneficial to SL). >> > > "Faster" doesn't mean much if it's so obscure that highly optimized > decoding libraries (that work on 3 platforms) don't exist. > > -Jason > From jhurliman at jhurliman.org Sat Jun 14 10:52:33 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sat Jun 14 10:52:35 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> References: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> Message-ID: If you really want to tackle banding/posterization, SL should be using an sRGB color format for textures. It's already encoding textures in sRGB color-space (see llimagej2coj.cpp:282), but feeding that non-linear data into a linear rendering equation (and later back to non-linear color space to display on the monitor) is going to introduce artifacts like posterization. Using OpenGL's sRGB texture format ( http://opengl.org/registry/specs/EXT/texture_sRGB.txt) will automatically do the conversion to linear space before feeding the data into any shaders. Converting to a new texture format won't fix much until you tackle the underlying issue. John On Sat, Jun 14, 2008 at 9:26 AM, Strife Onizuka wrote: > *cough* well it is new and hasn't been accepted as a standard as of > yet, should be only a matter of time before we see third party > libraries. Assuming we can get proper rendering support for JPEG XR, > it would reduce posterization and color washout (which would be cool). > I was more thinking of this as something to keep an eye on for the > long term. I totally agree that for the short term it's not feasible. > > Strife > > On Sat, Jun 14, 2008 at 9:27 AM, Jason Giglio > wrote: > > Strife Onizuka wrote: > >> Has anyone considered switching to JPEG XR? It's supposed to be faster > >> and give better compression. I'm not advocating that images should be > >> re-encoded, just that all new images would be uploaded in the JPEG XR > >> format instead of JPEG2000. JPEG XR also does a good job of dealing > >> with large images, allowing for decoding at various resolutions and > >> sections of the image (this would be beneficial to SL). > >> > > > > "Faster" doesn't mean much if it's so obscure that highly optimized > > decoding libraries (that work on 3 platforms) don't exist. > > > > -Jason > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/2c9a1454/attachment.htm From jhurliman at jhurliman.org Sat Jun 14 11:17:23 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sat Jun 14 11:17:26 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <48540627.7080605@gmail.com> References: <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> Message-ID: Yes it really does matter. The problem is that sRGB (the color-space of every texture in SL) has a gamma of 2.2 ( http://en.wikipedia.org/wiki/Image:SRGB_gamma.svg), a non-linear color space. An RGB value of 0.5,1.0,1.0 does *not* mean 50% intensity for red, you get something like 25% intensity. However your rendering engine (lets say a Phong shading model) is expecting linear values for the inputs. If it sees 0.5,1.0,1.0, it interprets that as "project 50% red photons in relation to blue and green". Linear math is also built directly into OpenGL such as mipmapping, where you'll get incorrect results describing an sRGB color-space as GL_RGB[A]8. John On Sat, Jun 14, 2008 at 10:55 AM, Jason Giglio wrote: > John Hurliman wrote: > > If you really want to tackle banding/posterization, SL should be using an > > sRGB color format for textures. It's already encoding textures in sRGB > > Does that really matter when the end user then feeds that into a monitor > running 9600K color temp at a brightness appropriate for direct sunlight? > > We aren't doing prepress here. > > -Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/18501491/attachment.htm From lenglish5 at cox.net Sat Jun 14 11:18:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 14 11:18:33 2008 Subject: [sldev] [AWG][META} pointer to new grid permissions jira: request for policy clarification Message-ID: <48540B73.7040303@cox.net> This is a pointer to the jira on the wiki. Please make comments on the wiki, not in this mailing list. https://jira.secondlife.com/browse/MISC-1277 Request for policy clarification concerning cross-grid copying of assets Lawson From sldev at bitparts.org Sat Jun 14 12:13:02 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 14 12:13:26 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <89ca6da00806132232p375930c6k9afa9b2f5a700b4@mail.gmail.com> References: <48520C5D.4040703@bitparts.org> <03B93F05-6D5D-40A0-B641-A223F224830C@gmail.com> <89ca6da00806132232p375930c6k9afa9b2f5a700b4@mail.gmail.com> Message-ID: <4854183E.7050609@bitparts.org> Strife Onizuka wrote: > What most people don't realize is that the client supports TGA images. > If you just converted incoming images to TGA you wouldn't have to do > anything fancy to the client to get it to use them. Basically after > the image was finished downloading you would convert it and change the > cache entry type. TGA for those who don't know is commonly used as a > raw image format, it has a header but it is minimal. > > I thought that was the case, from my browsing the code. The more I look at it, the more I doubt that I'm going to be able to implement this project myself, but I can definitely make contributions. I just haven't had the depth of experience with C++ that I need. However, I did notice that the existing code seems to support /reading/ TGA files from the cache, it's just that it doesn't support /writing/ to it except in JPG2000. I think the first step is going to have to be refactoring the interface between llTextureFetch and llTextureCache to include a "format" designator, and instead of passing objects of type llFormattedImage around, just passing the format ID, raw data, and maybe minor header info like dimensions, filesize, and color depth (if necessary). I'll see if I can get to work on a wiki page today organizing all of this into more or less coherent steps and post a link later tonight. -Buckaroo Mu From dahliatrimble at gmail.com Sat Jun 14 12:39:55 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat Jun 14 12:39:58 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <4850E9E4.50408@gmail.com> <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> Message-ID: I agree, the color rendering in sl is horrendous. I had the opportunity to work with Michael Stokes on a closely related project while he was developing the sRGB spec. If my memory is accurate, it was meant for the display of images that were taken with digital cameras or scanned with scanners and will be displayed on CRTs or printed. The sRGB color space is somewhat compromised as it is optimized for consumer devices and was not designed for very high quality color reproduction applications. Given that 3D applications have internal lighting models and radically alter the viewing conditions as the rendering perspective changes (viewing conditions which sRGB is dependant on), I can see that introducing nonlinearities may impose quantization errors and they would be exacerbated when multiplied by scene rendering "lights", especially if the color calculations are limited in precision to 8 bits. However I am *not* currently familiar with the light mixing implementation in OpenGL or the viewer so I dont know how well these comments apply. Off hand it would seem if there were a lot of precision available for the calculations, the 'banding/posterization" would be minimized, at least in the middle level ranges for RGB levels. I wouldn't assume that all the textures in sl are in sRGB space though. I was under the impression that the texture creator could use any color space that the RGB format could support. Could someone familiar with the intricate details of the uploading/conversion/rendering processes add some comments, specifically, what is assumed about the image and do any color conversions occur in the processes? Perhaps some guidelines exist for content creators who create textures, but I haven't seen any. On Sat, Jun 14, 2008 at 11:17 AM, John Hurliman wrote: > Yes it really does matter. The problem is that sRGB (the color-space of > every texture in SL) has a gamma of 2.2 ( > http://en.wikipedia.org/wiki/Image:SRGB_gamma.svg), a non-linear color > space. An RGB value of 0.5,1.0,1.0 does *not* mean 50% intensity for red, > you get something like 25% intensity. However your rendering engine (lets > say a Phong shading model) is expecting linear values for the inputs. If it > sees 0.5,1.0,1.0, it interprets that as "project 50% red photons in relation > to blue and green". Linear math is also built directly into OpenGL such as > mipmapping, where you'll get incorrect results describing an sRGB > color-space as GL_RGB[A]8. > > John > > On Sat, Jun 14, 2008 at 10:55 AM, Jason Giglio > wrote: > >> John Hurliman wrote: >> > If you really want to tackle banding/posterization, SL should be using >> an >> > sRGB color format for textures. It's already encoding textures in sRGB >> >> Does that really matter when the end user then feeds that into a monitor >> running 9600K color temp at a brightness appropriate for direct sunlight? >> >> We aren't doing prepress here. >> >> -Jason >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/56978c82/attachment.htm From lenglish5 at cox.net Sat Jun 14 15:02:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 14 15:02:17 2008 Subject: [sldev] Login SL Using Java Client In-Reply-To: References: <484F2C03.20307@cox.net> Message-ID: <48543FE6.6010303@cox.net> Waseem Azhar wrote: > > Thanks for the help Lawson. > Did it work? L. From jhurliman at jhurliman.org Sat Jun 14 16:04:05 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sat Jun 14 16:04:08 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> Message-ID: The source code line I referenced, llimagej2coj.cpp:282, points to where all textures being uploaded to the grid are converted to sRGB color-space. This is the default for JPEG2000, and although someone could technically use a third party client to upload an image with an embedded color profile it would be discarded. I found a website that explains the issue in better depth (with a specific example of the mip-mapping problem): http://www.sjbrown.co.uk/?article=gamma Created a JIRA for the issue here: http://jira.secondlife.com/browse/VWR-7778 John On Sat, Jun 14, 2008 at 12:39 PM, Dahlia Trimble wrote: > I agree, the color rendering in sl is horrendous. I had the opportunity to > work with Michael Stokes on a closely related project while he was > developing the sRGB spec. If my memory is accurate, it was meant for the > display of images that were taken with digital cameras or scanned with > scanners and will be displayed on CRTs or printed. The sRGB color space is > somewhat compromised as it is optimized for consumer devices and was not > designed for very high quality color reproduction applications. Given that > 3D applications have internal lighting models and radically alter the > viewing conditions as the rendering perspective changes (viewing conditions > which sRGB is dependant on), I can see that introducing nonlinearities may > impose quantization errors and they would be exacerbated when multiplied by > scene rendering "lights", especially if the color calculations are limited > in precision to 8 bits. However I am *not* currently familiar with the light > mixing implementation in OpenGL or the viewer so I dont know how well these > comments apply. Off hand it would seem if there were a lot of precision > available for the calculations, the 'banding/posterization" would be > minimized, at least in the middle level ranges for RGB levels. > > I wouldn't assume that all the textures in sl are in sRGB space though. I > was under the impression that the texture creator could use any color space > that the RGB format could support. Could someone familiar with the intricate > details of the uploading/conversion/rendering processes add some comments, > specifically, what is assumed about the image and do any color conversions > occur in the processes? Perhaps some guidelines exist for content > creators who create textures, but I haven't seen any. > > On Sat, Jun 14, 2008 at 11:17 AM, John Hurliman > wrote: > >> Yes it really does matter. The problem is that sRGB (the color-space of >> every texture in SL) has a gamma of 2.2 ( >> http://en.wikipedia.org/wiki/Image:SRGB_gamma.svg), a non-linear color >> space. An RGB value of 0.5,1.0,1.0 does *not* mean 50% intensity for red, >> you get something like 25% intensity. However your rendering engine (lets >> say a Phong shading model) is expecting linear values for the inputs. If it >> sees 0.5,1.0,1.0, it interprets that as "project 50% red photons in relation >> to blue and green". Linear math is also built directly into OpenGL such as >> mipmapping, where you'll get incorrect results describing an sRGB >> color-space as GL_RGB[A]8. >> >> John >> >> On Sat, Jun 14, 2008 at 10:55 AM, Jason Giglio >> wrote: >> >>> John Hurliman wrote: >>> > If you really want to tackle banding/posterization, SL should be using >>> an >>> > sRGB color format for textures. It's already encoding textures in sRGB >>> >>> Does that really matter when the end user then feeds that into a monitor >>> running 9600K color temp at a brightness appropriate for direct sunlight? >>> >>> We aren't doing prepress here. >>> >>> -Jason >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/370683b8/attachment.htm From sldev at bitparts.org Sat Jun 14 16:55:39 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 14 16:56:03 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <48545A7B.7010000@bitparts.org> OK, I've made a Wiki page about the discussions we've had regarding the Texture Cache, with some additional thoughts. Please check it out, discuss as necessary. https://wiki.secondlife.com/wiki/SLDEV_Discussion_-_Texture_Cache_Plan_of_Attack From secret.argent at gmail.com Sat Jun 14 17:01:58 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 14 17:00:29 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> Message-ID: <890DE91C-152E-4F42-AF2D-8B8A19BC5537@gmail.com> On 2008-06-14, at 18:04, John Hurliman wrote: > The source code line I referenced, llimagej2coj.cpp:282, points to > where all textures being uploaded to the grid are converted to sRGB > color-space. Wouldn't this cause distortions in sculpt textures? From dahliatrimble at gmail.com Sat Jun 14 17:38:59 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat Jun 14 17:39:01 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <890DE91C-152E-4F42-AF2D-8B8A19BC5537@gmail.com> References: <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> <890DE91C-152E-4F42-AF2D-8B8A19BC5537@gmail.com> Message-ID: It probably depends on how the conversion takes place. If a sculptie texture image contains metadata that describes it as containing RGB data in the sRGB color space, then I would hope no conversion of the actual RGB data would occur. The condition that concerns me is if the actual RGB data is transformed if I upload an image in another format, or if it is merely marked as sRGB in metadata. As a content creator it would be nice to know how the conditions where any changes to the data occur. Would it be possible to fool the importer by specifying the data is in sRGB, but replacing the actual data with something else? Thanks for the reference to that web site John, it described my earlier concerns fairly well. On Sat, Jun 14, 2008 at 5:01 PM, Argent Stonecutter wrote: > On 2008-06-14, at 18:04, John Hurliman wrote: > >> The source code line I referenced, llimagej2coj.cpp:282, points to where >> all textures being uploaded to the grid are converted to sRGB color-space. >> > > Wouldn't this cause distortions in sculpt textures? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080614/dd2ee635/attachment.htm From sldev at bitparts.org Sun Jun 15 23:07:22 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sun Jun 15 23:07:54 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <48520C5D.4040703@bitparts.org> References: <48520C5D.4040703@bitparts.org> Message-ID: <4856031A.8030906@bitparts.org> I've been browsing the code some more, and have come up with a few questions for those who may be more familiar with the details of the image pipeline. 1 - Would it be beneficial, and what are the unintended consequences, of moving the "Load from Network", "Load from Simulator", and decode from llTextureFetch to llTextureCache? This would allow llTextureFetch to only process images stored in llRawImage objects, and leave llTextureCache to deal with the details of what format a texture is available in. It increase the complexity of the llTextureCache object, but dramatically simplifies the "fetch" operation - since it would not have to deal with differing image formats. Corollaries - we could effectively remove the llFormattedImage object use from llTextureFetch class, if I'm not mistaken. This would also allow the llTextureCache to take care of writing cached files by itself, rather than being told to by the llTextureFetch class. 2 - The code delimited by USE_LFS_READ and USE_LFS_WRITE - I presume that's there to allow better platform neutrality? This may sound 80's of me, but would there be any benefit to using #ifdef-delimited blocks to define platform-specific read & write functions for the local file system, and reduce the overhead of an additional third-party library? Of course, it's probably used many other places in the code, but it's just a thought. I'm sure I'll think of more as I dig. I'm slowly beginning to understand this tiny portion of the code. -Buckaroo Mu From dmahalko at gmail.com Sun Jun 15 23:42:42 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Jun 15 23:42:45 2008 Subject: [sldev] [WEB] wiki Viewer Source Files page needs an update Message-ID: Could someone with more knowledge and experience please update the Viewer Source Files wiki page? https://wiki.secondlife.com/wiki/Viewer_Source_Files I'm creating a page documenting where the various VFS, gVFS, gStaticVFS, and LFS references are located in the 1.19.1.4 source. I am basing the layout of the new page on that source file listing. https://wiki.secondlife.com/wiki/VFS:_Where_it_is_used_in_the_viewer In the process I've found a large collection of source files that aren't on the Viewer Source Files page, which I've stuck at the bottom of the new page: https://wiki.secondlife.com/wiki/VFS:_Where_it_is_used_in_the_viewer#Unlisted_in_Viewer_Source_Files_page I can understand some of these files not being listed, since the viewer source page hasn't been updated since August 2007....... but many of the unlisted files I'm finding were in existence long before that time, like llvfs.cpp. As a non-C++/Visual Studio programmer, I don't know how to determine which of these "extra" files are actually being used and where they should be added to the Viewer Source Files page. Some may be unused, legacy, or example files, but I have no idea. - Scalar Tardis / Dale Mahalko From dmahalko at gmail.com Mon Jun 16 02:55:36 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 16 02:55:39 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <4856031A.8030906@bitparts.org> References: <48520C5D.4040703@bitparts.org> <4856031A.8030906@bitparts.org> Message-ID: On Mon, Jun 16, 2008 at 1:07 AM, Buckaroo Mu wrote: > 2 - The code delimited by USE_LFS_READ and USE_LFS_WRITE - I presume that's > there to allow better platform neutrality? This may sound 80's of me, but > would there be any benefit to using #ifdef-delimited blocks to define > platform-specific read & write functions for the local file system, and > reduce the overhead of an additional third-party library? Of course, it's > probably used many other places in the code, but it's just a thought. It may be that the LFS calls are (becoming) legacy code. As that code is written the client uses either LFS calls or apr_file calls, and the globals at the top seem to be forcing the client to only use the apr_file calls. Two hours ago I had no clue what the Apache Portable Runtime was for, but the Wikipedia article says it is designed to provide cross-platform filesystem access for the Apache server. If a platform doesn't support a needed feature, then the APR will provide that functionality directly by itself, making it a very useful library even when your goal isn't to design a web server. http://en.wikipedia.org/wiki/Apache_Portable_Runtime The LFS code was probably the previous method, now superseded by the apr_file calls. The client code was originally only written for Windows so the internally-created LLLFS code may at one time have made sense, but it does not now, as the client spreads to more widely varying OS platforms. llapr.cpp: S32 ll_apr_file_read(apr_file_t* apr_file, void *buf, S32 nbytes) S32 ll_apr_file_read_ex(const LLString& filename, apr_pool_t* pool, void *buf, S32 offset, S32 nbytes) S32 ll_apr_file_write(apr_file_t* apr_file, const void *buf, S32 nbytes) S32 ll_apr_file_write_ex(const LLString& filename, apr_pool_t* pool, void *buf, S32 offset, S32 nbytes) S32 ll_apr_file_seek(apr_file_t* apr_file, apr_seek_where_t where, S32 offset) bool ll_apr_file_remove(const LLString& filename, apr_pool_t* pool) bool ll_apr_file_rename(const LLString& filename, const LLString& newname, apr_pool_t* pool) bool ll_apr_file_exists(const LLString& filename, apr_pool_t* pool) S32 ll_apr_file_size(const LLString& filename, apr_pool_t* pool) bool ll_apr_dir_make(const LLString& dirname, apr_pool_t* pool) bool ll_apr_dir_remove(const LLString& dirname, apr_pool_t* pool) I see there are 20 source files that use the Apache Portable Runtime "apr_file" functions. Heh, I will see about wikifying this stuff. I'm not really finding much info about the client's APR usage, in the SL wiki. - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Mon Jun 16 05:04:13 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 16 05:04:25 2008 Subject: [sldev] Texture Cache: A summary of The Plan as it stands In-Reply-To: <4856031A.8030906@bitparts.org> References: <48520C5D.4040703@bitparts.org> <4856031A.8030906@bitparts.org> Message-ID: <485656BD.8030909@gmail.com> Buckaroo Mu wrote: > I've been browsing the code some more, and have come up with a few > questions for those who may be more familiar with the details of the > image pipeline. > > 1 - Would it be beneficial, and what are the unintended consequences, of We can't know that. Profile, profile, profile. Inspection can give guidance, but you must develop a profiling plan to actually see what changes are beneficial and worth it. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080616/e295fa66/smime.bin From lenglish5 at cox.net Tue Jun 17 11:50:21 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 17 11:50:24 2008 Subject: [sldev] [AWG][Meta] Revised jira: request for policy clarification for permissions system Message-ID: <4858076D.1090701@cox.net> https://jira.secondlife.com/browse/MISC-1277 Request for policy clarification concerning cross-grid copying of assets Please take any discussion back to the jira, not here. Thanks. L. From qarl at lindenlab.com Wed Jun 18 10:26:56 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Wed Jun 18 10:26:58 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <20080614190024.465AC41B4AC@stupor.lindenlab.com> References: <20080614190024.465AC41B4AC@stupor.lindenlab.com> Message-ID: <3DBB67E6-2556-4F7E-88D3-6FC9F558CC6A@lindenlab.com> John Hurliman wrote: > If you really want to tackle banding/posterization, SL should be > using an sRGB color format for textures YES! ten years ago i made a pretty penny writing a bunch of shaders which compensated for bad math in non-linear color spaces. but the effect is very subtle. it's most noticeable in reflections off water... i don't think it's responsible for our posterization problem in highly compressed images. i think that's all JPEG2000's doing. K. From waseemzhr at gmail.com Wed Jun 18 10:29:01 2008 From: waseemzhr at gmail.com (Waseem Azhar) Date: Wed Jun 18 10:29:04 2008 Subject: [sldev] Simulator disconnect every 30 second Message-ID: Hi All, I am having trouble keeping the connection alive with simulator. After successful login, Simulator stop sending data and disconnect me in about 30 seconds. Though the time I am connected, I can send/receive packets e.g requesting balance, friend online/offline notification, economy, balace transfer etc. Seems there is something I need to do to keep connection alive, is it ping packets ? not sure.. in the libsl C# code I even disabled ping packets but connection with simulator stays alive for long time. Any idea ? Thanks, /Azhar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080618/a24de2fa/attachment.htm From carjay at gmx.net Wed Jun 18 11:29:10 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Jun 18 11:29:36 2008 Subject: [sldev] Cache politics: OpenJPEG and colour spaces In-Reply-To: References: <378A993F-92F2-4CEC-935B-BBADB07836AF@gmail.com> <4851218E.6000802@gmail.com> <89ca6da00806131004s5ad7a81cg6ed9f8ae32dcdfe9@mail.gmail.com> <4853C728.80700@gmail.com> <89ca6da00806140926q2caebf95m7d9c0601c3cf69b9@mail.gmail.com> <48540627.7080605@gmail.com> Message-ID: <485953F6.7030200@gmx.net> John Hurliman wrote: > The source code line I referenced, llimagej2coj.cpp:282, points to > where all textures being uploaded to the grid are converted to sRGB > color-space. This is the default for JPEG2000, and although someone > could technically use a third party client to upload an image with an > embedded color profile it would be discarded. I guess whoever wrote that code was using some example code from OpenJPEG. The colour space setting is only used in case you generate a JP2-file (which is an optional file format to wrap the JPEG2000 codestream into) and is the only enumerated RGB colour space offered for that format. You are free to embed your own ICC profile in it though. The SL viewer uses the JPEG2000 codestream itself which makes no assumptions what colour space is used or even what the components are, that information is simply not stored. You are free to encode the components in RGB, YUV, XYZ or any colour space you would like. Carsten From kwerks.sl at gmail.com Wed Jun 18 12:11:50 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Wed Jun 18 12:11:56 2008 Subject: [sldev] Viewer inventory management: duplicate/clone tool Message-ID: <7b61e3970806181211w78fb72dfvc678b94f683ed97c@mail.gmail.com> One of the projects I have been toying with is a ways to address, via the viewer UI, tools for inventory management. One aspect of this is how to deal with multiple listed items referencing the same object, the same UUID. I do appreciate that these are simply references but they do create load on both the severs and client. I have done this in LSL for my texture organizer and inventory box but it seems to me the place for it, really, is in the viewer itself. Perhaps there is a way to this this already but what I have been thinking of is adding another tab to the inventory view that identifies and filters based on duplicate references pointing to a single UUID. A duplicates tab, if you will. This would afford the user another tool to cull inventory and I imagine cumulatively, across the user base, could potentially alleviate some server load. My questions: - Is this a sensible, worthwhile pursuit? if so.. - does it warrant a JIRA? - what other ways might this be implemented in the UI I would appreciate any thoughts you all may have. regards JB p.s. Apologies if this is an inappropriate forum or method of presenting this notion. I am still stuggling with culture and procedure. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080618/b84f86b6/attachment.htm From lenglish5 at cox.net Wed Jun 18 14:00:47 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jun 18 14:00:49 2008 Subject: [sldev] Viewer inventory management: duplicate/clone tool In-Reply-To: <7b61e3970806181211w78fb72dfvc678b94f683ed97c@mail.gmail.com> References: <7b61e3970806181211w78fb72dfvc678b94f683ed97c@mail.gmail.com> Message-ID: <4859777F.2000302@cox.net> JB Kraft wrote: > One of the projects I have been toying with is a ways to address, via > the viewer UI, tools for inventory management. One aspect of this is > how to deal with multiple listed items referencing the same object, > the same UUID. I do appreciate that these are simply references but > they do create load on both the severs and client. > > I have done this in LSL for my texture organizer and inventory box but > it seems to me the place for it, really, is in the viewer itself. > Perhaps there is a way to this this already but what I have been > thinking of is adding another tab to the inventory view that > identifies and filters based on duplicate references pointing to a > single UUID. A duplicates tab, if you will. This would afford the user > another tool to cull inventory and I imagine cumulatively, across the > user base, could potentially alleviate some server load. > > My questions: > > - Is this a sensible, worthwhile pursuit? > > if so.. > > - does it warrant a JIRA? > - what other ways might this be implemented in the UI > > I would appreciate any thoughts you all may have. > > regards > JB > > p.s. Apologies if this is an inappropriate forum or method of > presenting this notion. I am still stuggling with culture and procedure. > It sounds like a great idea on the face, but I wonder if there would be increased server load from using it since the current U, IIRC, requires a server-side update for each inventory change in an inventory folder. If your proposed code deletes 1000 duplicate items from inventory, that's an extra 1000 update messages sent to the server at a rather speedy clip, using a system designed for rather slow, manual-speed updating. If you could implement a batch-processing for the update packets, that might make things worthwhile. The other way, would be to make it an idle task that makes only a few updates at a time. Lawson From gbrandon at gmail.com Thu Jun 19 05:08:38 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Jun 19 05:08:40 2008 Subject: [sldev] RevokePermissions In-Reply-To: References: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> Message-ID: Hmm I put it in JIRA http://jira.secondlife.com/browse/VWR-7822 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080619/d0a99685/attachment.htm From dmahalko at gmail.com Thu Jun 19 10:51:55 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu Jun 19 10:51:57 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? Message-ID: Cross-posting from the Open Source Meeting Agenda page: How do you (Rob / LL staff / and the rest of the SL-Dev professionals) feel about relative C++ noobs (*waves!*) jumping headfirst into the client source to explore it? Do you prefer that only people with years of prior C++ experience try to be involved with the open source project? ("Come back when you've actually used a multimap in a program!") I am wondering if showing up at the open source meeting and asking what may seem as "stupid beginner's questions" would be perceived as annoying and a waste of your / LL-Staffs' professional time. (For example, why is ll_apr_file used for open/read/write/etc rather than just apr_file? Is llapr.cpp a shim library, to make transitioning from the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't find any official coding policy or notes pointing in that direction. Is it okay to discuss this in SLDev or not?) My interest and involvement in the source is mostly because I want the VFS expunged, and the overall caching performance improved... but since this coding task is apparently not high on anyone else's agenda, I guess there's room for a QBASIC / LSL2 / Apple II 6502-assembly programmer to explore the issue. (Note, the only thing I've ever threaded is a needle.) - Scalar Tardis / Dale Mahalko From tongb at ohio.edu Thu Jun 19 11:46:46 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 19 11:46:53 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: References: Message-ID: <4f335a50806191146ofa68b24w586be9516c9ca55f@mail.gmail.com> I'll just say you're not alone and that I appreciate what may seem like ignorant (not stupid) beginner's questions. We're in similar states, Dale. My C background is about 5 years stale and I usually worked on server-side stuff. There is ANSI C++ syntax that I don't recall ever seeing before in the source code and I feel kind of embarrased to admit that. I mean, I wrote code in C for many years before taking jobs that used Java. All the various issues about rendering graphic images and the various libraries they use are all completely foreign. Anyways, as far as I'm concerned, ask away. Being a (relative) noob is temporary. SL: Wilton Lundquist On Thu, Jun 19, 2008 at 1:51 PM, Dale Mahalko wrote: > Cross-posting from the Open Source Meeting Agenda page: > > > How do you (Rob / LL staff / and the rest of the SL-Dev professionals) > feel about relative C++ noobs (*waves!*) jumping headfirst into the > client source to explore it? Do you prefer that only people with years > of prior C++ experience try to be involved with the open source > project? ("Come back when you've actually used a multimap in a > program!") > > I am wondering if showing up at the open source meeting and asking > what may seem as "stupid beginner's questions" would be perceived as > annoying and a waste of your / LL-Staffs' professional time. (For > example, why is ll_apr_file used for open/read/write/etc rather than > just apr_file? Is llapr.cpp a shim library, to make transitioning from > the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't > find any official coding policy or notes pointing in that direction. > Is it okay to discuss this in SLDev or not?) > > My interest and involvement in the source is mostly because I want the > VFS expunged, and the overall caching performance improved... but > since this coding task is apparently not high on anyone else's agenda, > I guess there's room for a QBASIC / LSL2 / Apple II 6502-assembly > programmer to explore the issue. (Note, the only thing I've ever > threaded is a needle.) > > - Scalar Tardis / Dale Mahalko -- Bruce Tong Software Engineer Office of Information Technology Ohio University From q at lindenlab.com Thu Jun 19 11:53:05 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu Jun 19 11:53:18 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: References: Message-ID: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com> I'm going to jump in and suggest that the big-picture OS discussion on Thursdays probably doesn't want to include detailed questions about coding style and design. BUT...such questions seem really appropriate for an office-hours type of discussion. I'll happily offer my office hours -- currently 7:30 AM Pacific on Mondays -- to field such questions. Q On Jun 19, 2008, at 1:51 PM, Dale Mahalko wrote: > Cross-posting from the Open Source Meeting Agenda page: > > > How do you (Rob / LL staff / and the rest of the SL-Dev professionals) > feel about relative C++ noobs (*waves!*) jumping headfirst into the > client source to explore it? Do you prefer that only people with years > of prior C++ experience try to be involved with the open source > project? ("Come back when you've actually used a multimap in a > program!") > > I am wondering if showing up at the open source meeting and asking > what may seem as "stupid beginner's questions" would be perceived as > annoying and a waste of your / LL-Staffs' professional time. (For > example, why is ll_apr_file used for open/read/write/etc rather than > just apr_file? Is llapr.cpp a shim library, to make transitioning from > the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't > find any official coding policy or notes pointing in that direction. > Is it okay to discuss this in SLDev or not?) > > My interest and involvement in the source is mostly because I want the > VFS expunged, and the overall caching performance improved... but > since this coding task is apparently not high on anyone else's agenda, > I guess there's room for a QBASIC / LSL2 / Apple II 6502-assembly > programmer to explore the issue. (Note, the only thing I've ever > threaded is a needle.) > > - Scalar Tardis / Dale Mahalko > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tongb at ohio.edu Thu Jun 19 12:16:50 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 19 12:16:53 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com> References: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com> Message-ID: <4f335a50806191216y4c825006q8bb70b0d9435ac3f@mail.gmail.com> Oh sure, I agree with you about big live meetings. My reply was mostly towards his question about if those were appropriate for SLDev. I'm new to this list, but it seemed that since it didn't always talk about code, that what he described seemed in bounds to me. On Thu, Jun 19, 2008 at 2:53 PM, Kent Quirk (Q Linden) wrote: > I'm going to jump in and suggest that the big-picture OS discussion on > Thursdays probably doesn't want to include detailed questions about coding > style and design. > > BUT...such questions seem really appropriate for an office-hours type of > discussion. > > I'll happily offer my office hours -- currently 7:30 AM Pacific on Mondays > -- to field such questions. > > Q > > > On Jun 19, 2008, at 1:51 PM, Dale Mahalko wrote: > >> Cross-posting from the Open Source Meeting Agenda page: >> >> >> How do you (Rob / LL staff / and the rest of the SL-Dev professionals) >> feel about relative C++ noobs (*waves!*) jumping headfirst into the >> client source to explore it? Do you prefer that only people with years >> of prior C++ experience try to be involved with the open source >> project? ("Come back when you've actually used a multimap in a >> program!") >> >> I am wondering if showing up at the open source meeting and asking >> what may seem as "stupid beginner's questions" would be perceived as >> annoying and a waste of your / LL-Staffs' professional time. (For >> example, why is ll_apr_file used for open/read/write/etc rather than >> just apr_file? Is llapr.cpp a shim library, to make transitioning from >> the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't >> find any official coding policy or notes pointing in that direction. >> Is it okay to discuss this in SLDev or not?) >> >> My interest and involvement in the source is mostly because I want the >> VFS expunged, and the overall caching performance improved... but >> since this coding task is apparently not high on anyone else's agenda, >> I guess there's room for a QBASIC / LSL2 / Apple II 6502-assembly >> programmer to explore the issue. (Note, the only thing I've ever >> threaded is a needle.) >> >> - Scalar Tardis / Dale Mahalko >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Thu Jun 19 12:19:29 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 19 12:19:38 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: References: Message-ID: On Thu, Jun 19, 2008 at 12:51 PM, Dale Mahalko wrote: > > I am wondering if showing up at the open source meeting and asking > what may seem as "stupid beginner's questions" would be perceived as > annoying and a waste of your / LL-Staffs' professional time. (For > example, why is ll_apr_file used for open/read/write/etc rather than > just apr_file? Is llapr.cpp a shim library, to make transitioning from > the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't > find any official coding policy or notes pointing in that direction. > Is it okay to discuss this in SLDev or not?) If you ask questions on-list, the question's likely to be forwarded to the person who knows the system best if they're not already subscribed. If you ask in a meeting, odds are it goes nowhere if the person who owns a system isn't there. Please don't be discouraged from diving into the source wtih any level of experience. If you worry that a question might be distracting or too basic, be sure it's in its own thread. If you want to be sure you're contributing from the start, you can always offer to document what you learn on the wiki. From rdw at lindenlab.com Thu Jun 19 12:20:41 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Jun 19 12:20:43 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: <4f335a50806191216y4c825006q8bb70b0d9435ac3f@mail.gmail.com> References: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com> <4f335a50806191216y4c825006q8bb70b0d9435ac3f@mail.gmail.com> Message-ID: <485AB189.6050404@lindenlab.com> Bruce Tong wrote: > Oh sure, I agree with you about big live meetings. My reply was mostly > towards his question about if those were appropriate for SLDev. I'm > new to this list, but it seemed that since it didn't always talk about > code, that what he described seemed in bounds to me. > > I would certainly prefer code-related discussions on this list, dumb or not, to policy-related discussions, smart or not. :-) -RYaN From soft at lindenlab.com Thu Jun 19 12:22:32 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 19 12:22:35 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: <485AB189.6050404@lindenlab.com> References: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com> <4f335a50806191216y4c825006q8bb70b0d9435ac3f@mail.gmail.com> <485AB189.6050404@lindenlab.com> Message-ID: On Thu, Jun 19, 2008 at 2:20 PM, Ryan Williams (Which) wrote: > > I would certainly prefer code-related discussions on this list, dumb or not, > to policy-related discussions, smart or not. :-) rdw++ From daveh at lindenlab.com Thu Jun 19 12:23:28 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Thu Jun 19 12:23:32 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: <485AB189.6050404@lindenlab.com> References: <36F03687-6567-4A30-8184-6D583D67C177@lindenlab.com><4f3 35a50806191216y4c825006q8bb70b0d9435ac3f@mail.gmail.com> <485AB189.6050404@lindenlab.com> Message-ID: +1 This is a very atypical development list, usually development lists are full of technical questions. On 19 Jun 2008, at 20:20, Ryan Williams (Which) wrote: > Bruce Tong wrote: >> Oh sure, I agree with you about big live meetings. My reply was >> mostly >> towards his question about if those were appropriate for SLDev. I'm >> new to this list, but it seemed that since it didn't always talk >> about >> code, that what he described seemed in bounds to me. >> >> > I would certainly prefer code-related discussions on this list, dumb > or not, to policy-related discussions, smart or not. :-) > > -RYaN > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From robla at lindenlab.com Thu Jun 19 12:44:39 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 19 12:44:46 2008 Subject: [sldev] [Policy] C++ N00bs exploring the client source code? In-Reply-To: References: Message-ID: <485AB727.3080702@lindenlab.com> On 6/19/08 10:51 AM, Dale Mahalko wrote: > How do you (Rob / LL staff / and the rest of the SL-Dev professionals) > feel about relative C++ noobs (*waves!*) jumping headfirst into the > client source to explore it? Do you prefer that only people with years > of prior C++ experience try to be involved with the open source > project? ("Come back when you've actually used a multimap in a > program!") > Hi Dale, Please jump in! Objective questions about how stuff works are very welcome, and as long as it's clear you've made a little effort to find the answer on your own before getting on list, I don't think anyone has a right to get upset about it. Special bonus points for saying "I looked for this information here (), but didn't find what I was expecting"....and then after the thread concludes, document what you learned. You'll especially endear yourself to the seasoned devs here if you do that, and are more likely to get quick answers if you get a reputation for being a good documentation writer. Suggestions for architectural directions are more controversial if you're not seasoned with the code. My personal view is that these can be ok too, but there needs to be an escape valve for the conversation. That's where the list guidelines about redirecting long threads to some other place (JIRA, Wiki or otherwise) become really important. The person starting the thread is in the best position to find the right offlist home for the conversation, so picking a good place before even starting the thread (and putting it in the initial post) is greatly appreciated. On questions of policy, it's much more important to go offlist fast, because many people here are really, really tired of seeing an allegedly development-oriented list dominated by policy talk. In the name of practicing what I preach, I think it'd be good to continue this conversation here: https://wiki.secondlife.com/wiki/Talk:SLDev You asked an interesting question buried in your original mail that I'm going to reply to under separate cover. > My interest and involvement in the source is mostly because I want the > VFS expunged, and the overall caching performance improved... but > since this coding task is apparently not high on anyone else's agenda, > I guess there's room for a QBASIC / LSL2 / Apple II 6502-assembly > programmer to explore the issue. (Note, the only thing I've ever > threaded is a needle.) > This sort of thing is the type of thing that we've discussed a lot already, and can be discussed more here: http://wiki.secondlife.com/wiki/Talk:VFS Rob From robla at lindenlab.com Thu Jun 19 13:21:04 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 19 13:21:08 2008 Subject: [sldev] Why ll_apr_file rather than apr_file? (was: Re: C++ N00bs exploring the client source code?) In-Reply-To: References: Message-ID: <485ABFB0.6060106@lindenlab.com> On 6/19/08 10:51 AM, Dale Mahalko wrote: > I am wondering if showing up at the open source meeting and asking > what may seem as "stupid beginner's questions" would be perceived as > annoying and a waste of your / LL-Staffs' professional time. (For > example, why is ll_apr_file used for open/read/write/etc rather than > just apr_file? Is llapr.cpp a shim library, to make transitioning from > the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't > find any official coding policy or notes pointing in that direction. > Is it okay to discuss this in SLDev or not?) > Yes, this is fine to discuss here, especially if you document what you learn here: http://wiki.secondlife.com/wiki/Apache_Portable_Runtime I'm not sure why we have a wrapped version of apr_file, but I'm hoping the different subject line will get the right person's attention. Rob From lenglish5 at cox.net Thu Jun 19 13:39:32 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 19 13:39:34 2008 Subject: [sldev] [AWG] Test harness meeting at zero's went nicely. Message-ID: <485AC404.70603@cox.net> The first full-blown meeting on the test harness was held at Zero's office hours while he's on vacation. https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_June_19 Webpage: https://wiki.secondlife.com/wiki/AWG_Test_Harness irc: irc://irc.freenode.net/#pyogp chalogs: https://wiki.secondlife.com/wiki/AWG_Test_Harness#Related_Chat_Logs I'm the least knowledgeable person about this stuff, but have the most time on my hands, so I'll be at the Open Source meeting today to try to answer questions if there are any. Lawson (Saijanaia Kuhn) From carjay at gmx.net Thu Jun 19 15:24:15 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Jun 19 15:24:24 2008 Subject: [sldev] [VWR] What are the plans for LLLFSThread? Message-ID: <485ADC8F.1080908@gmx.net> Both llaudiodecodemgr.cpp and lltexturecache.cpp feature some code that uses the LLLFSThread class ("threaded local file system"). But in both cases there are defines which currently disable it in favour of alternative calls. We talked about it at the last open office meeting but seems noone present at the time knew much about it. So I wonder if anyone else has a clue what is planned with that class? Is it going to be removed or did someone push it on his "ToDo" list so we might see it getting reactivated at some point? If you want to check, look for USE_LFS_WRITE and USE_LFS_READ in the texture cache code and USE_WAV_VFILE in the audio decode manager Carsten From ye.yearn at gmail.com Thu Jun 19 21:21:56 2008 From: ye.yearn at gmail.com (En Ye) Date: Thu Jun 19 21:22:00 2008 Subject: [sldev] A fatal error when running the complied SL client Message-ID: <59a0b1a00806192121s11146840u3bd287c7ab2cc618@mail.gmail.com> Hi, there, I built SL 1.20(5) (using ReleaseNoOpt configuration) using Visual Studio 2005 under Vista Home Premium successfully, however, when I tried running it, I encounter a fatal error "LLImageGL::createGLTexture failed to make texture". Is there anyone who knows how to solve this problem? Thanks in advance for any help. Best, En -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080620/8b86ee2e/attachment-0001.htm From thomas.shikami at online.de Fri Jun 20 11:38:28 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Fri Jun 20 11:38:31 2008 Subject: [sldev] A fatal error when running the complied SL client In-Reply-To: <59a0b1a00806192121s11146840u3bd287c7ab2cc618@mail.gmail.com> References: <59a0b1a00806192121s11146840u3bd287c7ab2cc618@mail.gmail.com> Message-ID: <485BF924.4050807@online.de> try deleting or renaming llkdu.dll En Ye wrote: > Hi, there, > > I built SL 1.20(5) (using ReleaseNoOpt configuration) using Visual > Studio 2005 under Vista Home Premium successfully, however, when > I tried running it, I encounter a fatal error > "LLImageGL::createGLTexture failed to make texture". Is there anyone > who knows how to solve this problem? Thanks in advance for any help. From seg at haxxed.com Fri Jun 20 21:47:19 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 20 21:47:22 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <061120081755.14074.485011AA000933BB000036FA221558639404040A990B040E0CA1020A079D0E0B@comcast.net> References: <061120081755.14074.485011AA000933BB000036FA221558639404040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: <1218b5bc0806202147i23a3468fg4ab2f2d3f6d342ba@mail.gmail.com> On Wed, Jun 11, 2008 at 12:55 PM, wrote: > On a related note, I would like to ask Linden Lab, if a better cache system > was developed by someone for inclusion in the viewer, what is the likelihood > that such a patch would be accepted? Is LL willing to do any/some/all of the > things suggested or is all this discussion for naught? Are there any hard > requirements to make a new cache system acceptable for the production > viewer, or any things which would absolutely preclude a particular cache > system from being accpeted? A better cache system has already been developed. It's called HTTP. I think I finally wrapped my brain around REST. Its 'everything is a file' reinvented for the age of ubiquitous internet connectivity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080620/49f0a63a/attachment.htm From seg at haxxed.com Fri Jun 20 22:29:58 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 20 22:30:00 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> Message-ID: <1218b5bc0806202229q1ecc5ec2x826f6a4f59a3637c@mail.gmail.com> On Thu, Jun 12, 2008 at 5:42 AM, Dale Mahalko wrote: > And how does Profoky Neva feel about this issue? Oh look, here's a > blog post about this very sl-dev thread. It's too bad Profoky isn't > interested in particupating directly, but here's a link so Profoky > views can be included. Warning, strong language and high emotion. > > I think she is a little upset about this discussion, and in particular > with Giglio's cavalier opinions about intellectual property. > > June 09, 2008: How They Talk About You: "I tire of people moaning > about IP security" > > http://secondthoughts.typepad.com/second_thoughts/2008/06/how-they-talk-a.html Why do people listen to that lunatic? He calls us "arrogant coder fucks" then expects us to listen to him. Sorry, solid engineering practice is not a democracy, and we really have better things to do than teach Software Engineering 101 to every loudmouth that comes along. Patch or GTFO. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/737ee638/attachment.htm From seg at haxxed.com Fri Jun 20 23:12:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 20 23:12:46 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> On Mon, Jun 9, 2008 at 5:34 PM, Jake Simpson wrote: > I'd just like to make the point that a lot of LL reads these threads and we > have lots of internal discussions about exactly stuff like this. We have one > currently going regarding a feature we are talking about adding thats very > much along these lines. > > "How far do we go to obstrufacate the data stream?" is the question. I may be late to the party here, but mark my words, if the cache is changed to anything other than plain, complete files in a standard file format, it will be the final nail in the coffin for my already tenuous faith in Linden Lab's collective engineering sense. Also note, if we're going to do the uncompressed cache thing, XORing the file will eliminate the possibility of zero-copy DMAing of the texture directly from disk into VRAM. XOR is still more overhead than having the texture not hit the processor at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/4f31ee6a/attachment.htm From GordonWendt at gmail.com Fri Jun 20 23:22:09 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Jun 20 23:32:12 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <1218b5bc0806202229q1ecc5ec2x826f6a4f59a3637c@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> <4850E9E4.50408@gmail.com> <1218b5bc0806202229q1ecc5ec2x826f6a4f59a3637c@mail.gmail.com> Message-ID: <493033a70806202322g461daa5bw3844b0695ebe601d@mail.gmail.com> He is a she, and it's ironic that her name be brought up here considering that she has many times derided this very list as being full of "arrogant coder fucks" and JIRA users as "opensource freaks" but I digress although I disagree with your Patch or GTFO statement since I never submit code or generally look at patches that are submitted or referenced since I'll admit to not being a coder but I have an inherent issue in the technological development of the platform as a user of said platform and as one who seems to get repeatedly screwever over whoever gets their way whether it be those who keep getting the ui crippled or those who want to redefine how the viewer and the server communicate (again). -G.W. On Sat, Jun 21, 2008 at 1:29 AM, Callum Lerwick wrote: > On Thu, Jun 12, 2008 at 5:42 AM, Dale Mahalko wrote: > >> And how does Profoky Neva feel about this issue? Oh look, here's a >> blog post about this very sl-dev thread. It's too bad Profoky isn't >> interested in particupating directly, but here's a link so Profoky >> views can be included. Warning, strong language and high emotion. >> >> I think she is a little upset about this discussion, and in particular >> with Giglio's cavalier opinions about intellectual property. >> >> June 09, 2008: How They Talk About You: "I tire of people moaning >> about IP security" >> >> http://secondthoughts.typepad.com/second_thoughts/2008/06/how-they-talk-a.html > > > Why do people listen to that lunatic? > > He calls us "arrogant coder fucks" then expects us to listen to him. Sorry, > solid engineering practice is not a democracy, and we really have better > things to do than teach Software Engineering 101 to every loudmouth that > comes along. > > Patch or GTFO. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/362f7e02/attachment.htm From secret.argent at gmail.com Sat Jun 21 13:14:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 21 13:12:56 2008 Subject: [sldev] How Far For Security? In-Reply-To: <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> Message-ID: On 2008-06-21, at 01:12, Callum Lerwick wrote: > I may be late to the party here, but mark my words, if the cache is > changed to anything other than plain, complete files in a standard > file format, it will be the final nail in the coffin for my already > tenuous faith in Linden Lab's collective engineering sense. Even if a non-standard format that's a serialization of the internal structures is faster and more efficient? There's no solid engineering reason to go with a standard file format for a *cache*. > Also note, if we're going to do the uncompressed cache thing, > XORing the file will eliminate the possibility of zero-copy DMAing > of the texture directly from disk into VRAM. XOR is still more > overhead than having the texture not hit the processor at all.\ The Amiga did MFM decoding on the blitter, and that had a fraction of the versatility of any modern GPU, there's no reason that the GPU can't do any operations needed to remove obfuscation. I happen to agree that there's probably no need for obfuscation beyond just not using a standard format, I proposed XOR as the cheapest possible concession to obfuscation, and I'm not going to argue hard at all to keep it... but there's no need to make up arguments like that against it, because there's all KINDS of problems that have to be solved to get anywhere near that kind of solution. Is there even a usermode API for that in any modern OS, or would you have to ship device drivers with SL and make SL bypass local user permissions in the OS? From lenglish5 at cox.net Sat Jun 21 13:56:21 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 21 13:56:23 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> Message-ID: <485D6AF5.5050007@cox.net> Argent Stonecutter wrote: > On 2008-06-21, at 01:12, Callum Lerwick wrote: >> I may be late to the party here, but mark my words, if the cache is >> changed to anything other than plain, complete files in a standard >> file format, it will be the final nail in the coffin for my already >> tenuous faith in Linden Lab's collective engineering sense. > > Even if a non-standard format that's a serialization of the internal > structures is faster and more efficient? > > There's no solid engineering reason to go with a standard file format > for a *cache*. > >> Also note, if we're going to do the uncompressed cache thing, XORing >> the file will eliminate the possibility of zero-copy DMAing of the >> texture directly from disk into VRAM. XOR is still more overhead than >> having the texture not hit the processor at all.\ > > The Amiga did MFM decoding on the blitter, and that had a fraction of > the versatility of any modern GPU, there's no reason that the GPU > can't do any operations needed to remove obfuscation. > > I happen to agree that there's probably no need for obfuscation beyond > just not using a standard format, I proposed XOR as the cheapest > possible concession to obfuscation, and I'm not going to argue hard at > all to keep it... but there's no need to make up arguments like that > against it, because there's all KINDS of problems that have to be > solved to get anywhere near that kind of solution. Is there even a > usermode API for that in any modern OS, or would you have to ship > device drivers with SL and make SL bypass local user permissions in > the OS? Given The low-end for the GPU is a Geforce 2, you'd have to decide what facilities were available for that level. And I think deliberate low-level obfuscation should take a backburner to improvements in speed. It may turn out that the most effective simple optimizations for texture-handling in the cache will provide sufficient "bozo-bit" type obfuscation (for those that remember the file flag in the original Mac OS that simply told the GUI to not allow drag copying of files via file icons) that we need not worry about it at all. All we need, is a way to make it non-transparent to casual explorers, how to extract the textures. Anything more than that will be a losing battle because there's always someone who will be willing to create a utility to break the "copy protection," no matter how involved we're willing to get. If our simple "protection scheme" actually results in a speedup of the system, so much the better and I think THAT should be the go: optimize the cache handling in the best way we can find without getting TOO fancy (because that becomes system-dependent, and keep an eye out for viable solutions that add a tad of obfuscation while we're at it. My intuition says we'll probably find that the best optimization solution will provide the desired level of obfuscation as a side-effect. Lawson From ye.yearn at gmail.com Sat Jun 21 14:52:10 2008 From: ye.yearn at gmail.com (En Ye) Date: Sat Jun 21 14:52:13 2008 Subject: [sldev] A fatal error when running the complied SL client In-Reply-To: <485BF924.4050807@online.de> References: <59a0b1a00806192121s11146840u3bd287c7ab2cc618@mail.gmail.com> <485BF924.4050807@online.de> Message-ID: <59a0b1a00806211452t62d9d5ccg2eee87931e30a84e@mail.gmail.com> There are two llkdu.dll. I tried deleting either one or both, but still had the same error. Any other thoughts? Thanks, En On Fri, Jun 20, 2008 at 2:38 PM, Thomas Shikami wrote: > try deleting or renaming llkdu.dll > > En Ye wrote: > >> Hi, there, >> I built SL 1.20(5) (using ReleaseNoOpt configuration) using Visual Studio >> 2005 under Vista Home Premium successfully, however, when I tried running >> it, I encounter a fatal error "LLImageGL::createGLTexture failed to make >> texture". Is there anyone who knows how to solve this problem? Thanks in >> advance for any help. >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/51caa8e0/attachment.htm From ravenglassrentals at yahoo.com Sat Jun 21 15:01:30 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Sat Jun 21 15:01:35 2008 Subject: [sldev] Re: Software Engineers Not A Democracy? Who Says? In-Reply-To: <20080621190025.1151C41B1B6@stupor.lindenlab.com> Message-ID: <93973.99430.qm@web55608.mail.re4.yahoo.com> I should think that anyone who says "software engineering is not a democracy" and "patch or GTFO" might have earned some of the labels with the word "arrogant" that have been used to describe them on blogs. They are a living, walking example of the problem. Software engineering *better be* a democracy when it affects people in a world who pay tier or else those people cannot be persuaded to remain in a project and keep paying for them to have a sandbox. I often find a high-handed dismissal of non-engineer, non-coder participation in SL Dev and in certain AWG office hours, as if these issues are purely technical. They aren't. Under the guise of "technicality," these coders are trying to take over complex and diverse political, social, and economic issues that have profound consequences for people in this virtual world, their property, and even their real-life earnings. I fail to see why any one of us with intellectual property, or a financial stake in Second Life, must be forced to cede absolute control over these aspects of our second lives to coders, especially arrogant coders, and especially coders who have a very, very sectarian and extremist copyleftist, freetard view of IP issues. No one's RL gender should be disclosed within the SL domain. That's a TOS regulation. If it is not on the SL profile, it is not fair game for lists, forums, the official blog etc *regardless if the information is obtainable by Google witch-hunting on the Internet*. It's also immaterial to any discussion, what a RL gender is. People who are not engineers and software programmers are also participating in this list. And what I find interesting is that some of those with the very strongest opinions who *are* programmers are not programmers *in these languages*, by their own admission, or who don't have knowledge or experience in VW engineering, by their own admission, and yet have highly emotional views on what LL should or shouldn't do. Giglio's views of IP are indeed cavalier, as are others. They do not reflect the mainstream of views even within Linden Lab, let alone the general population. Nothing about us/without us. Random Unsung/Prokofy Neva My alt name on here is my well-known alt, and isn't some disguise, but merely a wish to have all the prolific email from this list not go into my main account which is cluttered enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/02858b2d/attachment.htm From sldev at bitparts.org Sat Jun 21 15:43:19 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 21 15:43:27 2008 Subject: [sldev] Re: Software Engineers Not A Democracy? Who Says? In-Reply-To: <93973.99430.qm@web55608.mail.re4.yahoo.com> References: <93973.99430.qm@web55608.mail.re4.yahoo.com> Message-ID: <485D8407.8090504@bitparts.org> Is it possible to lock a thread in a mailing list? :P Please, all of this is offtopic (the guy you're responding too, as well), and will only generate tons of opinion spam. Please take it off-list. Random Unsung wrote: > I should think that anyone who says "software engineering is not a > democracy" and "patch or GTFO" might have earned some of the labels > with the word "arrogant" that have been used to describe them on > blogs. They are a living, walking example of the problem. > From seg at haxxed.com Sat Jun 21 16:33:14 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 21 16:33:16 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> Message-ID: <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter wrote: > On 2008-06-21, at 01:12, Callum Lerwick wrote: > >> I may be late to the party here, but mark my words, if the cache is >> changed to anything other than plain, complete files in a standard file >> format, it will be the final nail in the coffin for my already tenuous faith >> in Linden Lab's collective engineering sense. >> > > Even if a non-standard format that's a serialization of the internal > structures is faster and more efficient? Until you have to change the internal structures and suddenly your cache needs to be wiped and re-filled. Which would defeat the purpose of the cache. To avoid this you have to abstract your internal structures from the on disk format, and if you're going to do that, you might as well use a pre-existing standard. There's plenty to choose from already. And as noted, there's already TGA reading code in the viewer. There's no solid engineering reason to go with a standard file format for a > *cache*. > Seriously, have we not been bitten by lack of engineering foresight in SL infrastructure enough as it is? Why do I even have to explain this? Also note, if we're going to do the uncompressed cache thing, XORing the >> file will eliminate the possibility of zero-copy DMAing of the texture >> directly from disk into VRAM. XOR is still more overhead than having the >> texture not hit the processor at all.\ >> > > The Amiga did MFM decoding on the blitter, and that had a fraction of the > versatility of any modern GPU, there's no reason that the GPU can't do any > operations needed to remove obfuscation. Except that programmable cards only do FP, not integer/binary operations like XOR. And shaderless cards are still in wide use, not to mention bugs in shader implementations are still widespread, and the open source r300 drivers for one still don't support shaders. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/f89d526e/attachment-0001.htm From nik at terminaldischarge.net Sat Jun 21 16:39:59 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Sat Jun 21 16:40:18 2008 Subject: [sldev] How Far For Security? In-Reply-To: <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> Message-ID: <485D914F.3080704@terminaldischarge.net> Callum Lerwick wrote: > On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter > > wrote: > > On 2008-06-21, at 01:12, Callum Lerwick wrote: > > I may be late to the party here, but mark my words, if the > cache is changed to anything other than plain, complete files > in a standard file format, it will be the final nail in the > coffin for my already tenuous faith in Linden Lab's collective > engineering sense. > > > Even if a non-standard format that's a serialization of the > internal structures is faster and more efficient? > > > Until you have to change the internal structures and suddenly your > cache needs to be wiped and re-filled. Which would defeat the purpose > of the cache. To avoid this you have to abstract your internal > structures from the on disk format, and if you're going to do that, > you might as well use a pre-existing standard. There's plenty to > choose from already. And as noted, there's already TGA reading code in > the viewer. > > There's no solid engineering reason to go with a standard file > format for a *cache*. > > > Seriously, have we not been bitten by lack of engineering foresight in > SL infrastructure enough as it is? > > Why do I even have to explain this? > > Also note, if we're going to do the uncompressed cache thing, > XORing the file will eliminate the possibility of zero-copy > DMAing of the texture directly from disk into VRAM. XOR is > still more overhead than having the texture not hit the > processor at all.\ > > > The Amiga did MFM decoding on the blitter, and that had a fraction > of the versatility of any modern GPU, there's no reason that the > GPU can't do any operations needed to remove obfuscation. > > > Except that programmable cards only do FP, not integer/binary > operations like XOR. And shaderless cards are still in wide use, not > to mention bugs in shader implementations are still widespread, and > the open source r300 drivers for one still don't support shaders. > So XORing and image provides a minimal overhead and only has to be applied once per texture. Would that be so detrimental to performance. Surely you can understand why some obsfucation is needed even if it's minimal and can easily be broken by anyone with the inclination and will to do so? > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080622/f6ec78fe/attachment.htm From secret.argent at gmail.com Sat Jun 21 18:25:06 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 21 18:23:29 2008 Subject: [sldev] How Far For Security? In-Reply-To: <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> Message-ID: <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> On 2008-06-21, at 18:33, Callum Lerwick wrote: > On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter > wrote: >>> On 2008-06-21, at 01:12, Callum Lerwick wrote: >>> I may be late to the party here, but mark my words, if the cache >>> is changed to anything other than plain, complete files in a >>> standard file format, it will be the final nail in the coffin for >>> my already tenuous faith in Linden Lab's collective engineering >>> sense. >> Even if a non-standard format that's a serialization of the >> internal structures is faster and more efficient? > Until you have to change the internal structures and suddenly your > cache needs to be wiped and re-filled. Um, it's a cache. It's not a big deal if it gets wiped and refilled after an upgrade of the viewer. In fact some viewer upgrades have routinely wiped the cache, and almost nobody even noticed. Did you? Changes in format happen at most once every few months. The current cache turns over in minutes in some areas. A huge speedup in cache performance in exchange for *fewer* cache flushes seems a pretty reasonable tradeoff... heck, it's not a trade-off at all. >> There's no solid engineering reason to go with a standard file >> format for a *cache*. > Seriously, have we not been bitten by lack of engineering foresight > in SL infrastructure enough as it is? Yep. Using a standard file format for the cache is one of the examples: it's added complication to the cache and slowed it down and is the reason for this discussion. And I'd really like to see how you are proposing SL request a direct disk-to-GPU transfer without writing your own driver. From soft at lindenlab.com Sat Jun 21 18:26:28 2008 From: soft at lindenlab.com (Soft) Date: Sat Jun 21 18:26:32 2008 Subject: [sldev] Re: Software Engineers Not A Democracy? Who Says? In-Reply-To: <93973.99430.qm@web55608.mail.re4.yahoo.com> References: <20080621190025.1151C41B1B6@stupor.lindenlab.com> <93973.99430.qm@web55608.mail.re4.yahoo.com> Message-ID: On Sat, Jun 21, 2008 at 5:01 PM, Random Unsung wrote: > > I often find a high-handed dismissal of non-engineer, non-coder > participation in SL Dev and in certain AWG office hours, as if these issues > are purely technical. They aren't. Under the guise of "technicality," these > coders are trying to take over complex and diverse political, social, and > economic issues that have profound consequences for people in this virtual > world, their property, and even their real-life earnings. sldev is a technical forum for open source development. The AWG office hours are a technical forum for interoperability planning. Neither is a community or legal forum. If you believe decisions in one forum or the other overstep the domain of that forum - as they sometimes do - by all means, point it out and encourage people to raise the issue in the appropriate place. If debate persists, post a reminder or two. People may not realize that there are other office hours, lists, or wiki discussions that would be more appropriate. Please do not join the push to turn every last forum into a space for policy debate. It's ineffectual. The people who need convincing aren't a part of this list. It's also disruptive. Moving the list away from engineering issues is guaranteed to turn engineers within and without away from the list, and it's guaranteed to keep things from Getting Done. From Celierra at gmail.com Sat Jun 21 18:36:08 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sat Jun 21 18:36:11 2008 Subject: [sldev] How Far For Security? In-Reply-To: <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> References: <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> Message-ID: On Sat, Jun 21, 2008 at 7:33 PM, Callum Lerwick wrote: > On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter > wrote: >> Even if a non-standard format that's a serialization of the internal >> structures is faster and more efficient? > > Until you have to change the internal structures and suddenly your cache > needs to be wiped and re-filled. Which would defeat the purpose of the > cache. I think that the cache is mostly just to tide things over from one session to the next. If we suppose that people don't upgrade their viewer far more often than people upgrade it (a reasonable assumption), then the cache is doing its job the vast majority of the time, even if it were cleared at every upgrade. I doubt that such cache clears would be a significant source of cache misses, compared to, say, capacity misses after hopping around a few densely-textured areas. For fun, the extensibility of TIFF looks like it can be abused to hold a bunch of serialized stuff in addition to raw image data, and you could massage it so that standard image apps can't read the important stuff. For further cruelty, you could put serialized junk where TIFF would expect image data and have the real data in such tags, and it might still be considered a valid TIFF. ;) (Okay, so this probably isn't what you mean by "standard file format"...) Cel From whitequill.bj at gmail.com Sat Jun 21 19:05:56 2008 From: whitequill.bj at gmail.com (Bj Raz) Date: Sat Jun 21 19:06:00 2008 Subject: [sldev] Fwd: ISO MPEG-V In-Reply-To: <483C95DB.7010409@cox.net> References: <3e3ef2f00805260240ge10e16fm416ec595f5a40d93@mail.gmail.com> <3e3ef2f00805260241h3569fdfawc0b9769ed631c9d2@mail.gmail.com> <483C1FE1.2000900@openmv.org> <483C527E.2070504@gmail.com> <483C7623.8050208@gmail.com> <483C95DB.7010409@cox.net> Message-ID: I sent the "SL > WoW > IMVU" diagram to a single person verses the thread by accident. As something I could see as a perspective future, of the standard, and the simplistic pictogram from the PDF. It didn't seem imposable with the current technologies we have available to us at this time as well. If the ability to unite avatars into SL is outside the realm of current possibilities, please discount the whole idea. Though it seems far-fetched, it (to me) does not seem out side of our reach. Where can SL go if not out? It is open source, the devs can help and other platforms can too if LL and we can help the the virtual and real world see the extreme potential of Second Life, it can become I see, what none of us can or will ever imagine. Voluntary integration will be needed, not force to the industry to conform to Second Life. They will have to see the potential, they will have to come to us. Though we can advertise SL as a platform to integrate into. To develop into an industry standard platform where an avatar can cross into another world. From its origin, and back again. This is all I can see, I can not tell how, or when, just that if it can happen it will. That is all. BjRazzz Qinan On Tue, May 27, 2008 at 7:14 PM, Lawson English wrote: > Jason Giglio wrote: > >> Timeless Prototype wrote: >> >> >>> Maybe I'm just cynical today, but is this whole MPEG-V thing just a way >>> to make money from royalties/licensing by documenting protocols that >>> ultimately someone else developed and implemented beforehand? >>> >>> - Timeless >>> >>> >> >> I'm sure they also have higher goals, like ensuring that all content is >> "protected" by DRM in the future. >> >> -Jason >> >> > > Well, the MPEG-21 doesn't require that, so I doubt they do either. > > Lawson > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/bc4ba752/attachment.htm From blindwanderer at gmail.com Sat Jun 21 23:32:23 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sat Jun 21 23:32:27 2008 Subject: [sldev] How Far For Security? In-Reply-To: <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> Message-ID: <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> On Sat, Jun 21, 2008 at 9:25 PM, Argent Stonecutter wrote: > And I'd really like to see how you are proposing SL request a direct > disk-to-GPU transfer without writing your own driver. *sigh* You couldn't go straight from disk to GPU. There is no interface that connects the GPU to the disk. What you would do is write your program to make the appropriate requests to read a file into memory. The disk drive would be told where to read, and to use DMA to write the data directly to an already allocated memory range (the North Bridge would route the incoming data straight to memory). Once it was in memory the program would then tell the GPU what memory range to read and how to treat that range. The GPU would then request that memory and the North Bridge would send it along, again bypassing the CPU. Now to confuse things, in new CPU's (made in the last couple years) the memory controller has been integrated into the CPU though it is still separate from the actual part of the CPU that executes instructions. All of this is cleverly hidden and negotiated by the operating system and the BIOS; it's done this way so the programmer never need get their hands dirty with hardware specific code, that has been taken care of by the hardware manufacturers and operating system developers. By having the hardware properly obscured by a common API the programmer can write portable code with limited worry about the hardware the software is going to run on. This problem has already been solved, it's pretty much a non-issue. http://en.wikipedia.org/wiki/Northbridge_(computing) From secret.argent at gmail.com Sun Jun 22 05:14:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 22 05:13:07 2008 Subject: [sldev] How Far For Security? In-Reply-To: <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> Message-ID: <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> On 2008-06-22, at 01:32, Strife Onizuka wrote: > You couldn't go straight from disk to GPU. There is no interface that > connects the GPU to the disk. What you would do is write your program > to make the appropriate requests to read a file into memory. The disk > drive would be told where to read, and to use DMA to write the data > directly to an already allocated memory range (the North Bridge would > route the incoming data straight to memory). I'm not asking "does the hardware exist", I'm asking "does the OS API exist"? You have to make zero-copy transfers to memory at specific *physical* addresses, bypassing the ubiquitous buffer cache which *is* handled by the CPU. This kind of thing normally requires at the least privileged access, and probably kernel access, on any OS that makes even the slightest effort of implementing multiuser protection. Does Windows really allow non-privileged processes to grovel around in memory maps? From secret.argent at gmail.com Sun Jun 22 09:21:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 22 09:19:34 2008 Subject: [sldev] Comments on the Texture Cache page in the Wiki. In-Reply-To: <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> Message-ID: <3819933A-B40E-4CFF-8EC3-7F340E0DA8D1@gmail.com> This page seems to describe a far more detailed plan that I recall from the discussion on SLDev. In particular, the proposed scheme for tracking multiple formats in the texture cache seems overly complex... at least as a first step. The page also seems to demand more obfuscation than is necessary. It also involves retaining a number of inefficiencies from the existing cache. The simplest solution would be a separate cache for completely downloaded textures. This cache would be checked before the existing cache, and contain nothing but a serialized version of the internal cache structures and data, in whatever format can be quickly read and written. This format may involve multiple files per UUID if that is more efficient. The files are stored using a multi-level directory tree based only on the UUID of the file. The exact details of this tree are dependent on the UUID, but it would be uniquely derived from the UUID. There is no cache index file. Checking this cache would simply involve attempting to open the (main) file by UUID and reading a short header containing version information. If the version matches, the rest of the file is loaded and deserialized. If not, the file(s) are deleted and the existing path would continue to be followed via the existing cache. Filling this cache would happen whenever a texture was completely loaded from the existing texture path. The serialized texture would be saved to a file by UUID, and the corresponding texture would be deleted from the existing texture cache. The existing texture cache would then only contain incompletely downloaded textures. https://wiki.secondlife.com/wiki/SLDEV_Discussion_- _Texture_Cache_Plan_of_Attack From schlenk at uni-oldenburg.de Sun Jun 22 13:18:15 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sun Jun 22 13:18:16 2008 Subject: [sldev] Using OS X Image I/O for jpeg200 handling? Message-ID: <485EB387.5060305@uni-oldenburg.de> Hi all, just wondered if it would be worth the time to investigate Apples Image I/O Framework for jpeg2000 handling for the open source viewer on OS X. Its basically the kakadu lib shipped with Apples OS, so should be better than libjpeg. (at least according to a comment in http://www.wilshipley.com/blog/2005/09/jpeg2000-cool-but-slow.html ) Has there been any work in that direction? Michael From blindwanderer at gmail.com Sun Jun 22 16:08:33 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sun Jun 22 16:08:37 2008 Subject: [sldev] How Far For Security? In-Reply-To: <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> References: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> Message-ID: <89ca6da00806221608p6dc6bd2i88ad0156b23d72b5@mail.gmail.com> We are getting off topic. You wouldn't want to read straight from disk to memory or GPU. You wouldn't be able to take advantage of the file system, you would have to read the data by sector. I don't really care enough about this off-topic to continue it. On Sun, Jun 22, 2008 at 8:14 AM, Argent Stonecutter wrote: > On 2008-06-22, at 01:32, Strife Onizuka wrote: >> >> You couldn't go straight from disk to GPU. There is no interface that >> connects the GPU to the disk. What you would do is write your program >> to make the appropriate requests to read a file into memory. The disk >> drive would be told where to read, and to use DMA to write the data >> directly to an already allocated memory range (the North Bridge would >> route the incoming data straight to memory). > > I'm not asking "does the hardware exist", I'm asking "does the OS API > exist"? You have to make zero-copy transfers to memory at specific > *physical* addresses, bypassing the ubiquitous buffer cache which *is* > handled by the CPU. > > This kind of thing normally requires at the least privileged access, and > probably kernel access, on any OS that makes even the slightest effort of > implementing multiuser protection. Does Windows really allow non-privileged > processes to grovel around in memory maps? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From darien_caldwell at comcast.net Sun Jun 22 19:32:06 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Sun Jun 22 19:31:52 2008 Subject: [sldev] Cache politics: performance vs obfuscation References: <061120081755.14074.485011AA000933BB000036FA221558639404040A990B040E0CA1020A079D0E0B@comcast.net> <1218b5bc0806202147i23a3468fg4ab2f2d3f6d342ba@mail.gmail.com> Message-ID: heh, one of the most perplexing non-answers I think i've seen. No worries though. I've long decided my course of action as related to the cache improvements. Thanks. ----- Original Message ----- From: Callum Lerwick To: sldev@lists.secondlife.com Sent: Friday, June 20, 2008 9:47 PM Subject: Re: [sldev] Cache politics: performance vs obfuscation On Wed, Jun 11, 2008 at 12:55 PM, wrote: On a related note, I would like to ask Linden Lab, if a better cache system was developed by someone for inclusion in the viewer, what is the likelihood that such a patch would be accepted? Is LL willing to do any/some/all of the things suggested or is all this discussion for naught? Are there any hard requirements to make a new cache system acceptable for the production viewer, or any things which would absolutely preclude a particular cache system from being accpeted? A better cache system has already been developed. It's called HTTP. I think I finally wrapped my brain around REST. Its 'everything is a file' reinvented for the age of ubiquitous internet connectivity. ------------------------------------------------------------------------------ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080622/695d6965/attachment.htm From seg at haxxed.com Sun Jun 22 23:06:50 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jun 22 23:06:52 2008 Subject: [sldev] How Far For Security? In-Reply-To: <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> References: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> Message-ID: <1218b5bc0806222306m6e486250m9cb431613b544c2@mail.gmail.com> On Sun, Jun 22, 2008 at 7:14 AM, Argent Stonecutter wrote: > I'm not asking "does the hardware exist", I'm asking "does the OS API > exist"? You have to make zero-copy transfers to memory at specific > *physical* addresses, bypassing the ubiquitous buffer cache which *is* > handled by the CPU. You mmap() the file, then pass it to the GL driver. The kernel takes care of the rest. Stop acting like you know better than the kernel because you don't. This kind of thing normally requires at the least privileged access, and > probably kernel access, on any OS that makes even the slightest effort of > implementing multiuser protection. Does Windows really allow non-privileged > processes to grovel around in memory maps? I'm not talking about Windows. http://www.tungstengraphics.com/wiki/index.php/TTM_Memory_Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080623/f5d616c3/attachment.htm From dmahalko at gmail.com Mon Jun 23 00:35:14 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 23 00:35:17 2008 Subject: [sldev] [Policy] Documenting LL policies and JIRA-debates on the wiki Message-ID: I note there isn't any sort of central policy documentation on the wiki. Searching for "policy" turns up nothing particularly useful, so it is unclear what is meant by the idea that we should take these issues onto the wiki or JIRA.. I am trying to fill a void I am seeing. I've created three pages that attempt to document all the various official LL policies, as well as end-user attempts to document unwritten LL policies, and also linking to the ongoing hotbutton policy debates in the JIRA: https://wiki.secondlife.com/wiki/Linden_Lab_Policies https://wiki.secondlife.com/wiki/User-Documented_Policies https://wiki.secondlife.com/wiki/Ongoing_JIRA_Policy_Debates I certainly can't claim that these pages speak for LL, so I've put a huge disclaimer at the top of each page that there's no Linden responsibility for the content of these pages. I have no idea if these articles would be of interest to anyone else, but the articles would definitely need help from more experienced people to make them properly useful. I have not explored the entire wiki, website, JIRA, or SL-Dev archives to know what all could be listed. Please edit or delete as you wish. - Scalar Tardis / Dale Mahalko From dmahalko at gmail.com Mon Jun 23 04:06:03 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 23 04:06:05 2008 Subject: [sldev] Which VS2003 components are (not) needed to compile? Message-ID: I am about to install Visual Studio .NET 2003, but I would prefer some more configuration notes for VS2003 than the following paragraph provides: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 =========================== Visual Studio .NET 2003 Professional * Setup Microsoft Visual Studio. =========================== Which of the following items are the minimum components needed to compile and develop the SL viewer? I'd rather not have gigabytes of unnecessary clutter to dig through, if I can help it. Installing just the minimum necessary components may also make the learning process easier. Straight off, I am fairly certain I won't need either IIS or SQL Server installed. The entire tree of VS2003 install options:: Visual Studio .NET Professional (Required) 1 Language Tools 1.1 Visual Basic .NET 1.1.1 Smart Device Programmability 1.2 Visual C++ .NET 1.2.1 Visual C++ Class & Template Libraries 1.2.1.1 ATL MFC Shared Libraries ANSI 1.2.1.2 ATL MFC Source Code 1.2.1.3 ATL MFC Static Libraries ANSI 1.2.1.4 ATL MFC Shared Libraries Unicode 1.2.1.5 ATL MFC Static Libraries Unicode 1.2.2 Visual C++ Run-Time Libraries 1.2.2.1 Visual C++ Dynamic CRT Libraries 1.2.2.2 Visual C++ CRT Source Code 1.2.2.3 Visual C++ Static Single-Threaded CRT Libraries 1.2.2.4 Visual C++ Static Multi-Threaded CRT Libraries 1.2.3 Visual C++ Tools 1.2.3.1 MFC Trace Utility 1.2.3.2 Spy++ 1.2.3.3 OLE/COM Object Viewer 1.2.3.4 ActiveX Control Test Container 1.2.3.5 Visual C++ Error Lookup 1.2.3.6 ISAPI Web Debug Tool 1.2.3.7 Win32 Platform SDK Tools (NOT selected by default) 1.2.4 Visual C# .NET 1.2.4.1 Java Language Conversion Assisteant 1.2.4.2 Smart Device Programmability 1.2.5 Visual J# .NET 1.3 .NET Framework SDK 1.3.1 Samples 1.4 Dotfuscator Community Edition 1.5 Crystal Reports for Visual Studeio .NET 1.5.1 Common Components 1.5.1.1 Visual Basic .NET Template 1.5.1.2 Visual C# .NET Template 1.5.1.3 Visual C++ .NET Template 1.5.1.4 Visual J# .NET Template 1.5.1.5 Crystal Web Services 1.6 Tools for Redistributing Applications 1.6.1 Graphics Library 1.6.2 Redistributable Merge Modules 1.7 Server Components 1.7.1 Remote Debugger 1.7.2 Web Development 1.7.3 VS 6 Stored Procedure Version Control I assume these are only components I really need, but perhaps this could be trimmed further?: Visual Studio .NET Professional (Required) 1.2 Visual C++ .NET 1.2.1 Visual C++ Class & Template Libraries 1.2.1.1 ATL MFC Shared Libraries ANSI 1.2.1.2 ATL MFC Source Code 1.2.1.3 ATL MFC Static Libraries ANSI 1.2.1.4 ATL MFC Shared Libraries Unicode 1.2.1.5 ATL MFC Static Libraries Unicode 1.2.2 Visual C++ Run-Time Libraries 1.2.2.1 Visual C++ Dynamic CRT Libraries 1.2.2.2 Visual C++ CRT Source Code 1.2.2.3 Visual C++ Static Single-Threaded CRT Libraries 1.2.2.4 Visual C++ Static Multi-Threaded CRT Libraries 1.2.3 Visual C++ Tools 1.2.3.1 MFC Trace Utility 1.2.3.2 Spy++ 1.2.3.3 OLE/COM Object Viewer 1.2.3.4 ActiveX Control Test Container 1.2.3.5 Visual C++ Error Lookup 1.2.3.6 ISAPI Web Debug Tool 1.6 Tools for Redistributing Applications 1.6.1 Graphics Library 1.6.2 Redistributable Merge Modules ============================================================ In the VS2003 .NET MSDN Library, which of the following components would be useful for developing the client, and which ones can I skip? The entire tree: MSDN Library (base, must install) 1 Visual Studio .NET 2003 Documentation 2 Embedded Development 2.1 Windows CE Documentation 2.2 SQL Server 2000 Windows CE Edition 2.3 Windows CD Application Framework 2.4 Microsoft Server Applice Kit 2.0 2.5 Windows NT Embedded 2.6 Windows XP Embedded 2.7 Windows CE .NET 3 Developer Knowledge Base Documentation 4 Office Developer Documentation 4.1 Office 2000 Developer Documentation 4.2 Office XP Documentation 4.3 Microsoft Access 4.4 FrontPage 4.5 MapPoint 4.6 Project 2000 4.7 Visio 4.8 SharePoint Team Services 5 Windows Development 5.1 Windows 2000 Documentation 5.2 Driver Development Kit 5.3 Windows 98 and Windows ME Documentation 5.4 Windows NT Documentation 5.5 Tablet PC 6 XML and Web Services 7 MSDN Documentation Group 1 8 MSDN Documentation Group 2 9 Platform SDK 10 Enterprise Development 10.1 Microsoft Content Management Server 10.2 Exchange Server Documentation I assume these are the only MSDN items I'd really need for client source programming, but again, no clue as yet: MSDN Library (base, must install) 1 Visual Studio .NET 2003 Documentation 3 Developer Knowledge Base Documentation 9 Platform SDK Is there anything else I could drop from this VS2003 components list without shooting myself in the foot? This information will be used to extend and improve that "Compiling the viewer" SL wiki page I mentioned, to help other C++ beginners to compile the client. - Scalar Tardis / Dale Mahalko From q at lindenlab.com Mon Jun 23 06:27:56 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon Jun 23 06:28:04 2008 Subject: [sldev] Which VS2003 components are (not) needed to compile? In-Reply-To: References: Message-ID: I'm not in the office today to verify the details, but: a) You can certainly avoid anything related to MFC and ATL -- we don't use those, or ActiveX. You can drop these from your list: > 1.2.1.1 ATL MFC Shared Libraries ANSI > 1.2.1.2 ATL MFC Source Code > 1.2.1.3 ATL MFC Static Libraries ANSI > 1.2.1.4 ATL MFC Shared Libraries Unicode > 1.2.1.5 ATL MFC Static Libraries Unicode > 1.2.3.1 MFC Trace Utility > 1.2.3.3 OLE/COM Object Viewer > 1.2.3.4 ActiveX Control Test Container > 1.2.3.6 ISAPI Web Debug Tool As well as some of the library choices, but I don't remember which ones. Regarding documentation, it's sometimes (but rarely) useful to have the Windows documentation handy. But with that said, once we get the CMake stuff straightened out, we're very much looking forward to NOT using VS2003 anymore internally. I don't know how long this information will be useful. Q On Jun 23, 2008, at 7:06 AM, Dale Mahalko wrote: > I am about to install Visual Studio .NET 2003, but I would prefer some > more configuration notes for VS2003 than the following paragraph > provides: > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 > =========================== > Visual Studio .NET 2003 Professional > > * Setup Microsoft Visual Studio. > =========================== > > > Which of the following items are the minimum components needed to > compile and develop the SL viewer? I'd rather not have gigabytes of > unnecessary clutter to dig through, if I can help it. Installing just > the minimum necessary components may also make the learning process > easier. > > Straight off, I am fairly certain I won't need either IIS or SQL > Server installed. > > > The entire tree of VS2003 install options:: > > Visual Studio .NET Professional (Required) > 1 Language Tools > 1.1 Visual Basic .NET > 1.1.1 Smart Device Programmability > 1.2 Visual C++ .NET > 1.2.1 Visual C++ Class & Template Libraries > 1.2.1.1 ATL MFC Shared Libraries ANSI > 1.2.1.2 ATL MFC Source Code > 1.2.1.3 ATL MFC Static Libraries ANSI > 1.2.1.4 ATL MFC Shared Libraries Unicode > 1.2.1.5 ATL MFC Static Libraries Unicode > 1.2.2 Visual C++ Run-Time Libraries > 1.2.2.1 Visual C++ Dynamic CRT Libraries > 1.2.2.2 Visual C++ CRT Source Code > 1.2.2.3 Visual C++ Static Single-Threaded CRT Libraries > 1.2.2.4 Visual C++ Static Multi-Threaded CRT Libraries > 1.2.3 Visual C++ Tools > 1.2.3.1 MFC Trace Utility > 1.2.3.2 Spy++ > 1.2.3.3 OLE/COM Object Viewer > 1.2.3.4 ActiveX Control Test Container > 1.2.3.5 Visual C++ Error Lookup > 1.2.3.6 ISAPI Web Debug Tool > 1.2.3.7 Win32 Platform SDK Tools (NOT selected by default) > 1.2.4 Visual C# .NET > 1.2.4.1 Java Language Conversion Assisteant > 1.2.4.2 Smart Device Programmability > 1.2.5 Visual J# .NET > 1.3 .NET Framework SDK > 1.3.1 Samples > 1.4 Dotfuscator Community Edition > 1.5 Crystal Reports for Visual Studeio .NET > 1.5.1 Common Components > 1.5.1.1 Visual Basic .NET Template > 1.5.1.2 Visual C# .NET Template > 1.5.1.3 Visual C++ .NET Template > 1.5.1.4 Visual J# .NET Template > 1.5.1.5 Crystal Web Services > 1.6 Tools for Redistributing Applications > 1.6.1 Graphics Library > 1.6.2 Redistributable Merge Modules > 1.7 Server Components > 1.7.1 Remote Debugger > 1.7.2 Web Development > 1.7.3 VS 6 Stored Procedure Version Control > > > I assume these are only components I really need, but perhaps this > could be trimmed further?: > > Visual Studio .NET Professional (Required) > 1.2 Visual C++ .NET > 1.2.1 Visual C++ Class & Template Libraries > 1.2.1.1 ATL MFC Shared Libraries ANSI > 1.2.1.2 ATL MFC Source Code > 1.2.1.3 ATL MFC Static Libraries ANSI > 1.2.1.4 ATL MFC Shared Libraries Unicode > 1.2.1.5 ATL MFC Static Libraries Unicode > 1.2.2 Visual C++ Run-Time Libraries > 1.2.2.1 Visual C++ Dynamic CRT Libraries > 1.2.2.2 Visual C++ CRT Source Code > 1.2.2.3 Visual C++ Static Single-Threaded CRT Libraries > 1.2.2.4 Visual C++ Static Multi-Threaded CRT Libraries > 1.2.3 Visual C++ Tools > 1.2.3.1 MFC Trace Utility > 1.2.3.2 Spy++ > 1.2.3.3 OLE/COM Object Viewer > 1.2.3.4 ActiveX Control Test Container > 1.2.3.5 Visual C++ Error Lookup > 1.2.3.6 ISAPI Web Debug Tool > 1.6 Tools for Redistributing Applications > 1.6.1 Graphics Library > 1.6.2 Redistributable Merge Modules > > ============================================================ > > > In the VS2003 .NET MSDN Library, which of the following components > would be useful for developing the client, and which ones can I skip? > > The entire tree: > > MSDN Library (base, must install) > 1 Visual Studio .NET 2003 Documentation > 2 Embedded Development > 2.1 Windows CE Documentation > 2.2 SQL Server 2000 Windows CE Edition > 2.3 Windows CD Application Framework > 2.4 Microsoft Server Applice Kit 2.0 > 2.5 Windows NT Embedded > 2.6 Windows XP Embedded > 2.7 Windows CE .NET > 3 Developer Knowledge Base Documentation > 4 Office Developer Documentation > 4.1 Office 2000 Developer Documentation > 4.2 Office XP Documentation > 4.3 Microsoft Access > 4.4 FrontPage > 4.5 MapPoint > 4.6 Project 2000 > 4.7 Visio > 4.8 SharePoint Team Services > 5 Windows Development > 5.1 Windows 2000 Documentation > 5.2 Driver Development Kit > 5.3 Windows 98 and Windows ME Documentation > 5.4 Windows NT Documentation > 5.5 Tablet PC > 6 XML and Web Services > 7 MSDN Documentation Group 1 > 8 MSDN Documentation Group 2 > 9 Platform SDK > 10 Enterprise Development > 10.1 Microsoft Content Management Server > 10.2 Exchange Server Documentation > > > I assume these are the only MSDN items I'd really need for client > source programming, but again, no clue as yet: > > MSDN Library (base, must install) > 1 Visual Studio .NET 2003 Documentation > 3 Developer Knowledge Base Documentation > 9 Platform SDK > > > Is there anything else I could drop from this VS2003 components list > without shooting myself in the foot? > > This information will be used to extend and improve that "Compiling > the viewer" SL wiki page I mentioned, to help other C++ beginners to > compile the client. > > - Scalar Tardis / Dale Mahalko > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From talinsands at googlemail.com Mon Jun 23 08:50:47 2008 From: talinsands at googlemail.com (talin sands) Date: Mon Jun 23 08:50:52 2008 Subject: [sldev] How Far For Security? In-Reply-To: <1218b5bc0806222306m6e486250m9cb431613b544c2@mail.gmail.com> References: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <1218b5bc0806202312k735196b5o8cb5cbe021e7f18@mail.gmail.com> <1218b5bc0806211633t12c5ca41m54076ce2192bdc23@mail.gmail.com> <3EEF6398-C439-4F6E-84C5-2CC7A2C71A22@gmail.com> <89ca6da00806212332p13dffbf3ja8b3b133bbc51484@mail.gmail.com> <86734F2A-0648-4502-9B5A-03EFF3BD01AD@gmail.com> <1218b5bc0806222306m6e486250m9cb431613b544c2@mail.gmail.com> Message-ID: <1c0afcf80806230850p37d41851xa457983851b5dbd6@mail.gmail.com> There is no technical way to stop the copying of content full stop....the only solutions for better protection are only going to come from the inworld community. With any caching system thats implemented you can guarantee that a week later there will be hundreds of web pages out there how to circumvent it. The trick is to just make it hard enough so little johnny cant find the pictures to look at on his hard drive but if hes a bit more determined hes going to just google for a solution anyway.. Personally the only solution to reducing IP theft would be to educate the population about the pitfalls of having your inv wiped and to not allow accounts without "payment on file" or a RL verified account to create any objects with transfer permissions as I don't think a lot of the thieves want LL to have there RL details so it will act as a deterrent. I'm sure that its hard to implement but its not imposable and It wont stop all the thieving and the community will have to verify all their builder alts but it would be a start.. Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080623/a6985250/attachment.htm From ravenglassrentals at yahoo.com Mon Jun 23 13:15:25 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Mon Jun 23 13:15:27 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 113 In-Reply-To: <20080623190049.13A7541B274@stupor.lindenlab.com> Message-ID: <391035.92732.qm@web55608.mail.re4.yahoo.com> Soft, I understand your desire to keep this list on topic, and to deal with "only technical matters". But it's simply not true that these issues are "merely technical" and as we can see abundantly on the texture issue, there are different schools of technological thinking on these things. Of course it's possible to obfuscate textures, it's done all the time, and worlds like World of Warcraft or There obviously follow that practice. It really seems to depend on what mindset the coders in the project start out with, however -- whether they are copyleftists or copyrightists, and that's all there is to it. It's really a religious rather than a political belief -- but whether religious or political, it is *not* technical because it can go either way. Everyone thinks digital media can no longer protect itself, and yet, Napster is out of business, iTunes collects 99 cents, and most software companies charge for a license that expires and needs to be paid for again -- it's just that simple. Work needs to be paid for online; this is how you get it paid -- you pay for people's time. There was a big debate here on whether obfuscation would compromise performance, but despite hearing very heated opinions on this, we really don't have a read-out from those in a position to really know -- the Lindens -- as those making claims in some cases don't even work in these coding languages, or don't work on a coding project of the complexity of Second Life. What's lacking here is a willingness to think openly and freely through all possible options to protect IP, then fit the technology to them -- instead of making technology driven by one school of thought whiplash everybody. Is the compromised performance REALLY an issue? Can the slack be picked up somewhere else? If the obfuscation is a routine you run once a week and change like you would passwords or codes anywhere, what's the big deal? There isn't the capacity for "hundreds" of cracking webpages to appear because frankly, the percentage of thiefs isn't as high as you think -- most people aren't going to bother, or in fact they are participating in social shopping which has to do with supporting networks of friends creating stuff -- it's different than RL where you don't know the person who makes your dress or car. Draconian social-Darwin solutions like banning NPIOF from creating or cashing out for payments of their creative work strikes me as far more harsh and time-consuming to police that this putative "100 pages of cracking pages" invoked -- I frankly think the technical solutions are more fair, and less time-consuming unless I'm missing something. Why should everybody have to go through cumbersome verification procedures and curtail Europeans and Asians in NPIOF from the economy because of an ideological problem with obfuscation? If the Lindens are eager not to have socio-political discussions on this list, then the focus now has to be on getting them to answer some basic questions: 1. Is Linden Lab willing to look at obfuscation solutions at all, or does it have an adamantly-opposed, ideological position against them? If so, then we know we're dealing with a religious problem here, not a coding problem, and then we, like our ancestors in RL, can deal with this religious problem by emigrating if we don't wish to create under these conditions. Answers like "obfuscation is not possible because it is cracked within days" isn't an answer, because a) very reputable coders on this list have claimed otherwise; b) real life shows us many companies relying on this method. 2. If Linden Lab is willing to obfuscate, or at least look at options to do some obfuscation temporarily until better social or legal policies are in place, then is it true that these solutions affect performance? 3. If indeed performance is affected, can the slack be picked up elsewhere or are there too many bankrupt dbase accounts in the system already crying for attention? 4. Can Linden Lab even comment on the coding time involved in a putative obfuscation operation, versus a social policing of NPIOF or thieves -- which is more costly for LL as a whole? 5. Is Linden Lab simply going to duck the coding issues, not go that route, and also duck the social policing route, not having resources or will for either, and simply leave it to people to pursue this problem with their real-life attorneys? If so, *say so*. These are all perfectly legitimate technical questions, and without clear answers to them, this conversation will continue to churn as it has for years in Second Life. Random Unsung/Prokofy Neva sldev-request@lists.secondlife.com wrote: Send SLDev mailing list submissions to sldev@lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request@lists.secondlife.com You can reach the person managing the list at sldev-owner@lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. Re: How Far For Security? (talin sands) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Jun 2008 16:50:47 +0100 From: "talin sands" Subject: Re: [sldev] How Far For Security? To: "Second Life Developer Mailing List" Message-ID: <1c0afcf80806230850p37d41851xa457983851b5dbd6@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" There is no technical way to stop the copying of content full stop....the only solutions for better protection are only going to come from the inworld community. With any caching system thats implemented you can guarantee that a week later there will be hundreds of web pages out there how to circumvent it. The trick is to just make it hard enough so little johnny cant find the pictures to look at on his hard drive but if hes a bit more determined hes going to just google for a solution anyway.. Personally the only solution to reducing IP theft would be to educate the population about the pitfalls of having your inv wiped and to not allow accounts without "payment on file" or a RL verified account to create any objects with transfer permissions as I don't think a lot of the thieves want LL to have there RL details so it will act as a deterrent. I'm sure that its hard to implement but its not imposable and It wont stop all the thieving and the community will have to verify all their builder alts but it would be a start.. Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080623/a6985250/attachment-0001.htm ------------------------------ _______________________________________________ SLDev mailing list SLDev@lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 18, Issue 113 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080623/f7ab00d1/attachment.htm From lenglish5 at cox.net Mon Jun 23 13:28:37 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 23 13:28:39 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 113 In-Reply-To: <391035.92732.qm@web55608.mail.re4.yahoo.com> References: <391035.92732.qm@web55608.mail.re4.yahoo.com> Message-ID: <48600775.5090702@cox.net> Random Unsung wrote: > Soft, I understand your desire to keep this list on topic, and to deal > with "only technical matters". But it's simply not true that these > issues are "merely technical" and as we can see abundantly on the > texture issue, there are different schools of technological thinking > on these things. > > Of course it's possible to obfuscate textures, it's done all the time, > and worlds like World of Warcraft or There obviously follow that practice. I don't know about There, but the Worlds of Warcraft textures apparently are NOT encrypted or obfuscated. They DO use their own proprietary format, but it is well-documented: http://www.wowwiki.com/BLP_Files Lawson From lenglish5 at cox.net Mon Jun 23 13:53:22 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 23 13:53:23 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python Message-ID: <48600D42.1010500@cox.net> I spammed this message to various python and games programming lists. I'm submitting it to the SL lists as a heads up for technically included Second Life citizens who may wish to contribute to the project in some way: A new open source project has been started by Linden Lab, makers of the Second Life? virtual worlds, and the Second Life Architecture Working Group (AWG) to test LL's proposed virtual worlds Open Grid Protocols (OGP) that will allow any virtual world to support multi-world login, between-world teleport and other transportation mechanisms, as well as asset/property and currency sharing between worlds. https://wiki.secondlife.com/w/index.php?title=AWG_Test_Harness The code is released to all comers in Python under an Apache v2 agreement, although contributions require the signing of Linden Lab's developer contribution agreement (giving LL equal copyrights to the original contributer--a boilerplate LL corporate requirement that likely is redundant given the nature of Apache v2). svn: http://svn.secondlife.com/trac/linden/browser/projects/2008/pyogp. Second Life contribution agreement: http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf irc: irc://irc.freenode.net/#pyogp AWG homepage: https://wiki.secondlife.com/wiki/AWG AWG discussion group homepage: https://wiki.secondlife.com/wiki/Category:AW_Groupies AWG-related pages, irc channels and forums: https://wiki.secondlife.com/wiki/Category:AW_Groupies#External_Resources The near-term AWG goal is to create a set of open standard protocols that: 1) Enable third parties to run servers that connect to the Second Life Grid platform 2) Scale the Second Life Grid architecture to support the industry-projected situation in the next 10 years, where virtual worlds will comprise at least 60 million regions, 2 billion users and in-world concurrency of 50-100 million residents. https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 https://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman The long-term goal is to design a set of protocols and standards that will enable almost any virtual world of any kind to "plug into" this system to varying degrees, from support for a "universal avatar" to full support for all Second Life features and/or the ability to inform universal 3D viewers what features are supported (or not) in any given virtual world. More info on pyogp and the AWG can be obtained on the website or via irc. Lawson English AKA Saijana Kuhn, AWGroupies admin From matthew.dowd at hotmail.co.uk Mon Jun 23 15:07:41 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jun 23 15:07:44 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 113 In-Reply-To: <391035.92732.qm@web55608.mail.re4.yahoo.com> References: <20080623190049.13A7541B274@stupor.lindenlab.com> <391035.92732.qm@web55608.mail.re4.yahoo.com> Message-ID: >Why should everybody have to go through cumbersome verification procedures and curtail Europeans and Asians in NPIOF from the economy because of an ideological problem with obfuscation? A somewhat odd statement - a European or Asian is no less (or more) likely to be NPIOF than any other nationality found in SL! Matthew _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ From blindwanderer at gmail.com Mon Jun 23 17:11:21 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Mon Jun 23 17:11:25 2008 Subject: [sldev] [VWR] Shadow Branch Message-ID: <89ca6da00806231711p6336007qdb5be2932f9e230d@mail.gmail.com> There has been a new source drop for the Shadow branch on the SVN. Anyone want to take the time to post a build? Not to keen on doing it myself. http://svn.secondlife.com/trac/linden/changeset/674 From dmahalko at gmail.com Tue Jun 24 05:48:51 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 24 05:48:57 2008 Subject: [sldev] [source] Purpose of /newview and libraries split? Message-ID: What is the reason for the dividing of some source files into the /newview directory? I see lots of functional duplication across /newview and the other directories, so it's highly unclear to me what the code division is meant to accomplish. For example, there are some sound-system files in /llaudio and some in /newview I realize that LL is also working on simulator and asset code we cannot see, and it seems possible that the code not inside /newview may be utilized by these other components. For example, I would assume there's a similar usage of the LLLFS and the APR in the simulator code, as there is in the client code. But there's no way for an "outsider" to know if that is true or not. Are open-source programmers able to freely modify any component of the libraries and /newview? Can modifying the source outside /newview cause unseen problems with server/asset code that may reuse those libraries? - Scalar Tardis / Dale Mahalko From tao.takashi at googlemail.com Tue Jun 24 06:42:48 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Tue Jun 24 06:42:51 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python In-Reply-To: <48600D42.1010500@cox.net> References: <48600D42.1010500@cox.net> Message-ID: <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> Hi! As my proposal was to use the Zope Component Architecture for this library and I also started to implement things with it I wanted to write a little introduction into this way of working and here it is: http://mrtopf.de/blog/an-introduction-to-the-zope-component-architecture/ I did this a little bit in a hurry (and still need to document how I used this in pyogp) but I hope it's understandable. See it as work in progress. cheers, Tao On Mon, Jun 23, 2008 at 10:53 PM, Lawson English wrote: > I spammed this message to various python and games programming lists. > > I'm submitting it to the SL lists as a heads up for technically included > Second Life citizens who may wish to contribute to the project in some way: > > > > A new open source project has been started by Linden Lab, makers of the > Second Life? virtual worlds, and the Second Life Architecture Working Group > (AWG) to test LL's proposed virtual worlds Open Grid Protocols (OGP) that > will allow any virtual world to support multi-world login, between-world > teleport and other transportation mechanisms, as well as asset/property and > currency sharing between worlds. > > > https://wiki.secondlife.com/w/index.php?title=AWG_Test_Harness > > The code is released to all comers in Python under an Apache v2 agreement, > although contributions require the signing of Linden Lab's developer > contribution agreement (giving LL equal copyrights to the original > contributer--a boilerplate LL corporate requirement that likely is redundant > given the nature of Apache v2). > > svn: http://svn.secondlife.com/trac/linden/browser/projects/2008/pyogp. > > Second Life contribution agreement: > http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf > > irc: irc://irc.freenode.net/#pyogp > > AWG homepage: https://wiki.secondlife.com/wiki/AWG > > AWG discussion group homepage: > https://wiki.secondlife.com/wiki/Category:AW_Groupies > > AWG-related pages, irc channels and forums: > https://wiki.secondlife.com/wiki/Category:AW_Groupies#External_Resources > > > The near-term AWG goal is to create a set of open standard protocols that: > > 1) Enable third parties to run servers that connect to the Second Life Grid > platform > 2) Scale the Second Life Grid architecture to support the industry-projected > situation in the next 10 years, where virtual worlds will comprise at least > 60 million regions, 2 billion users and in-world concurrency of 50-100 > million residents. > > https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 > https://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman > > The long-term goal is to design a set of protocols and standards that will > enable almost any virtual world of any kind to "plug into" this system to > varying degrees, from support for a "universal avatar" to full support for > all Second Life features and/or the ability to inform universal 3D viewers > what features are supported (or not) in any given virtual world. > > > More info on pyogp and the AWG can be obtained on the website or via irc. > > > Lawson English > AKA Saijana Kuhn, AWGroupies admin > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From soft at lindenlab.com Tue Jun 24 07:01:16 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 24 07:01:29 2008 Subject: [sldev] [source] Purpose of /newview and libraries split? In-Reply-To: References: Message-ID: On Tue, Jun 24, 2008 at 7:48 AM, Dale Mahalko wrote: > What is the reason for the dividing of some source files into the > /newview directory? I see lots of functional duplication across > /newview and the other directories, so it's highly unclear to me what > the code division is meant to accomplish. For example, there are some > sound-system files in /llaudio and some in /newview > > I realize that LL is also working on simulator and asset code we > cannot see, and it seems possible that the code not inside /newview > may be utilized by these other components. For example, I would assume > there's a similar usage of the LLLFS and the APR in the simulator > code, as there is in the client code. But there's no way for an > "outsider" to know if that is true or not. > > Are open-source programmers able to freely modify any component of the > libraries and /newview? Can modifying the source outside /newview > cause unseen problems with server/asset code that may reuse those > libraries? Short answer: Ideally, more things should be split out of newview/ and into their own libraries. This would speed builds and encourage more modularity. A lot of larger components are in newview/ merely because they started there when they were small, and componentizing them hasn't ever stood out as someone's biggest itch so far. I have a feeling this may change as we move to VS2005, as monolithic projects interfere with the way it parallellizes builds. You can certainly break server code by modifying some of the common libs, but generally not if you're only modifying the implementation, not the interface. If there's a specific change you're thinking of, the best thing you can do is ask. Even if it does necessitate a server change, if it's a good change for the viewer, odds are there will be a benefit for the servers as well. From tao.takashi at googlemail.com Tue Jun 24 09:26:50 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Tue Jun 24 09:26:52 2008 Subject: [sldev] [AWG] pyogp refactoring explained Message-ID: <23bbb49e0806240926r6fd626c0ode4511d560ee546f@mail.gmail.com> Hi! Just for your information, I rectored the login script into separate parts and experimented a bit with it. My explanation of what I did (and a link to code) can be found here: http://mrtopf.de/blog/secondlife/a-first-shot-at-refactoring-the-ogp-login-in-python-pyogp-technical/ cheers, Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From jhurliman at jhurliman.org Tue Jun 24 12:40:21 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jun 24 12:40:27 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python In-Reply-To: <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> References: <48600D42.1010500@cox.net> <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> Message-ID: I skimmed over the article but couldn't find any explanation of why. Maybe I'm late to the party, but why is a content management system architecture being used for a virtual world networking library? John On Tue, Jun 24, 2008 at 6:42 AM, Christian Scholz / Tao Takashi (SL) < tao.takashi@googlemail.com> wrote: > Hi! > > As my proposal was to use the Zope Component Architecture for this > library and I also started to implement things with it I wanted to > write a little introduction into this way of working and here it is: > > http://mrtopf.de/blog/an-introduction-to-the-zope-component-architecture/ > > I did this a little bit in a hurry (and still need to document how I > used this in pyogp) but I hope it's understandable. See it as work in > progress. > > cheers, > > Tao > > > On Mon, Jun 23, 2008 at 10:53 PM, Lawson English > wrote: > > I spammed this message to various python and games programming lists. > > > > I'm submitting it to the SL lists as a heads up for technically included > > Second Life citizens who may wish to contribute to the project in some > way: > > > > > > > > A new open source project has been started by Linden Lab, makers of the > > Second Life? virtual worlds, and the Second Life Architecture Working > Group > > (AWG) to test LL's proposed virtual worlds Open Grid Protocols (OGP) that > > will allow any virtual world to support multi-world login, between-world > > teleport and other transportation mechanisms, as well as asset/property > and > > currency sharing between worlds. > > > > > > https://wiki.secondlife.com/w/index.php?title=AWG_Test_Harness > > > > The code is released to all comers in Python under an Apache v2 > agreement, > > although contributions require the signing of Linden Lab's developer > > contribution agreement (giving LL equal copyrights to the original > > contributer--a boilerplate LL corporate requirement that likely is > redundant > > given the nature of Apache v2). > > > > svn: http://svn.secondlife.com/trac/linden/browser/projects/2008/pyogp. > > > > Second Life contribution agreement: > > http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf > > > > irc: irc://irc.freenode.net/#pyogp > > > > AWG homepage: https://wiki.secondlife.com/wiki/AWG > > > > AWG discussion group homepage: > > https://wiki.secondlife.com/wiki/Category:AW_Groupies > > > > AWG-related pages, irc channels and forums: > > https://wiki.secondlife.com/wiki/Category:AW_Groupies#External_Resources > > > > > > The near-term AWG goal is to create a set of open standard protocols > that: > > > > 1) Enable third parties to run servers that connect to the Second Life > Grid > > platform > > 2) Scale the Second Life Grid architecture to support the > industry-projected > > situation in the next 10 years, where virtual worlds will comprise at > least > > 60 million regions, 2 billion users and in-world concurrency of 50-100 > > million residents. > > > > https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 > > https://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman > > > > The long-term goal is to design a set of protocols and standards that > will > > enable almost any virtual world of any kind to "plug into" this system to > > varying degrees, from support for a "universal avatar" to full support > for > > all Second Life features and/or the ability to inform universal 3D > viewers > > what features are supported (or not) in any given virtual world. > > > > > > More info on pyogp and the AWG can be obtained on the website or via irc. > > > > > > Lawson English > > AKA Saijana Kuhn, AWGroupies admin > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > > > -- > Christian Scholz > Tao Takashi (Second Life name) > taotakashi@gmail.com > Blog/Podcast: http://mrtopf.de/blog > Planet: http://worldofsl.com > > Company: http://comlounge.net > Tech Video Blog: http://comlounge.tv > IRC: MrTopf/Tao_T > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080624/57191eae/attachment.htm From sakkaku at gmail.com Tue Jun 24 12:52:42 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue Jun 24 12:52:44 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python In-Reply-To: References: <48600D42.1010500@cox.net> <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> Message-ID: <79e704e0806241252g557a7105y4f35f74f931c2e12@mail.gmail.com> Look at how Django handles models and database lookups/updates/inserts, it is pretty sexy coding wise and I believe it follows the same principals. On Tue, Jun 24, 2008 at 3:40 PM, John Hurliman wrote: > I skimmed over the article but couldn't find any explanation of why. Maybe > I'm late to the party, but why is a content management system architecture > being used for a virtual world networking library? > > > John > From blindwanderer at gmail.com Tue Jun 24 13:44:20 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Tue Jun 24 13:44:23 2008 Subject: [sldev] [source] Purpose of /newview and libraries split? In-Reply-To: References: Message-ID: <89ca6da00806241344y4541c744t3bcb2a4c06c07a47@mail.gmail.com> Many years ago the client was named "newview" but it was not the first iteration of the SL client, it was (atleast) the second; "new" is a prefix to differentiate it from the client before it. Much later during the push for the 2.0 renderer the source code layout got reorganized into what you see today (and the exe was renamed to the current naming semantic). The "newview" layout is lava flow. Strife On Tue, Jun 24, 2008 at 10:01 AM, Soft wrote: > On Tue, Jun 24, 2008 at 7:48 AM, Dale Mahalko wrote: >> What is the reason for the dividing of some source files into the >> /newview directory? I see lots of functional duplication across >> /newview and the other directories, so it's highly unclear to me what >> the code division is meant to accomplish. For example, there are some >> sound-system files in /llaudio and some in /newview >> >> I realize that LL is also working on simulator and asset code we >> cannot see, and it seems possible that the code not inside /newview >> may be utilized by these other components. For example, I would assume >> there's a similar usage of the LLLFS and the APR in the simulator >> code, as there is in the client code. But there's no way for an >> "outsider" to know if that is true or not. >> >> Are open-source programmers able to freely modify any component of the >> libraries and /newview? Can modifying the source outside /newview >> cause unseen problems with server/asset code that may reuse those >> libraries? > > Short answer: Ideally, more things should be split out of newview/ and > into their own libraries. This would speed builds and encourage more > modularity. A lot of larger components are in newview/ merely because > they started there when they were small, and componentizing them > hasn't ever stood out as someone's biggest itch so far. I have a > feeling this may change as we move to VS2005, as monolithic projects > interfere with the way it parallellizes builds. > > You can certainly break server code by modifying some of the common > libs, but generally not if you're only modifying the implementation, > not the interface. If there's a specific change you're thinking of, > the best thing you can do is ask. Even if it does necessitate a server > change, if it's a good change for the viewer, odds are there will be a > benefit for the servers as well. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From lenglish5 at cox.net Tue Jun 24 14:58:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 24 14:58:50 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python In-Reply-To: References: <48600D42.1010500@cox.net> <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> Message-ID: <48616DF9.80501@cox.net> John Hurliman wrote: > I skimmed over the article but couldn't find any explanation of why. > Maybe I'm late to the party, but why is a content management system > architecture being used for a virtual world networking library? > [...] > > > > http://mrtopf.de/blog/an-introduction-to-the-zope-component-architecture/ > [...] It provides a reasonably simple way to hide the implementation details for large chunks of code. Instead of having named class libraries for various chunks of protocol testing/implmentation code, we have ZCA interfaces, so we can use different libraries for testing/prototyping/optimization purposes. Different people and groups could be testing using different libraries and the overall structure of the pyogp wouldn't change. Nor would everyone have to follow exactly the same naming scheme for each module. Lawson From tao.takashi at googlemail.com Tue Jun 24 15:05:03 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Tue Jun 24 15:05:06 2008 Subject: [sldev] [ANN]{AWG]{PYOGP] Virtual Worlds Open Grid Protocol testing library in Python In-Reply-To: References: <48600D42.1010500@cox.net> <23bbb49e0806240642g3d265684t96311b9b78ff0d53@mail.gmail.com> Message-ID: <23bbb49e0806241505i64feb5b6t3116d66363da000c@mail.gmail.com> Hi! On Tue, Jun 24, 2008 at 9:40 PM, John Hurliman wrote: > I skimmed over the article but couldn't find any explanation of why. Maybe > I'm late to the party, but why is a content management system architecture > being used for a virtual world networking library? It's not a CMS architecture but simply a small part of the Zope framework (which in it's completeness is a web application server but also a python framework if you cut away the web server part). ZCA gives you IMHO a nice abstraction model for defining components around interfaces. It handles nothing more. As for Django, it's a great framework for web apps (although I also had my issues with it) but what we are trying is not so much a web app. Right now we neither need a db interface nor a web interface so it's not that well suited and we use more of a plain python instead of any framework. ZCA is really just a small layer on top on this plain python adding the concept of interfaces and providing a global component registry. -- Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From gigstaggart at gmail.com Tue Jun 24 16:00:00 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 24 16:00:04 2008 Subject: [sldev] Call for Papers: SLCC08 Open Source Track Message-ID: <48617C70.7060600@gmail.com> Hi Everyone. SLCC 08 is fast approaching. This year we will have a dedicated Open Source mini-track. The plan for most of the track is panels with heavy audience participation, however we will have some limited time for demonstrations or short presentations. Powerpoint style presentations are forbidden. I hate them. Please let me know if you have a new and compelling open source technology related to Second Life that you would like to present at SLCC 08. All proposals should be in before July 1. SLCC 08 is September 5-7 in Tampa FL. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080624/830c2d7c/smime-0001.bin From lenglish5 at cox.net Tue Jun 24 16:58:24 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 24 16:58:26 2008 Subject: [sldev] Call for Papers: SLCC08 Open Source Track In-Reply-To: <48617C70.7060600@gmail.com> References: <48617C70.7060600@gmail.com> Message-ID: <48618A20.5030408@cox.net> Jason Giglio wrote: > Hi Everyone. > > SLCC 08 is fast approaching. This year we will have a dedicated Open > Source mini-track. > SLCC = ? L. From sarah77 at gmail.com Tue Jun 24 17:02:04 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Tue Jun 24 17:02:08 2008 Subject: [sldev] Call for Papers: SLCC08 Open Source Track In-Reply-To: <48618A20.5030408@cox.net> References: <48617C70.7060600@gmail.com> <48618A20.5030408@cox.net> Message-ID: <9010c35c0806241702q56a00b40u5e1929ba454ee374@mail.gmail.com> Second Life Community Convention - Happens in Tampa this year. http://www.slconvention.org/ - Kippie On Tue, Jun 24, 2008 at 7:58 PM, Lawson English wrote: > Jason Giglio wrote: > >> Hi Everyone. >> >> SLCC 08 is fast approaching. This year we will have a dedicated Open >> Source mini-track. >> >> > > SLCC = ? > > L. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080624/a4cefbdf/attachment.htm From glenn at lindenlab.com Tue Jun 24 17:09:27 2008 From: glenn at lindenlab.com (Glenn Fisher) Date: Tue Jun 24 17:09:37 2008 Subject: [sldev] Scripting projects priority survey Message-ID: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> Dear member of SLDev: Help prioritize the next 8 potential scripting projects: rank them, tell us why they're important and how you might use each capability by taking this survey: https://www.surveymonkey.com/s.aspx? sm=Vyp_2fn74VLvZqjvu_2fbMvp3g_3d_3d? All data is collected anonymously. Please take a few minutes between now and this Friday, 27 June to complete the survey. Thank you. Glenn Fisher Director of Business Programs Linden Lab -------------- next part -------------- Skipped content of type multipart/related From dmahalko at gmail.com Tue Jun 24 19:40:08 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 24 19:40:11 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? Message-ID: On the wiki page for VS2003... http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 It says: == Building == "Go into the indra folder, and run the develop.py script." There is no develop.py for 1.19.1.4 as far as I can determine. A search of the entire source tree turns up nothing. Should I be running one of those 20 or so batch files now, instead? - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Tue Jun 24 19:59:07 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 24 19:59:12 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: Message-ID: <4861B47B.2050009@gmail.com> Dale Mahalko wrote: > There is no develop.py for 1.19.1.4 as far as I can determine. A > search of the entire source tree turns up nothing. > > Should I be running one of those 20 or so batch files now, instead? Don't bother investing time learning how to build under the old build system. CMake is the system that is in the later versions. Snapshot of internal branch release Last Changed Rev: 89507 Last Changed Date: 2008-06-11 11:50:23 -0700 (Wed, 11 Jun 2008) Supplementary files: http://secondlife.com/developers/opensource/downloads/2008/06/md5sums-release-r89507.txt http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-artwork-release-r89507.zip http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-darwin-libs-release-r89507.tar.gz http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-win32-libs-release-r89507.zip http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-linux-libs-release-r89507.tar.gz Source tarballs - redundant to this svn: http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-src-release-r89507.tar.gz http://secondlife.com/developers/opensource/downloads/2008/06/slviewer-src-release-r89507.zip Soft really needs to push a new release drop... this one is getting kind of old. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080624/3cc8a7b1/smime.bin From dmahalko at gmail.com Tue Jun 24 20:47:09 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 24 20:47:12 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: <4861B47B.2050009@gmail.com> References: <4861B47B.2050009@gmail.com> Message-ID: This is probably just a case where the wiki instructions need to be updated to match new methods. So far I am just ignoring this, trying to move straight on to building in VS2003, and it seems to be proceeding.. - Scalar Tardis / Dale Mahalko On Tue, Jun 24, 2008 at 9:59 PM, Jason Giglio wrote: > Dale Mahalko wrote: >> There is no develop.py for 1.19.1.4 as far as I can determine. A >> search of the entire source tree turns up nothing. >> >> Should I be running one of those 20 or so batch files now, instead? > > Don't bother investing time learning how to build under the old build > system. CMake is the system that is in the later versions. From gigstaggart at gmail.com Tue Jun 24 20:57:23 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 24 20:57:26 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: <4861B47B.2050009@gmail.com> Message-ID: <4861C223.7020701@gmail.com> Dale Mahalko wrote: > This is probably just a case where the wiki instructions need to be > updated to match new methods. > > So far I am just ignoring this, trying to move straight on to building > in VS2003, and it seems to be proceeding.. No it is the opposite. The wiki is up to date. The source code you have is old. Your version of visual studio is also ancient and is being phased out. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080624/1e9f7304/smime-0001.bin From dmahalko at gmail.com Tue Jun 24 21:26:56 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 24 21:26:58 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: <4861C223.7020701@gmail.com> References: <4861B47B.2050009@gmail.com> <4861C223.7020701@gmail.com> Message-ID: Well, I'll see about acquiring VS2005 or VS2008. Which one? The main reason for using VS2003 is simply because the precompiled libraries package LL provides is apparently not going to work with VS2005/2008, as the wiki says here: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 ========= Note: The VS2003 libraries provided in the source downloads do not fully work with VS2005 compiled binaries. They will compile with the viewer under VS2005, but the VS2003 libraries are not fully STL compliant. The differences of non-standard behavior in MSVS are the known cause. Alternatively, it may be possible to get the source files for the libraries and build by yourself. See the instruction for VS2003 users if you try it. Please note, however, it is not known that VS2005 can successfully compile the libraries. You have been warned. (If you can make it, please write the info on this wiki...) ========= That is hardly the most inspiring text for a coder n00b just trying to get a foothold on the source project. My current goal is to get it up and running with the least suffering. :-) If VS2005/2008 is now the way and the light, why isn't a precompiled library package being provided for them with each viewer release? Why only for the "old" VS2003? (Or is that library package now usable with more than VS2003 and the above wiki text is wrong?) - Scalar Tardis / Dale Mahalko On Tue, Jun 24, 2008 at 10:57 PM, Jason Giglio wrote: > No it is the opposite. The wiki is up to date. The source code you > have is old. > > Your version of visual studio is also ancient and is being phased out. > > -Jason > From soft at lindenlab.com Tue Jun 24 22:06:04 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 24 22:06:07 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: <4861B47B.2050009@gmail.com> References: <4861B47B.2050009@gmail.com> Message-ID: On Tue, Jun 24, 2008 at 9:59 PM, Jason Giglio wrote: > > Soft really needs to push a new release drop... this one is getting kind > of old. Release is on hold a little while longer. Some major changes were pushed into release that require some retooling of the build system before exports will work again. From blindwanderer at gmail.com Tue Jun 24 23:05:14 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Tue Jun 24 23:05:17 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: <4861B47B.2050009@gmail.com> Message-ID: <89ca6da00806242305k12055619m5783e86c460e1e6d@mail.gmail.com> We could really use at the very least a 1.19 refresh that includes some of the LSL improvements, it's kinda silly not having PRIM_GLOW available in the compiler. I think the slow time between releases is causing problems on JIRA with people reopening issues that have been resolved in the 1.20 RCs because they are still having them in the 1.19 series. Not mentioning that it just doesn't seem right to continually add new functionality into the RCs and not release a new client. Particle people instead of gray bodies was a bit of a surprise to spring on people in such a late RC. Subverts the Alpha, Beta, RC expectation. *shrug* No worries, I won't be leading the mob to pound on your door over it. Strife On Wed, Jun 25, 2008 at 1:06 AM, Soft wrote: > On Tue, Jun 24, 2008 at 9:59 PM, Jason Giglio wrote: >> >> Soft really needs to push a new release drop... this one is getting kind >> of old. > > Release is on hold a little while longer. > > Some major changes were pushed into release that require some > retooling of the build system before exports will work again. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From gigstaggart at gmail.com Tue Jun 24 23:55:48 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 24 23:55:52 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: <4861B47B.2050009@gmail.com> <4861C223.7020701@gmail.com> Message-ID: <4861EBF4.6000802@gmail.com> Dale Mahalko wrote: > Well, I'll see about acquiring VS2005 or VS2008. Which one? > > The main reason for using VS2003 is simply because the precompiled > libraries package LL provides is apparently not going to work with > VS2005/2008, as the wiki says here: > 2005 is probably your best bet, since Boost libs are a hassle with 2008. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080625/f9724a31/smime.bin From dmahalko at gmail.com Wed Jun 25 00:21:58 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 25 00:22:00 2008 Subject: [sldev] Compiling/VS2003: 1.19.1.4 link.exe Build non-errors? Message-ID: I've applied the two hacks to 1.19.1.4 discussed in SLDev and which I've added to the wiki: https://wiki.secondlife.com/wiki/Common_compilation_problems C1083: Cannot open include file: 'unistd.h' C4018: '<' : signed/unsigned mismatch I am left with four linking errors that don't seem to be errors: "win_crash_logger" error result returned from 'link.exe'. "win_updater" error result returned from 'link.exe'. "test" error result returned from 'link.exe'. "newview" error result returned from 'link.exe'. This appears for "debug" and "ReleaseNoOpt". Haven't tried the other one yet. I am not seeing this mentioned in the wiki, so I don't see what to do next. - Scalar Tardis / Dale Mahalko From robin.cornelius at gmail.com Wed Jun 25 01:08:49 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 25 01:09:03 2008 Subject: [sldev] Compiling/VS2003: 1.19.1.4 link.exe Build non-errors? In-Reply-To: References: Message-ID: > I am left with four linking errors that don't seem to be errors: > > "win_crash_logger" error result returned from 'link.exe'. > "win_updater" error result returned from 'link.exe'. > "test" error result returned from 'link.exe'. > "newview" error result returned from 'link.exe'. > > This appears for "debug" and "ReleaseNoOpt". Haven't tried the other one yet. > Yea a tad odd, there is information missing. I think VS is being helpful and only showing you the build summary window. Can you try to find the build results window, it should be a lot more helpful and give the actual error (its the "Output" window you need from View Menu). Hopefully that will tell you some more. Robin From tao.takashi at googlemail.com Wed Jun 25 02:39:17 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed Jun 25 02:39:20 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> Message-ID: <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Hi! I wonder if everybody knows what those questions are about (like scheduling or collection classes). I talked to some Lindens and think I know a little bit about the background regarding scheduling and ressource limits (at least I have an idea) but maybe this can be elaborated upon a little bit on what that means and what collection classes are (not everybody is a C# programmer). Besides that I would like to be able to use any language which can produce an mono compatible output (I guess Python fits in there? :-) ) but the upload needs to be done via some webservice or client api. Only if it's really easy to press a button in your editor and it gets stored under some id/name on LL's servers and I can refer to it from within an object it IMHO makes sense and is somewhat comfortable. It also might open up the opportunity to do version control and collaborative development easier. Thanks for the survey! :-) -- Tao On Wed, Jun 25, 2008 at 2:09 AM, Glenn Fisher wrote: > Dear member of SLDev: > > Help prioritize the next 8 potential scripting projects: rank them, tell us > why they're important and how you might use each capability by taking this > survey: > https://www.surveymonkey.com/s.aspx?sm=Vyp_2fn74VLvZqjvu_2fbMvp3g_3d_3d > > All data is collected anonymously. Please take a few minutes between now and > this Friday, 27 June to complete the survey. > > Thank you. > Glenn Fisher > Director of Business Programs > Linden Lab > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From dmahalko at gmail.com Wed Jun 25 03:37:58 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 25 03:38:00 2008 Subject: [sldev] Compiling/VS2003: 1.19.1.4 link.exe Build non-errors? In-Reply-To: References: Message-ID: The problem: Linking... link: extra operand `/NOLOGO' Try `link --help' for more information. win_crash_logger : error PRJ0002 : error result returned from 'link.exe'. Rather than include attachments, I've put the four error logs here: https://wiki.secondlife.com/wiki/User:Scalar_Tardis/NOLOGO-Compile-Err >From searching for NOLOGO I see it's in 18 other logs without a problem. I've included one of those success logs as well. - Scalar Tardis / Dale Mahalko On Wed, Jun 25, 2008 at 3:08 AM, Robin Cornelius wrote: > Yea a tad odd, there is information missing. I think VS is being > helpful and only showing you the build summary window. Can you try to > find the build results window, it should be a lot more helpful and > give the actual error (its the "Output" window you need from View > Menu). Hopefully that will tell you some more. > > Robin > From tongb at ohio.edu Wed Jun 25 05:26:10 2008 From: tongb at ohio.edu (Bruce Tong) Date: Wed Jun 25 05:26:13 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Message-ID: <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> On Wed, Jun 25, 2008 at 5:39 AM, Christian Scholz / Tao Takashi (SL) wrote: > I wonder if everybody knows what those questions are about (like > scheduling or collection classes). I talked to some Lindens and think > I know a little bit about the background regarding scheduling and > ressource limits (at least I have an idea) but maybe this can be > elaborated upon a little bit on what that means and what collection > classes are (not everybody is a C# programmer). I'm not a C# programmer, but I assumed collection classes referred to things like a Hashmap in Java. I've not put a lot of thought into this, but might there be some undesirable exploits if people are able to upload their own compilations? I guess I'm wondering if folks might be able to get outside of what I assume is an isolated or protected runtime environment and find data to which they should not have? I'm completely ignorant of the runtime environment of scripts, so these are probably unjustified concerns. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Wed Jun 25 05:43:28 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 25 05:43:31 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: <89ca6da00806242305k12055619m5783e86c460e1e6d@mail.gmail.com> References: <4861B47B.2050009@gmail.com> <89ca6da00806242305k12055619m5783e86c460e1e6d@mail.gmail.com> Message-ID: On Wed, Jun 25, 2008 at 1:05 AM, Strife Onizuka wrote: > We could really use at the very least a 1.19 refresh that includes > some of the LSL improvements, it's kinda silly not having PRIM_GLOW > available in the compiler. I think the slow time between releases is > causing problems on JIRA with people reopening issues that have been > resolved in the 1.20 RCs because they are still having them in the > 1.19 series. Not mentioning that it just doesn't seem right to > continually add new functionality into the RCs and not release a new > client. Particle people instead of gray bodies was a bit of a surprise > to spring on people in such a late RC. Subverts the Alpha, Beta, RC > expectation. *shrug* No worries, I won't be leading the mob to pound > on your door over it. I hear ya, but unfortunately QA resources are one of the gating factors right now. (If you know qualified, experienced QA people, please nudge them toward our jobs pages! They're harder to find than you may think.) Another 1.19 series release would spread QA even thinner. 1.20 is getting much more scrutiny than previous viewers. Tools were added to a couple RCs that provide LL with feedback on specific problems, such as the viewer pauses. A line was drawn in the sand as to where the overall crash rate should be, and that's been met. Feedback about one of 1.20's key features has also resulted in the release being held up for a pretty significant rework. I think some other "safe" features are being trickled in just to try and reduce the significant changeset that would have gone into 1.21. From daveh at lindenlab.com Wed Jun 25 05:53:50 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Wed Jun 25 05:53:57 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> Message-ID: On 25 Jun 2008, at 13:26, Bruce Tong wrote: > On Wed, Jun 25, 2008 at 5:39 AM, Christian Scholz / Tao Takashi (SL) > wrote: >> I wonder if everybody knows what those questions are about (like >> scheduling or collection classes). I talked to some Lindens and think >> I know a little bit about the background regarding scheduling and >> ressource limits (at least I have an idea) but maybe this can be >> elaborated upon a little bit on what that means and what collection >> classes are (not everybody is a C# programmer). > > I'm not a C# programmer, but I assumed collection classes referred to > things like a Hashmap in Java. You're correct. That's exactly what it is. A search of ".NET Collections" provides lots of relevant hits. Here is the documentation for those classes: http://msdn.microsoft.com/en-us/library/system.collections.aspx > I've not put a lot of thought into this, but might there be some > undesirable exploits if people are able to upload their own > compilations? I guess I'm wondering if folks might be able to get > outside of what I assume is an isolated or protected runtime > environment and find data to which they should not have? I'm > completely ignorant of the runtime environment of scripts, so these > are probably unjustified concerns. If you're interested in the security that Mono provides you can look at this page: http://www.mono-project.com/CAS Mono also provides a byte code verifier: http://tirania.org/blog/archive/2008/Apr-30.html This checks for lots of security exploits. From timelessprototype at gmail.com Wed Jun 25 05:57:04 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Wed Jun 25 05:57:00 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> Message-ID: <486240A0.5090501@gmail.com> Uploading precompiled binaries worries me a lot, especially after Diniz Cruz's video demonstration of how to root the CLR - permanently disabling security features in the .NET Framework. http://video.google.com/videoplay?docid=-2492965730809426450&q=owasp Babbage Linden might have information about how this will be mitigated? Thanks. - Timeless Prototype Bruce Tong wrote: > On Wed, Jun 25, 2008 at 5:39 AM, Christian Scholz / Tao Takashi (SL) > wrote: >> I wonder if everybody knows what those questions are about (like >> scheduling or collection classes). I talked to some Lindens and think >> I know a little bit about the background regarding scheduling and >> ressource limits (at least I have an idea) but maybe this can be >> elaborated upon a little bit on what that means and what collection >> classes are (not everybody is a C# programmer). > > I'm not a C# programmer, but I assumed collection classes referred to > things like a Hashmap in Java. > > I've not put a lot of thought into this, but might there be some > undesirable exploits if people are able to upload their own > compilations? I guess I'm wondering if folks might be able to get > outside of what I assume is an isolated or protected runtime > environment and find data to which they should not have? I'm > completely ignorant of the runtime environment of scripts, so these > are probably unjustified concerns. > From tateru.nino at gmail.com Wed Jun 25 06:05:19 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 25 06:06:31 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <486240A0.5090501@gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <486240A0.5090501@gmail.com> Message-ID: <4862428F.8050704@weblogsinc.com> It does sound like an awfully reckless notion, unless the CLR implementation is a whole lot more robust than I think it is. Timeless Prototype wrote: > Uploading precompiled binaries worries me a lot, especially after Diniz > Cruz's video demonstration of how to root the CLR - permanently > disabling security features in the .NET Framework. > http://video.google.com/videoplay?docid=-2492965730809426450&q=owasp > > Babbage Linden might have information about how this will be mitigated? > > Thanks. > > - Timeless Prototype > > > Bruce Tong wrote: > >> On Wed, Jun 25, 2008 at 5:39 AM, Christian Scholz / Tao Takashi (SL) >> wrote: >> >>> I wonder if everybody knows what those questions are about (like >>> scheduling or collection classes). I talked to some Lindens and think >>> I know a little bit about the background regarding scheduling and >>> ressource limits (at least I have an idea) but maybe this can be >>> elaborated upon a little bit on what that means and what collection >>> classes are (not everybody is a C# programmer). >>> >> I'm not a C# programmer, but I assumed collection classes referred to >> things like a Hashmap in Java. >> >> I've not put a lot of thought into this, but might there be some >> undesirable exploits if people are able to upload their own >> compilations? I guess I'm wondering if folks might be able to get >> outside of what I assume is an isolated or protected runtime >> environment and find data to which they should not have? I'm >> completely ignorant of the runtime environment of scripts, so these >> are probably unjustified concerns. >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://www.massively.com/ From nchase at earthlink.net Wed Jun 25 06:08:48 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Wed Jun 25 06:08:51 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> Message-ID: <48624360.3090908@earthlink.net> My personal feeling is that I'd rather concentrate on getting capabilities we don't have at all -- such as http in or (ESPECIALLY) confirmation of money transfers -- than features that just make it easier to do things we can do already, albeit with some difficulty. ---- Chase From secret.argent at gmail.com Wed Jun 25 06:13:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 25 06:11:52 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Message-ID: The quota system as described in #1 would absolutely lead to content being broken, and it would almost always be content that was NOT the content that caused the lag that's being fought... since *that* content is already running. If you can't throttle scripts based on quota rather than simply block them, then you probably shouldn't implement quotas at all. I'm also concerned about the quota system that would be used. It has to allow significant overcommitment, because most parcels and most avatars use few scripts, and a parcel with 1/128th of the sim using 1/16th of the available scripting resources is common and not a problem, because scripts are dynamic, and 10 seconds from now it may be using 1/1000th of the available resources and another parcel's using 1/8th. Which is of course another reason to *throttle* rather than *block*. A comment on Tao's comment: > Besides that I would like to be able to use any language which can > produce an mono compatible output (I guess Python fits in there? :-) ) That will probably depend on the size and nature of the runtime. For languages like Python with a significant runtime of their own, and a runtime that includes "dangerous" APIs, I suspect it would take a significant effort from Linden Labs to support safely. I share Bruce Tong's concern about the security implications of allowing arbitrary CIL uploads. The SL environment requires more than usual levels of care... I would let the OpenSim people collect the arrow-holes in their shirts here. From daveh at lindenlab.com Wed Jun 25 06:20:05 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Wed Jun 25 06:20:10 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <48624360.3090908@earthlink.net> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> Message-ID: That's great. Please include your comments in the survey. On 25 Jun 2008, at 14:08, Nicholas Chase wrote: > My personal feeling is that I'd rather concentrate on getting > capabilities we don't have at all -- such as http in or (ESPECIALLY) > confirmation of money transfers -- than features that just make it > easier to do things we can do already, albeit with some difficulty. > > ---- Chase > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From xotmid at gmail.com Wed Jun 25 07:41:00 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Wed Jun 25 07:41:03 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> Message-ID: c# yes! Script quotas = bad and broken content. Right now its hard to do what i do With DCS in lsl.. So many work arounds.. a true programing language and servers that can handle the scripts would be great. On Wed, Jun 25, 2008 at 8:20 AM, Dave Hillier wrote: > That's great. Please include your comments in the survey. > > > On 25 Jun 2008, at 14:08, Nicholas Chase wrote: > > My personal feeling is that I'd rather concentrate on getting capabilities >> we don't have at all -- such as http in or (ESPECIALLY) confirmation of >> money transfers -- than features that just make it easier to do things we >> can do already, albeit with some difficulty. >> >> ---- Chase >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/3b0b16db/attachment-0001.htm From sean at dague.net Wed Jun 25 08:08:43 2008 From: sean at dague.net (Sean Dague) Date: Wed Jun 25 08:08:48 2008 Subject: [sldev] Re: Scripting projects priority survey In-Reply-To: References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Message-ID: <20080625150843.GI10012@dague.net> On Wed, Jun 25, 2008 at 08:13:42AM -0500, Argent Stonecutter wrote: > That will probably depend on the size and nature of the runtime. For > languages like Python with a significant runtime of their own, and a > runtime that includes "dangerous" APIs, I suspect it would take a > significant effort from Linden Labs to support safely. > > I share Bruce Tong's concern about the security implications of allowing > arbitrary CIL uploads. The SL environment requires more than usual levels > of care... I would let the OpenSim people collect the arrow-holes in > their shirts here. Heh. That's ok, we tend to wear thick jackets. ;) Fwiw, while OpenSim does use assemblies for script execution, it doesn't let the user upload them. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080625/1f542bdb/attachment.pgp From brad at lindenlab.com Wed Jun 25 08:18:01 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Wed Jun 25 08:15:45 2008 Subject: [sldev] Compiling/VS2003: 1.19.1.4 link.exe Build non-errors? In-Reply-To: References: Message-ID: <486261A9.4030300@lindenlab.com> I've seen the nologo error before when cygwin link.exe (symlink/shorcut creation) is being accidentally executed instead of MSVC's link.exe. The solution is to move the cygwin dirs to the bottom of your MSVC path configuration. The unistd.h error is a bug in bison (maybe flex?). It will work if you use an older version of bison or a newer version of our source which contains a workaround. Alternatively you can apply the workaround manually to your version of the source (see details https://lists.secondlife.com/pipermail/sldev/2008-April/009426.html) -Brad Dale Mahalko wrote: > The problem: > > Linking... > link: extra operand `/NOLOGO' > Try `link --help' for more information. > win_crash_logger : error PRJ0002 : error result returned from 'link.exe'. > > > Rather than include attachments, I've put the four error logs here: > https://wiki.secondlife.com/wiki/User:Scalar_Tardis/NOLOGO-Compile-Err > > >From searching for NOLOGO I see it's in 18 other logs without a > problem. I've included one of those success logs as well. > > > - Scalar Tardis / Dale Mahalko > > > On Wed, Jun 25, 2008 at 3:08 AM, Robin Cornelius > wrote: > >> Yea a tad odd, there is information missing. I think VS is being >> helpful and only showing you the build summary window. Can you try to >> find the build results window, it should be a lot more helpful and >> give the actual error (its the "Output" window you need from View >> Menu). Hopefully that will tell you some more. >> >> Robin >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From secret.argent at gmail.com Wed Jun 25 08:43:16 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 25 08:43:22 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <48624360.3090908@earthlink.net> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> Message-ID: <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> On 2008-06-25, at 08:08, Nicholas Chase wrote: My personal feeling is that I'd rather concentrate on getting capabilities we don't have at all -- such as http in or (ESPECIALLY) confirmation of money transfers -- than features that just make it easier to do things we can do already, albeit with some difficulty. That's my feeling, and how I voted. I would also like to get confirmation of asset delivery, and identification of the agent responsible for inventory changes via llAllowInventoryDrop(). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/5520cfe5/attachment.htm From kelly at lindenlab.com Wed Jun 25 09:16:48 2008 From: kelly at lindenlab.com (Kelly) Date: Wed Jun 25 09:16:55 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> Message-ID: <48626F70.7090000@lindenlab.com> It is probably worth noting that with C# comes several new capabilities we don't have at all, just a couple off the top of my head are proper data types (arrays, maps) and pass by reference. On a new-feature-not-possible-before-per-project weighting, I'm pretty sure allowing C# ranks at the top and probably by a very large margin. It is just a matter of how important those features are *to you* compared to the others, which is the point of the survey. :D It is of course perfectly fine to discuss the proposed projects here - just keep in mind that discussion here is not going to be aggregated in the survey results. The survey is also obviously only one point of data to be used in setting our priorities - but a pretty valuable one. - Kelly Argent wrote: > On 2008-06-25, at 08:08, Nicholas Chase wrote: > My personal feeling is that I'd rather concentrate on getting > capabilities we don't have at all -- such as http in or (ESPECIALLY) > confirmation of money transfers -- than features that just make it > easier to do things we can do already, albeit with some difficulty. > > That's my feeling, and how I voted. > > I would also like to get confirmation of asset delivery, and > identification of the agent responsible for inventory changes via > llAllowInventoryDrop(). > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/11a37673/attachment.htm From jhurliman at jhurliman.org Wed Jun 25 09:25:06 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Wed Jun 25 09:25:09 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Message-ID: > A comment on Tao's comment: > >> Besides that I would like to be able to use any language which can >> produce an mono compatible output (I guess Python fits in there? :-) ) >> > > That will probably depend on the size and nature of the runtime. For > languages like Python with a significant runtime of their own, and a runtime > that includes "dangerous" APIs, I suspect it would take a significant effort > from Linden Labs to support safely. > > The preferred target would be IronPython ( http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython) as it compiles down to CIL like C# and the new LSL server-side compile. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/e1c2d986/attachment.htm From jhurliman at jhurliman.org Wed Jun 25 09:59:33 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Wed Jun 25 09:59:37 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> Message-ID: On Wed, Jun 25, 2008 at 5:26 AM, Bruce Tong wrote: > > ... > > I've not put a lot of thought into this, but might there be some > undesirable exploits if people are able to upload their own > compilations? I guess I'm wondering if folks might be able to get > outside of what I assume is an isolated or protected runtime > environment and find data to which they should not have? I'm > completely ignorant of the runtime environment of scripts, so these > are probably unjustified concerns. > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University The idea is to run code in a sandbox using a customized version of Mono (open source implementation of the .NET runtime/framework). To do anything clever in any language you need functions that let you do clever things. For example, peeking at memory you shouldn't see requires a function that lets you look at memory, or a pointer that you can manipulate to point outside where it should see. The sandbox removes all unsafe code (unsafe in this context meaning code marked with the unsafe keyword which gives you access to pointers) and is not compiled with any framework except for LL's API. You end up with something that is no less secure than the original LSL language, but you're coding in a more refined syntax that compiles to a common instruction set. For reference, the "Rooting the CLR" presentation is talking about using full security .NET apps to patch the CLR at runtime. An important talk, but not applicable to sandboxed runtimes. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/96682bbf/attachment.htm From nchase at earthlink.net Wed Jun 25 10:11:43 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Wed Jun 25 10:11:49 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <48626F70.7090000@lindenlab.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> <48626F70.7090000@lindenlab.com> Message-ID: <48627C4F.9060204@earthlink.net> Kelly wrote: > It is probably worth noting that with C# comes several new capabilities > we don't have at all, just a couple off the top of my head are proper > data types (arrays, maps) and pass by reference. On a > new-feature-not-possible-before-per-project weighting, I'm pretty sure > allowing C# ranks at the top and probably by a very large margin. It is > just a matter of how important those features are *to you* compared to > the others, which is the point of the survey. :D Of course. :) And I'm looking forward to hearing how the survey turns out. But seriously, anything you can do with arrays, maps, and pass by reference, you can do in LSL, it just takes a little more ingenuity (and hassle). But you can't have a legitimate business application that involves money transfers if you can't detect whether the transfer was successful. ---- Chase From tao.takashi at googlemail.com Wed Jun 25 11:05:58 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed Jun 25 11:06:02 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <48627C4F.9060204@earthlink.net> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> <48626F70.7090000@lindenlab.com> <48627C4F.9060204@earthlink.net> Message-ID: <23bbb49e0806251105vb182d8dmd8fddfa47c72305d@mail.gmail.com> On Wed, Jun 25, 2008 at 7:11 PM, Nicholas Chase wrote: > > > Kelly wrote: >> >> It is probably worth noting that with C# comes several new capabilities we >> don't have at all, just a couple off the top of my head are proper data >> types (arrays, maps) and pass by reference. On a >> new-feature-not-possible-before-per-project weighting, I'm pretty sure >> allowing C# ranks at the top and probably by a very large margin. It is >> just a matter of how important those features are *to you* compared to the >> others, which is the point of the survey. :D > > Of course. :) And I'm looking forward to hearing how the survey turns out. > > But seriously, anything you can do with arrays, maps, and pass by reference, > you can do in LSL, it just takes a little more ingenuity (and hassle). But > you can't have a legitimate business application that involves money > transfers if you can't detect whether the transfer was successful. Sure, but still I see LSL as somewhat broken for serious applications and I'd rather see it become replaced by something better sooner than later instead of taking time to add new features to it which you might need to reimplement later then. So the argument is that nobody should be writing serious applications in LSL anyway ;-) (but everybody is doing it because there is no alternative)l -- Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From secret.argent at gmail.com Wed Jun 25 11:35:16 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 25 11:35:23 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <48626F70.7090000@lindenlab.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> <48626F70.7090000@lindenlab.com> Message-ID: <16309a040806251135g3ac3c269n2848ce7274f69ebf@mail.gmail.com> Kelly, I did make similar comments in my response to the survey. Since there's no way to go back and update the survey, should I take it again? :) On Wed, Jun 25, 2008 at 11:16 AM, Kelly wrote: > It is of course perfectly fine to discuss the proposed projects here - just > keep in mind that discussion here is not going to be aggregated in the > survey results. The survey is also obviously only one point of data to be > used in setting our priorities - but a pretty valuable one. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/6ab677fc/attachment.htm From nchase at earthlink.net Wed Jun 25 11:37:46 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Wed Jun 25 11:37:49 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <23bbb49e0806251105vb182d8dmd8fddfa47c72305d@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> <48626F70.7090000@lindenlab.com> <48627C4F.9060204@earthlink.net> <23bbb49e0806251105vb182d8dmd8fddfa47c72305d@mail.gmail.com> Message-ID: <4862907A.3040806@earthlink.net> Christian Scholz / Tao Takashi (SL) wrote: > Sure, but still I see LSL as somewhat broken for serious applications > and I'd rather see it become replaced by something better sooner than > later instead of taking time to add new features to it which you might > need to reimplement later then. So the argument is that nobody should > be writing serious applications in LSL anyway ;-) (but everybody is > doing it because there is no alternative)l Tao, if we have to wait until SL's scripting is perfect before we start writing serious applications, we might as well pack it in and go home now. :) Forgive me for making the web analogy, but I don't think that anybody would have envisioned today's application environment when looking at HTML 1.0 and early CGI, but it was those applications that pushed the web to what it is now. ---- Chase From secret.argent at gmail.com Wed Jun 25 11:46:44 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 25 11:46:47 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> Message-ID: <16309a040806251146r24fc769ahd256eb7391f03b73@mail.gmail.com> On Wed, Jun 25, 2008 at 11:59 AM, John Hurliman wrote: > The idea is to run code in a sandbox using a customized version of Mono > (open source implementation of the .NET runtime/framework). To do anything > clever in any language you need functions that let you do clever things. For > example, peeking at memory you shouldn't see requires a function that lets > you look at memory, or a pointer that you can manipulate to point outside > where it should see. The sandbox removes all unsafe code (unsafe in this > context meaning code marked with the unsafe keyword which gives you access > to pointers) and is not compiled with any framework except for LL's API. You > end up with something that is no less secure than the original LSL language, > but you're coding in a more refined syntax that compiles to a common > instruction set. I've implemented "inherently secure" languages for real-time control systems, web frameworks, and user-side scripting, and I've also followed the development of the Java sandbox (and found some security flaws in their proxy handling for them). I've found that it's not as simple as removing all code that gives you access to pointers: you have to examine every component that you're going to make available through the language to make sure that it conforms to the same protection model that you're trying to implement. Most common components do satisfy that constraint, but not always, so you do have to audit everything you add. And the exposed C# runtime will have to be a superset of the LSL one... providing access to more capable components is one of the reasons for doing this. Have a look at the kinds of odd interactions the Javascript runtime (which is "inherently safe" in this sense) has run afoul of, to get an idea of what it would take to incorporate any rich scripting language like Python or Lua or Tcl. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/33ca6f3c/attachment.htm From schlenk at uni-oldenburg.de Wed Jun 25 11:53:08 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Wed Jun 25 11:53:15 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <16309a040806251146r24fc769ahd256eb7391f03b73@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <16309a040806251146r24fc769ahd256eb7391f03b73@mail.gmail.com> Message-ID: Am 25.06.2008 um 20:46 schrieb Argent: > On Wed, Jun 25, 2008 at 11:59 AM, John Hurliman > wrote: > The idea is to run code in a sandbox using a customized version of > Mono (open source implementation of the .NET runtime/framework). To > do anything clever in any language you need functions that let you > do clever things. For example, peeking at memory you shouldn't see > requires a function that lets you look at memory, or a pointer that > you can manipulate to point outside where it should see. The sandbox > removes all unsafe code (unsafe in this context meaning code marked > with the unsafe keyword which gives you access to pointers) and is > not compiled with any framework except for LL's API. You end up with > something that is no less secure than the original LSL language, but > you're coding in a more refined syntax that compiles to a common > instruction set. > > I've implemented "inherently secure" languages for real-time control > systems, web frameworks, and user-side scripting, and I've also > followed the development of the Java sandbox (and found some > security flaws in their proxy handling for them). I've found that > it's not as simple as removing all code that gives you access to > pointers: you have to examine every component that you're going to > make available through the language to make sure that it conforms to > the same protection model that you're trying to implement. Most > common components do satisfy that constraint, but not always, so you > do have to audit everything you add. And the exposed C# runtime will > have to be a superset of the LSL one... providing access to more > capable components is one of the reasons for doing this. > > Have a look at the kinds of odd interactions the Javascript runtime > (which is "inherently safe" in this sense) has run afoul of, to get > an idea of what it would take to incorporate any rich scripting > language like Python or Lua or Tcl. Tcl and Lua might be the easiest from a security standpoint, at least Tcl has a similar sandbox model and you can quite safely strip out any non wanted functionality. But fully agreed with your statment that its a huge task to security review all those modules you might give access to. Another example of stripped down environment which faces similar problems might be the nearly crippled python subsystem in Google App Engine. Michael From secret.argent at gmail.com Wed Jun 25 11:53:20 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 25 11:53:23 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: <23bbb49e0806251105vb182d8dmd8fddfa47c72305d@mail.gmail.com> References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> <4f335a50806250526ta18de63ge177f09a7905ee91@mail.gmail.com> <48624360.3090908@earthlink.net> <16309a040806250843k1e711342i12513bb05393d762@mail.gmail.com> <48626F70.7090000@lindenlab.com> <48627C4F.9060204@earthlink.net> <23bbb49e0806251105vb182d8dmd8fddfa47c72305d@mail.gmail.com> Message-ID: <16309a040806251153te57ed72k327f084043ee57a@mail.gmail.com> On Wed, Jun 25, 2008 at 1:05 PM, Christian Scholz / Tao Takashi (SL) < tao.takashi@googlemail.com> wrote: > Sure, but still I see LSL as somewhat broken for serious applications > and I'd rather see it become replaced by something better sooner than > later instead of taking time to add new features to it which you might > need to reimplement later then. We're not concerned so much about adding new features to LSL, but adding new features to the runtime... the llFunction() calls that LSL2 and CIL code alike will be calling regardless of the language it was written in. The specific calls discussed in the survey and the others that have been discussed here aren't "LSL Calls", they're "Linden runtime library" calls that are currently being called from LSL: whether you're writing code in LSL or C#, you will need to call the same functions to transfer money or accept HTTP connections. This is not work that has to be "reimplemented", this is work that will automatically work for LSL2 and CIL code alike. They're even using the same compiler right now... look at the tree walker in the LSL compiler: it's got code to generate CIL, and some residents have already identified bugs in the CIL implementation by simple examination of the source. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/e33d5532/attachment.htm From blindwanderer at gmail.com Wed Jun 25 13:21:49 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Wed Jun 25 13:21:51 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: <4861B47B.2050009@gmail.com> <89ca6da00806242305k12055619m5783e86c460e1e6d@mail.gmail.com> Message-ID: <89ca6da00806251321w7c788e89nd43da7c9af79c39e@mail.gmail.com> > Feedback about one of 1.20's key features has also resulted in the > release being held up for a pretty significant rework. Ohhhhh cryptic. Mind letting us in on the secret... which feature is it? From bridie at lindenlab.com Wed Jun 25 14:04:11 2008 From: bridie at lindenlab.com (Bridie Linden) Date: Wed Jun 25 14:04:14 2008 Subject: [sldev] Upcoming Releases: June edition Message-ID: <4862B2CB.5060604@lindenlab.com> Hello again SLDev folks! It's time for another update on our release plans... == Viewer: /"...and ya don't stop" ==/ That's right, take off your shoes + socks to keep count --- we're on the 12th iteration of the 1.20 Release Candidate Viewer. 1.20 RC11 will be available for download today. A showstopper was found last week that prevented us from shipping. RC11 has 4 more crash fixes and an important fix to a major source of memory leaks. We've been listening to the feedback on Dazzle --- specifically, the request that the Dazzle UI be optional (See VWR-5059). We've decided to take the next several weeks to implement the ability to toggle between pre-installed skins (Classic look vs. Dazzle) via a preference in the Viewer UI and thus extend the 1.20 RC cycle further. We had originally included skin-switching in our plans, but upped the priority after taking a look @ all of the feedback we've received. We want everyone to be able to benefit from the many bug/crash fixes in 1.20 rather than have the fans of the "Classic" viewer look continue to use the 1.19.1 viewer. The work required to do this is shared across Dev, Rx and the QA teams. While the complexity is fairly small, it will take time to update the UI and confirm the changes. We expect to do at least 2 more iterations of the 1.20 Release Candidate before we call it Final, likely early August. Please continue to report any new issues in PJIRA and set "Affects Version/s" to "1.20 Release Candidate". We appreciate your patience and help making 1.20 as solid as possible! Heads up for Mono fans, 1.20 RC12 is planned to include the Viewer UI changes for Mono! Note, the Mono-viewer UI will be greyed out until the Mono simulators are deployed in late July. See below for details on when Mono will be rolling out in production. For now, this capability can be tested by logging on to the Preview Grid. == Server: /"...keep on movin'"/ == This week brings us another server patch rolling restart. 1.22.4 is being deployed this week to address a couple of security issues that were identified and fixed. 1.22.4 has already been deployed to the "Beta Server" channel on the Preview Grid (aditi). Your help testing out new simulators on the Preview Grid before they hit the Main Live Grid is always appreciated --- be sure to set "Affects Version/s" to "1.22.4 Server". As of Wednesday 6/25, 1.22.4 has been rolled out to half of the simulators on the Main Live Grid. The 1.23 Server is still approximately 2 weeks out as we take the time to stabilize the tip of our trunk branch. 1.23 Server doesn't currently contain any super exciting new code, but does include some Havok4 and other bug fixes. Expect 1.23 Server to hit the Preview Grid some time next week. The 1.24 Server is planned for 2 or 3 weeks after 1.23 --- 3 weeks after 1.23 if we decide to pause for a week and not release any new server code. Drum roll please...1.24 is planned to include Mono! Check out Mono on the Preview Grid now: http://blog.secondlife.com/2008/06/18/mono-beta-refresh-11/ Thanks for your patience + interest. --Bridie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/03ff9ae5/attachment.htm From jpirkola at gmail.com Wed Jun 25 14:29:42 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Wed Jun 25 14:29:45 2008 Subject: [sldev] realXtend new release coming this Friday Message-ID: <6c9557390806251429s2f78a12ax31d71ecfb94f3510@mail.gmail.com> Dear all, I am proud to announce that we will release realXtend viewer 0.3 (based on SL Viewer) and realXtend server 0.3 (based on OpenSim) versions this Friday. Check our web site at www.realxtend.org for cool new videos and to get idea of the new features! We will merge code from the latest SL Viewer during August, and we will also have steady monthly releases starting from the end of August. The server is now based on a quite new version of OpenSim. realXtend viewer can still be used to go to Second Life, and one of the new features is the address bar that you can use to teleport between OpenSim, SecondLife and realXtend worlds. You can also use teleport script to teleport you from SL to e.g. Openlifegrid: llMapDestination("rex://logingrid.net:8002", <100, 100, 0>, ZERO_VECTOR); Note: We are still far away from 1.0 stable release, but we are working full speed to that direction! Best regards, Jani Pirkola/realXtend -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080626/d3575508/attachment.htm From liana at lindenlab.com Wed Jun 25 15:29:06 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Wed Jun 25 15:29:09 2008 Subject: [sldev] Hippo Awards -- call for nominations Message-ID: <4862C6B2.3030304@lindenlab.com> The hippo returns! We are now accepting nominations for the second annual Linden Lab Innovation Awards. Also known as The Hippos, these awards honor community members who have had the most significant impact on the Second Life open source viewer project over the last year. Please help us acknowledge the work of your peers by nominating candidates in the categories listed in the "How It Works" section below. Thanks to this community, the Second Life open source project has grown quite a bit this last year, with excellent contributions showing up not only in the issue tracker but also in documentation and community participation. Consider these highlights: Since this time last year, we have seen sldev list membership double and total patches accepted into the release viewer almost triple. Community members have joined in the Architecture Working Group effort to write open protocols for virtual worlds. Bug triages, office hours and team meetings have been well-attended, with invaluable guidance, technical assistance and organizational help coming from the community. You're all to be congratulated. On behalf of Linden Lab, I thank you for the thought and effort you have put toward the success of this project. Read on and help us thank the superheros of our community! Best, Liana P.S. By the way, if you're not familiar with the hippo meme, the hippo has long been "the mascot" of Second Life. In the early days, Linden service announcements on the public forums would often feature the dramatic doings of super-powered yet secretive hippos who kept the grid safe from bugs released by evil gnomes. It seemed an appropriate icon for the open source project. - - - - - HOW IT WORKS = Nominations = If you would like to nominate your open source peers for a Hippo Award, then please * sign in to the Issue Tracker and add the person's Second Life avatar name as a subtask to the appropriate category (below), and * write a comment about what their contribution was and why you find it to be exemplary. Please cite jira issues, wiki pages or other examples of the contribution wherever possible. Nominations are open from now through 2008 July 8 at noon PDT.* * Additional notes: * Although the issue tracker has a voting feature, winners will not be selected by popular vote but through the jury process described below. * Please create only one jira issue per nominee per category. You are welcome to second a nomination by commenting on the jira opened in that nominee's name. * People may be nominated in multiple applicable categories. == Eligibility == * Nominees are eligible to win if their contribution was made between 2007/07/01 and 2008/06/30. * Linden Lab employees and family members are not eligible to win. == Judging == These are juried awards, and winners will be selected based on a point system used by the judges. The judges panel will be comprised of Linden open source team members and developers. = Categories = Nominees should exhibit not only a great track record in their respective categories but also exemplify core community values of collegiality and respect. Visit the jira links below to read a description of the category and make nominations. * Best Documentation MISC-1301 * Best Project Organizer MISC-1302 * Best Contribution MISC-1303 * The Jesse Malthus Award for Best Community Influence MISC-1304 * Contributor of the Year MISC-1305 We have redefined some of the categories from last year and added a new one in order to reduce overlap and increase coverage of the breadth of work coming from the community. = Awards = Award winners will be announced in early September. I'll be sending another message with the exact date, time and location of this event. You can see last year's award announcement on the blog . == Prizes == The 2007 Hippo Award winners received a rent-free parcel on the open source island Hippotropolis for one year and a gift of Linden dollars. The Contributor of the Year also received a Macintosh computer. Based on feedback from the 2007 winners, we'll be making some changes to the prize types and distribution this year, though the overall value of the prizes will be similar. A later announcement will detail this year's prizes. - - - - - The LINDEN LAB INNOVATION AWARDS are for entertainment purposes only and have no monetary or other value. LINDEN LAB, LINDEN RESEARCH, and SECOND LIFE are trademarks or registered trademarks of Linden Research, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/8117cff4/attachment.htm From grant at lindenlab.com Wed Jun 25 15:33:06 2008 From: grant at lindenlab.com (Steven Grant (Grant Linden)) Date: Wed Jun 25 15:33:12 2008 Subject: [sldev] Notifications Redesign Presentation Message-ID: <4862C7A2.2080103@lindenlab.com> This week at the Resident Experience Office hours, Malbers Linden Will be presenting on the Notifications Redesign. Thursday June 25th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience --------------- Grant Linden User Experience Designer Linden Lab | Second Life From poppy at lindenlab.com Wed Jun 25 16:38:32 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Wed Jun 25 16:38:46 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: <89ca6da00806251321w7c788e89nd43da7c9af79c39e@mail.gmail.com> References: <4861B47B.2050009@gmail.com><89ca6da00806242305k12055619m5783e86c460e1e6d@mail.gmail.com> <89ca6da00806251321w7c788e89nd43da7c9af79c39e@mail.gmail.com> Message-ID: <4862D6F8.8050109@lindenlab.com> Strife Onizuka wrote: >> Feedback about one of 1.20's key features has also resulted in the >> release being held up for a pretty significant rework. > > Ohhhhh cryptic. Mind letting us in on the secret... which feature is it? 1.20: http://blog.secondlife.com/2008/06/25/now-available-optional-release-candidate-viewer-120-rc11-dazzle-we-hear-you/ internal trunk... err, "release" branch export is just broken right now, so we're holding off updating that. Sorry, we're on it. + poppy From sldev at free.fr Wed Jun 25 16:51:17 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Jun 25 16:51:18 2008 Subject: [sldev] Upcoming Releases: June edition In-Reply-To: <4862B2CB.5060604@lindenlab.com> References: <4862B2CB.5060604@lindenlab.com> Message-ID: <20080626015117.650eb842.sldev@free.fr> On Wed, 25 Jun 2008 14:04:11 -0700, Bridie Linden wrote: > Hello again SLDev folks! > It's time for another update on our release plans... > > == Viewer: /"...and ya don't stop" ==/ > That's right, take off your shoes + socks to keep count --- we're on the > 12th iteration of the 1.20 Release Candidate Viewer. 1.20 RC11 will be > available for download today. A showstopper was found last week that > prevented us from shipping. RC11 has 4 more crash fixes and an > important fix to a major source of memory leaks. > > We've been listening to the feedback on Dazzle --- specifically, the > request that the Dazzle UI be optional (See VWR-5059). We've decided to > take the next several weeks to implement the ability to toggle between > pre-installed skins (Classic look vs. Dazzle) via a preference in the > Viewer UI and thus extend the 1.20 RC cycle further. Excellent ! At least, LL did hear us... :-) Let's hope this new trend will become the norm and that users feedback will truly be taken into account for future changes to the viewer. > We had originally included skin-switching in our plans, but upped the > priority after taking a look @ all of the feedback we've received. We > want everyone to be able to benefit from the many bug/crash fixes in > 1.20 rather than have the fans of the "Classic" viewer look continue to > use the 1.19.1 viewer. There will still be the users that, like me, stick with the viewers (Nicholaz' or mine, for example) implementing the good old pre-voice like UI (the horrendeous chatterbox and the permanent huge music/media controls that eat up the chat input line are just impossible to bear for us). While you are at it, perhaps would it be time to give us back that good old UI... Oh... and also, give us back the "fly" button in the movement controls floater, the permanent "Tools" menu bar entry, the friends and groups buttons in the toolbar, and... and... oh, well have a look at the Cool SL Viewer and you will see what I mean... ;-P > The work required to do this is shared across Dev, Rx and the QA teams. > While the complexity is fairly small, it will take time to update the UI > and confirm the changes. We expect to do at least 2 more iterations of > the 1.20 Release Candidate before we call it Final, likely early > August. Excellent ! It was time to put a stop at the mad rush for express releases that v1.19 went through and which caused so many troubles for so many residents. Till and including v1.18.0.6 almost every new release was a pleasure to see coming and use, but from v1.18.1 and till v1.20, every new viewer version has been a real pain, both in stability and usability. Regards, Henri. From sldev at free.fr Thu Jun 26 00:29:44 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Jun 26 00:29:41 2008 Subject: [sldev] Sources for v1.20RC11, please ? Message-ID: <20080626092944.5df1528b.sldev@free.fr> Just what the subject says... :-) From robin.cornelius at gmail.com Thu Jun 26 04:05:54 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 26 04:05:57 2008 Subject: [sldev] [VWR] gcc 4.1.2 and viewer 1.20.10 Message-ID: Hi everyone, Having a gcc issue on 1.20.10 also reported on JIRA as VWR-7831. x86_64-linux-client-release/newview/llviewerregion.cpp:111: error: no match for 'operator!=' in 'this != LLViewerRegion::getHttpResponderPtr() const()' I'm assuming gcc 4.1.2 cannot handle the implicit casting required here. 4.1.3 and newer seems ok but this is a particular problem for me as i need to build on 4.1.2 (the version in debian etch) to avoid a whole world of distribution issues with my viewer packages. Is the fix as simple as an explicit cast? or is gcc just deciding the pointers are of different classes and as there is no = operator defined, balking at what it thinks it cannot do? Thanks for any help on this one! Robin From bboomslang at googlemail.com Thu Jun 26 04:46:10 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Thu Jun 26 04:46:12 2008 Subject: [sldev] Scripting projects priority survey In-Reply-To: References: <5833C1B5-C700-483A-B127-121D0597AB2E@lindenlab.com> <23bbb49e0806250239w1c438e6di73eb2a6ed0a3f375@mail.gmail.com> Message-ID: <347b550f0806260446s4e4f4a4bp64115bfbb63abc36@mail.gmail.com> Hey, yep, I totally agree with Argent. Experiences from the Linux Kernel and the OOM process killer there should be a warning sign to everybody - because the one process that gets the troubles most often isn't the actual reason for the problems. A much more deterministic behaviour would be preferable over that idea. (side note: my fav. point on the list is HTTP in, as that would allmost remove the need for C# on the server for me - LSL would be reduced to UI programming, for which it might be cumbersome, but useable, and server side would work efficiently with the UI, without the need of polling. Yummy!) bye, Barney On Wed, Jun 25, 2008 at 3:13 PM, Argent Stonecutter wrote: > The quota system as described in #1 would absolutely lead to content being > broken, and it would almost always be content that was NOT the content that > caused the lag that's being fought... since *that* content is already > running. If you can't throttle scripts based on quota rather than simply > block them, then you probably shouldn't implement quotas at all. > > I'm also concerned about the quota system that would be used. It has to > allow significant overcommitment, because most parcels and most avatars use > few scripts, and a parcel with 1/128th of the sim using 1/16th of the > available scripting resources is common and not a problem, because scripts > are dynamic, and 10 seconds from now it may be using 1/1000th of the > available resources and another parcel's using 1/8th. Which is of course > another reason to *throttle* rather than *block*. > > A comment on Tao's comment: > >> Besides that I would like to be able to use any language which can >> produce an mono compatible output (I guess Python fits in there? :-) ) >> > > That will probably depend on the size and nature of the runtime. For > languages like Python with a significant runtime of their own, and a runtime > that includes "dangerous" APIs, I suspect it would take a significant effort > from Linden Labs to support safely. > > I share Bruce Tong's concern about the security implications of allowing > arbitrary CIL uploads. The SL environment requires more than usual levels of > care... I would let the OpenSim people collect the arrow-holes in their > shirts here. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080626/fe0b3bf6/attachment.htm From q at lindenlab.com Thu Jun 26 06:19:14 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu Jun 26 06:19:20 2008 Subject: [sldev] [VWR] gcc 4.1.2 and viewer 1.20.10 In-Reply-To: References: Message-ID: <8569A822-FBCF-496F-B88E-911E2F28DB74@lindenlab.com> Hi, I'm deep in another branch right now, but from looking over the code briefly, I'm guessing that you're running into a problem comparing a smart pointer to a base class to a smart pointer to a subclass. Instead of: this != LLViewerRegion::getHttpResponderPtr() Please try: !(this == LLViewerRegion::getHttpResponderPtr()) If that fails, another option might be: LLHTTPClient::ResponderPtr(this) != LLViewerRegion::getHttpResponderPtr() These are boost::intrusive_ptr objects, so that last one should be safe. Q On Jun 26, 2008, at 7:05 AM, Robin Cornelius wrote: > Hi everyone, > > Having a gcc issue on 1.20.10 also reported on JIRA as VWR-7831. > > x86_64-linux-client-release/newview/llviewerregion.cpp:111: error: no > match for 'operator!=' in 'this != > LLViewerRegion::getHttpResponderPtr() const()' > > I'm assuming gcc 4.1.2 cannot handle the implicit casting required > here. 4.1.3 and newer seems ok but this is a particular problem for me > as i need to build on 4.1.2 (the version in debian etch) to avoid a > whole world of distribution issues with my viewer packages. > > Is the fix as simple as an explicit cast? or is gcc just deciding the > pointers are of different classes and as there is no = operator > defined, balking at what it thinks it cannot do? > > Thanks for any help on this one! > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From soft at lindenlab.com Thu Jun 26 06:32:36 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 26 06:32:39 2008 Subject: [sldev] Sources for v1.20RC11, please ? In-Reply-To: <20080626092944.5df1528b.sldev@free.fr> References: <20080626092944.5df1528b.sldev@free.fr> Message-ID: On Thu, Jun 26, 2008 at 2:29 AM, Henri Beauchamp wrote: > Just what the subject says... :-) Of course. Up at https://wiki.secondlife.com/wiki/Source_downloads From Dana.Fagerstrom at Sun.COM Thu Jun 26 06:33:18 2008 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jun 26 06:33:23 2008 Subject: [sldev] [VWR] gcc 4.1.2 and viewer 1.20.10 In-Reply-To: <8569A822-FBCF-496F-B88E-911E2F28DB74@lindenlab.com> References: <8569A822-FBCF-496F-B88E-911E2F28DB74@lindenlab.com> Message-ID: <48639A9E.5030307@sun.com> I was getting the same problem with gcc 3.4! I fixed it with: (LLHTTPClient::ResponderPtr) this != mRegion->getHttpResponderPtr()) D Kent Quirk (Q Linden) wrote: > Hi, > > I'm deep in another branch right now, but from looking over the code > briefly, I'm guessing that you're running into a problem comparing a > smart pointer to a base class to a smart pointer to a subclass. > > Instead of: > this != LLViewerRegion::getHttpResponderPtr() > Please try: > !(this == LLViewerRegion::getHttpResponderPtr()) > > If that fails, another option might be: > > LLHTTPClient::ResponderPtr(this) != > LLViewerRegion::getHttpResponderPtr() > > These are boost::intrusive_ptr objects, so that last one should be safe. > > Q > > > On Jun 26, 2008, at 7:05 AM, Robin Cornelius wrote: > >> Hi everyone, >> >> Having a gcc issue on 1.20.10 also reported on JIRA as VWR-7831. >> >> x86_64-linux-client-release/newview/llviewerregion.cpp:111: error: no >> match for 'operator!=' in 'this != >> LLViewerRegion::getHttpResponderPtr() const()' >> >> I'm assuming gcc 4.1.2 cannot handle the implicit casting required >> here. 4.1.3 and newer seems ok but this is a particular problem for me >> as i need to build on 4.1.2 (the version in debian etch) to avoid a >> whole world of distribution issues with my viewer packages. >> >> Is the fix as simple as an explicit cast? or is gcc just deciding the >> pointers are of different classes and as there is no = operator >> defined, balking at what it thinks it cannot do? >> >> Thanks for any help on this one! >> >> Robin >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -- ===================================================================== Dana Fagerstrom Phone: 877.851.6343 Sun Services Fax: 877.851.6343 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM Somerset, NJ 08873 SneakerNet: USMT01 ===================================================================== Pressure - It can turn a lump of coal into a flawless diamond, and an average person into a perfect basketcase. -- www.despair.com ===================================================================== From q at lindenlab.com Thu Jun 26 07:19:09 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu Jun 26 07:20:20 2008 Subject: [sldev] [VWR] gcc 4.1.2 and viewer 1.20.10 In-Reply-To: <48639A9E.5030307@sun.com> References: <8569A822-FBCF-496F-B88E-911E2F28DB74@lindenlab.com> <48639A9E.5030307@sun.com> Message-ID: <516C0FD9-FDE0-4025-ABE1-8838122A4A41@lindenlab.com> Yes, I *believe* that in this case that's equivalent to the constructor form (don't have my C++ reference handy), but it's an old style cast, which is often equivalent to reinterpret_cast and a bit of a blunt instrument. In general, using the constructor form or a C++- style cast is the preferred methodology these days. Q On Jun 26, 2008, at 9:33 AM, Dana Fagerstrom wrote: > I was getting the same problem with gcc 3.4! I fixed it with: > > (LLHTTPClient::ResponderPtr) this != mRegion- > >getHttpResponderPtr()) > > D > > Kent Quirk (Q Linden) wrote: >> Hi, >> I'm deep in another branch right now, but from looking over the >> code briefly, I'm guessing that you're running into a problem >> comparing a smart pointer to a base class to a smart pointer to a >> subclass. >> Instead of: >> this != LLViewerRegion::getHttpResponderPtr() >> Please try: >> !(this == LLViewerRegion::getHttpResponderPtr()) >> If that fails, another option might be: >> LLHTTPClient::ResponderPtr(this) != >> LLViewerRegion::getHttpResponderPtr() >> These are boost::intrusive_ptr objects, so that last one should be >> safe. >> Q >> On Jun 26, 2008, at 7:05 AM, Robin Cornelius wrote: >>> Hi everyone, >>> >>> Having a gcc issue on 1.20.10 also reported on JIRA as VWR-7831. >>> >>> x86_64-linux-client-release/newview/llviewerregion.cpp:111: error: >>> no >>> match for 'operator!=' in 'this != >>> LLViewerRegion::getHttpResponderPtr() const()' >>> >>> I'm assuming gcc 4.1.2 cannot handle the implicit casting required >>> here. 4.1.3 and newer seems ok but this is a particular problem >>> for me >>> as i need to build on 4.1.2 (the version in debian etch) to avoid a >>> whole world of distribution issues with my viewer packages. >>> >>> Is the fix as simple as an explicit cast? or is gcc just deciding >>> the >>> pointers are of different classes and as there is no = operator >>> defined, balking at what it thinks it cannot do? >>> >>> Thanks for any help on this one! >>> >>> Robin >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated >>> posting privileges >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > -- > ===================================================================== > Dana Fagerstrom Phone: 877.851.6343 > Sun Services Fax: 877.851.6343 > 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM > Somerset, NJ 08873 SneakerNet: USMT01 > ===================================================================== > Pressure - It can turn a lump of coal into a flawless diamond, > and an average person into a perfect basketcase. > -- www.despair.com > ===================================================================== > From drew at alliancenavy.org Thu Jun 26 11:05:58 2008 From: drew at alliancenavy.org (Drew Dwi) Date: Thu Jun 26 11:05:58 2008 Subject: [sldev] [VWR] 1.20.11 linux compile error Message-ID: <4863DA86.4050201@alliancenavy.org> This is my first attempt to build the client from scratch, amd64 ubuntu 8.04. I searched the list for a similar error but didn't find anything. libuuid.so.1 seems to be missing. I can copy it from the 1.20.11 pre-built binary package, but wanted to see if this was my error somehow or if the source is missing this file? /usr/bin/ld: warning: libuuid.so.1, needed by ../linden/libraries/i686-linux/lib_release_client/libaprutil-1.so, not found (try using -rpath or -rpath-link) ../linden/libraries/i686-linux/lib_release_client/libapr-1.so: undefined reference to `uuid_generate' collect2: ld returned 1 exit status scons: *** [linux_crash_logger/linux-crash-logger-i686-bin-globalsyms] Error 1 scons: building terminated because of errors. Thanks for time, ~Drew From suzhanna.rossini at balsaestates.com Thu Jun 26 11:46:40 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Thu Jun 26 11:47:04 2008 Subject: [sldev] Building boost on VS2008 Message-ID: <009e01c8d7bc$f9d13500$ed739f00$@rossini@balsaestates.com> I'm doing an attempt to rebuild the libraries on VC2008, but ran into some weirdness right away. I must say, this is experimenting from a novice! I'm trying to learn here.. ;-) Anyway, I'm trying to build boost from the advice in the SL wiki, but somehow the libraries comes up with names like 'boost_regex-vc90-mt-1_35.dll' and *not* 'libboost_regex-vc90-mt-1_35.dll' as I was expecting them to. Where did the initial 'lib' go? Did I miss something in the build, or should I just rename them when copying them to the SL client source tree? From carjay at gmx.net Thu Jun 26 13:04:17 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Jun 26 13:04:28 2008 Subject: [sldev] [VWR] 1.20.11 linux compile error In-Reply-To: <4863DA86.4050201@alliancenavy.org> References: <4863DA86.4050201@alliancenavy.org> Message-ID: <4863F641.6010308@gmx.net> Drew Dwi wrote: > This is my first attempt to build the client from scratch, amd64 > ubuntu 8.04. I searched the list for a similar error but didn't find > anything. libuuid.so.1 seems to be missing. I can copy it from the > 1.20.11 pre-built binary package, but wanted to see if this was my > error somehow or if the source is missing this file? > > /usr/bin/ld: warning: libuuid.so.1, needed by > ../linden/libraries/i686-linux/lib_release_client/libaprutil-1.so, not > found (try using -rpath or -rpath-link) > ../linden/libraries/i686-linux/lib_release_client/libapr-1.so: > undefined reference to `uuid_generate' > collect2: ld returned 1 exit status > scons: *** [linux_crash_logger/linux-crash-logger-i686-bin-globalsyms] > Error 1 > scons: building terminated because of errors. Hm, are you building for 32 bit? The Linden pre-built libraries are 32 bit only but you seem to have used at least the libaprutil-1.so somehow? The two libraries in the log are libaprutil1 (Apache Portable Runtime Utility Library) and uuid (universally unique id library). Their packages are called "libaprutil1-dev" and "uuid-dev" on Ubuntu, they are not originally from LL. Regards, Carsten From lenglish5 at cox.net Fri Jun 27 12:42:25 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jun 27 12:55:16 2008 Subject: [sldev] [AWG] Inter-grid permissions issues at Zero's office hours on Tuesday, 1PM Message-ID: <486542A1.4050804@cox.net> Xen Linden will be guest-hosting Zero Linden's office hours on Tuesday, 1 July, at 1PM. The topic will be issues pertaining to intergrid permissions. http://slurl.com/secondlife/Grasmere/164/110/27 I've started a SL forum thread here: http://forums.secondlife.com/showthread.php?t=267473 Please vote if you plan on attending the meeting since I expect that more than 40 avatars will show up so they need to know ahead of time if the meeting place needs to be changed. Lawson From edward.artaud at gmail.com Fri Jun 27 15:32:09 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Fri Jun 27 15:32:14 2008 Subject: [sldev] Suggestion for viewer plug-ins Message-ID: I've documented my thinking about the requirements for a viewer plug-in model in a Jira entry: http://jira.secondlife.com/browse/VWR-7970 There are some discussions of plug-ins in the wiki ( http://wiki.secondlife.com/wiki/Plugin_architecture), however, I don't think they fully convey the importance of this capability for the evolution of the platform or mention the requirement for plug-ins to actually participate in the rendering pipeline. I'm increasingly becoming convinced that in order for SL to be a viable platform for professional content, that such a plug-in model will be required if for no other reason than for third-parties to be implement the content protection and access to secure assets they need outside of the open-source codebase. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080627/21ce73c0/attachment.htm From lenglish5 at cox.net Fri Jun 27 22:40:16 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jun 27 22:40:18 2008 Subject: [sldev] Suggestion for viewer plug-ins In-Reply-To: References: Message-ID: <4865CEC0.5070000@cox.net> Edward Artaud wrote: > I've documented my thinking about the requirements for a viewer > plug-in model in a Jira entry: > > http://jira.secondlife.com/browse/VWR-7970 > > There are some discussions of plug-ins in the wiki > (http://wiki.secondlife.com/wiki/Plugin_architecture), however, I > don't think they fully convey the importance of this capability for > the evolution of the platform or mention the requirement for plug-ins > to actually participate in the rendering pipeline. I'm increasingly > becoming convinced that in order for SL to be a viable platform for > professional content, that such a plug-in model will be required if > for no other reason than for third-parties to be implement the content > protection and access to secure assets they need outside of the > open-source codebase. My own belief is that a plug-in architecture won't make sense until the OGP is much, MUCH further along. The current protocols and set of libraries is just too convoluted and organic to allow a viable plugin system to be designed. By the time ti could go "live" in any meaningful way, the underlying architecture will have changed too drastically for any plug-in that was designed for the current system to still be usable. If you want to experiment with plugin designs for SL, join the pyogp crew and steer SL's viewer-server protocols in a direction that makes a robust plug-in architecture viable in the long-run. http://wiki.secondlife.com/wiki/Pyogp Lawson From edward.artaud at gmail.com Fri Jun 27 23:50:23 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Fri Jun 27 23:50:26 2008 Subject: [sldev] Suggestion for viewer plug-ins In-Reply-To: <4865CEC0.5070000@cox.net> References: <4865CEC0.5070000@cox.net> Message-ID: I certainly will get involved with that effort, but if the evolution of the viewer is at all similar to that of the browser, I strongly suspect that trying to design the OGP in advance of the plug-in model is going to result in a much over-engineered OGP. I think one similar analogy would be the way the W3 API bindings for the XML DOM evolved out of the DOM API's that were originally exposed for the use of plug-ins and scripting - plug-ins were introducted by Netscape in 2.0b1 in 1995 but the DOM API didn't get to the W3 until almost two yearslater. One could have made the argument that browsers should not have implemented a plug-in model that allowed the Acrobat plugin to be developed until the W3 developed CSS or allowed Flash to be developed until the W3 finished the SVG spec (i.e. completely different approaches to solve virtually the same problems that wouldn't have occured through a centrally planned roadmap, but which would have arguably hampered the growth of the web if a governing body like the W3 took the approach of dictating rather than recommending browser architecture). Further, many viewer plug-ins will make only minimal use of the OGP, much the same way that many browser plug-ins only really use the browser's display API's. I really do stand by the idea that if we're trying to embrace the idea of emulating the openness of the web, we can't pick and choose which parts of that open ecosystem we like, but must try to open as many extension points as possible and let the market drive direction through people trying a lot of experiments, with standards efforts following and formalizing rather than trying to predict the future. On Fri, Jun 27, 2008 at 10:40 PM, Lawson English wrote: > Edward Artaud wrote: > >> I've documented my thinking about the requirements for a viewer plug-in >> model in a Jira entry: >> >> http://jira.secondlife.com/browse/VWR-7970 >> >> There are some discussions of plug-ins in the wiki ( >> http://wiki.secondlife.com/wiki/Plugin_architecture), however, I don't >> think they fully convey the importance of this capability for the evolution >> of the platform or mention the requirement for plug-ins to actually >> participate in the rendering pipeline. I'm increasingly becoming convinced >> that in order for SL to be a viable platform for professional content, that >> such a plug-in model will be required if for no other reason than for >> third-parties to be implement the content protection and access to secure >> assets they need outside of the open-source codebase. >> > > My own belief is that a plug-in architecture won't make sense until the OGP > is much, MUCH further along. The current protocols and set of libraries is > just too convoluted and organic to allow a viable plugin system to be > designed. By the time ti could go "live" in any meaningful way, the > underlying architecture will have changed too drastically for any plug-in > that was designed for the current system to still be usable. > > If you want to experiment with plugin designs for SL, join the pyogp crew > and steer SL's viewer-server protocols in a direction that makes a robust > plug-in architecture viable in the long-run. > > > http://wiki.secondlife.com/wiki/Pyogp > > Lawson > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080627/5521cab1/attachment.htm From dmahalko at gmail.com Sat Jun 28 06:31:55 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 28 06:31:57 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: Message-ID: Thread update. :-) On Tue, Jun 24, 2008 at 9:40 PM, Dale Mahalko wrote: > On the wiki page for VS2003... > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 > > It says: > == Building == > "Go into the indra folder, and run the develop.py script." > > There is no develop.py for 1.19.1.4 as far as I can determine. A > search of the entire source tree turns up nothing. There is no develop.py for the 1.20.11.RC that is hot off the presses, as far as I can determine. A search of the entire source tree turns up nothing for a file named "develop". So, I assume that particular compiling instruction can be deleted as obsolete? - Scalar Tardis / Dale Mahalko From soft at lindenlab.com Sat Jun 28 07:09:49 2008 From: soft at lindenlab.com (Soft) Date: Sat Jun 28 07:09:51 2008 Subject: [sldev] Compiling/VS2003: Where is develop.py ? In-Reply-To: References: Message-ID: On Sat, Jun 28, 2008 at 8:31 AM, Dale Mahalko wrote: > On Tue, Jun 24, 2008 at 9:40 PM, Dale Mahalko wrote: >> On the wiki page for VS2003... >> http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 >> >> It says: >> == Building == >> "Go into the indra folder, and run the develop.py script." >> >> There is no develop.py for 1.19.1.4 as far as I can determine. A >> search of the entire source tree turns up nothing. > > > There is no develop.py for the 1.20.11.RC that is hot off the presses, > as far as I can determine. A search of the entire source tree turns up > nothing for a file named "develop". > > So, I assume that particular compiling instruction can be deleted as obsolete? develop.py is new. It will be used in 1.21 on forward. It is presently in release/ -- our badly-named version of a head branch. 1.20 is still old-school build. From lenglish5 at cox.net Sat Jun 28 11:05:30 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 28 11:05:35 2008 Subject: [sldev] Suggestion for viewer plug-ins In-Reply-To: References: <4865CEC0.5070000@cox.net> Message-ID: <48667D6A.7040804@cox.net> Edward Artaud wrote: > I certainly will get involved with that effort, but if the evolution > of the viewer is at all similar to that of the browser, I strongly > suspect that trying to design the OGP in advance of the plug-in model > is going to result in a much over-engineered OGP. I think one similar > analogy would be the way the W3 API bindings for the XML DOM evolved > out of the DOM API's that were originally exposed for the use of > plug-ins and scripting - plug-ins were introducted by Netscape in > 2.0b1 in 1995 but the DOM API didn't get to the W3 until almost two > yearslater. One could have made the argument that browsers should not > have implemented a plug-in model that allowed the Acrobat plugin to be > developed until the W3 developed CSS or allowed Flash to be developed > until the W3 finished the SVG spec (i.e. completely different > approaches to solve virtually the same problems that wouldn't have > occured through a centrally planned roadmap, but which would have > arguably hampered the growth of the web if a governing body like the > W3 took the approach of dictating rather than recommending browser > architecture). Further, many viewer plug-ins will make only minimal > use of the OGP, much the same way that many browser plug-ins only > really use the browser's display API's. I really do stand by the idea > that if we're trying to embrace the idea of emulating the openness of > the web, we can't pick and choose which parts of that open ecosystem > we like, but must try to open as many extension points as possible and > let the market drive direction through people trying a lot of > experiments, with standards efforts following and formalizing rather > than trying to predict the future. > I think once thing I left out of my comments is that until the GUI is refactored, a plug-in architecture won't make much sense for many kinds of plug-ins because the human interface to such things will be almost impossible. The way things are going, this won't get done until AFTER the OGP is much further along. > > On Fri, Jun 27, 2008 at 10:40 PM, Lawson English > wrote: > > Edward Artaud wrote: > > I've documented my thinking about the requirements for a > viewer plug-in model in a Jira entry: > > http://jira.secondlife.com/browse/VWR-7970 > > There are some discussions of plug-ins in the wiki > (http://wiki.secondlife.com/wiki/Plugin_architecture), > however, I don't think they fully convey the importance of > this capability for the evolution of the platform or mention > the requirement for plug-ins to actually participate in the > rendering pipeline. I'm increasingly becoming convinced that > in order for SL to be a viable platform for professional > content, that such a plug-in model will be required if for no > other reason than for third-parties to be implement the > content protection and access to secure assets they need > outside of the open-source codebase. > > > My own belief is that a plug-in architecture won't make sense > until the OGP is much, MUCH further along. The current protocols > and set of libraries is just too convoluted and organic to allow a > viable plugin system to be designed. By the time ti could go > "live" in any meaningful way, the underlying architecture will > have changed too drastically for any plug-in that was designed for > the current system to still be usable. > > If you want to experiment with plugin designs for SL, join the > pyogp crew and steer SL's viewer-server protocols in a direction > that makes a robust plug-in architecture viable in the long-run. > > > http://wiki.secondlife.com/wiki/Pyogp > > Lawson > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From edward.artaud at gmail.com Sat Jun 28 11:35:35 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sat Jun 28 11:35:39 2008 Subject: [sldev] Suggestion for viewer plug-ins In-Reply-To: <48667D6A.7040804@cox.net> References: <4865CEC0.5070000@cox.net> <48667D6A.7040804@cox.net> Message-ID: Unfortunately, I do have to agree with that point. The viewer urgently needs to be refactored to be modular, my hope was that a strong push towards a plug-in architecture would go hand in hand with that. However, even though it's not ideal, it still should be possible to bolt a plug-in API on to top of the current viewer architecture. I think this would drive the rest of the codebase toward modularity as, over time, more new functionality was added via the plug-in API rather than in the core code. On Sat, Jun 28, 2008 at 11:05 AM, Lawson English wrote: > I think once thing I left out of my comments is that until the GUI is > refactored, a plug-in architecture won't make much sense for many kinds of > plug-ins because the human interface to such things will be almost > impossible. The way things are going, this won't get done until AFTER the > OGP is much further along. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080628/c9e42bef/attachment.htm From lenglish5 at cox.net Sat Jun 28 12:38:25 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 28 12:38:27 2008 Subject: [sldev] Suggestion for viewer plug-ins In-Reply-To: References: <4865CEC0.5070000@cox.net> <48667D6A.7040804@cox.net> Message-ID: <48669331.80703@cox.net> Edward Artaud wrote: > Unfortunately, I do have to agree with that point. The viewer > urgently needs to be refactored to be modular, my hope was that a > strong push towards a plug-in architecture would go hand in hand with > that. However, even though it's not ideal, it still should be > possible to bolt a plug-in API on to top of the current viewer > architecture. I think this would drive the rest of the codebase > toward modularity as, over time, more new functionality was added via > the plug-in API rather than in the core code. > I think a big issue is: what is "core code?" As part of the design of the pyogp, we're having to figure out just what code goes into what module. The nice thing about using ZCA (Zope Cmponent Architecture) is that it gives us a plug-in architecture "for free." In fact, I'd say that ALL of pyogp will likely be nothing but plug-ins before we are done and that each major module will have its own sub-modules, which will also be plug-ins. This isn't quite what you had in mind, but the structure we come up with may help guide designing the plug-in architecture for the C++ GPL client (pyogp is Apache v2 licensed). > On Sat, Jun 28, 2008 at 11:05 AM, Lawson English > wrote: > > I think once thing I left out of my comments is that until the GUI > is refactored, a plug-in architecture won't make much sense for > many kinds of plug-ins because the human interface to such things > will be almost impossible. The way things are going, this won't > get done until AFTER the OGP is much further along. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From terry at usfastweb.com Sun Jun 29 13:22:17 2008 From: terry at usfastweb.com (Terry F.) Date: Sun Jun 29 13:22:18 2008 Subject: [sldev] Can anyone help? Message-ID: <4867EEF9.9010400@usfastweb.com> I'm having some trouble compiling 1.20.11RC can anyone help? I am a "Noob" compiling the viewer and I keep getting errors. I'm using VS2005 Express. Nicholaz has helped me in the past by sending me a "PRE" converted, Ready to compile folder and I have been able to build this fine, so this leads me to believe my setup and program settings are correct. I'm just not sure where I'm going wrong trying to convert and prepare the downloaded material on my own. I'm sure it's something I'm overlooking, but I can't figure it out. I've spent countless hours trying to resolve my problems but cannot successfully download, convert/prepare, and build the viewer. I open the "indra_complete.sln" file. I've set "newview" as my default project and "unloaded" the test, win_crash_logger and win_updater projects. I choose "Release" then click build, and it eventually errors. Any help would be greatly appreciated! I'm getting this error(There are others, but I'm trying to solve each in order): llsys.cpp(144) : error C2665: 'utf16str_to_utf8str' : none of the 2 overloads could convert all the argument types i:\linden\indra\llcommon\llstring.h(430): could be 'std::string utf16str_to_utf8str(const llutf16string &)' while trying to match the argument list '(WCHAR [128])' Thank-you, -Terry From dmahalko at gmail.com Sun Jun 29 14:18:08 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Jun 29 14:18:10 2008 Subject: [sldev] Source/VS2003 1.20.11 RC, all four builds won't compile Message-ID: Nothing will build for this using the "standard" external libraries from 1.19.1.4, and the three source, lib, and artwork zipfiles. Here are all four build log files: A slight bit of trouble building ReleaseNoOpt.. VS2003 does not like listing 28,666 linking errors all in one log window. Makes it very slow.. ------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ [. . . .] Linking... llagent.obj : error LNK2001: unresolved external symbol "public: virtual class LLEventDispatcher * __thiscall LLObservable::getDispatcher(void)" (?getDispatcher@LLObservable@@UAEPAVLLEventDispatcher@@XZ) llfloateractivespeakers.obj : error LNK2001: unresolved external symbol "public: virtual class LLEventDispatcher * __thiscall LLObservable::getDispatcher(void)" (?getDispatcher@LLObservable@@UAEPAVLLEventDispatcher@@XZ) [. . . .] pipeline.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRenderTarget::getViewport(int *)" (?getViewport@LLRenderTarget@@QAEXPAH@Z) referenced in function "public: void __thiscall LLPipeline::generateWaterReflection(class LLCamera &)" (?generateWaterReflection@LLPipeline@@QAEXAAVLLCamera@@@Z) pipeline.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRender::color4ub(unsigned char const &,unsigned char const &,unsigned char const &,unsigned char const &)" (?color4ub@LLRender@@QAEXABE000@Z) referenced in function "public: void __thiscall LLPipeline::generateImpostor(class LLVOAvatar *)" (?generateImpostor@LLPipeline@@QAEXPAVLLVOAvatar@@@Z) ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 3330 unresolved externals Build log was saved at "file://c:\SL_Viewer_Builds\1_20_11_RC\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" newview - 28666 error(s), 0 warning(s) --------------------------------------------------------------------------------- ------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ Executing pre-build batch file master: http://secondlife.com/app/message_template/master_message_template.msg current: c:\SL_Viewer_Builds\1_20_11_RC\linden\scripts\messages\message_template.msg Refreshing master cache from http://secondlife.com/app/message_template/master_message_template.msg --- PASS --- Same PREBUILD SUCCESSFUL Linking... LINK : fatal error LNK1181: cannot open input file 'llaudio.lib' Build log was saved at "file://c:\SL_Viewer_Builds\1_20_11_RC\linden\indra\newview\ReleaseForDownload\BuildLog.htm" newview - 1 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped ------------------------------------------------------------------------------- ------ Build started: Project: newview, Configuration: Release Win32 ------ Executing pre-build batch file master: http://secondlife.com/app/message_template/master_message_template.msg current: c:\SL_Viewer_Builds\1_20_11_RC\linden\scripts\messages\message_template.msg --- PASS --- Same PREBUILD SUCCESSFUL Linking... LINK : fatal error LNK1181: cannot open input file 'llaudio.lib' Build log was saved at "file://c:\SL_Viewer_Builds\1_20_11_RC\linden\indra\newview\Release\BuildLog.htm" newview - 1 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped ------------------------------------------------------------------------------- ------ Build started: Project: newview, Configuration: Debug Win32 ------ Executing pre-build batch file master: http://secondlife.com/app/message_template/master_message_template.msg current: c:\SL_Viewer_Builds\1_20_11_RC\linden\scripts\messages\message_template.msg --- PASS --- Same PREBUILD SUCCESSFUL Linking... LINK : fatal error LNK1104: cannot open file 'EZ_LCD_Wrapper_d.lib' Build log was saved at "file://c:\SL_Viewer_Builds\1_20_11_RC\linden\indra\newview\Debug\BuildLog.htm" newview - 1 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped From soft at lindenlab.com Sun Jun 29 15:32:38 2008 From: soft at lindenlab.com (Soft) Date: Sun Jun 29 15:32:40 2008 Subject: [sldev] Source/VS2003 1.20.11 RC, all four builds won't compile In-Reply-To: References: Message-ID: I'm confused. Are you aiming to use the library bundle from a 1.19 viewer and source from 1.20? We don't support mixing versions. You should get the library bundle matching your source. Otherwise, maybe you could explain what you mean by the quoted "standard." On Sun, Jun 29, 2008 at 4:18 PM, Dale Mahalko wrote: > Nothing will build for this using the "standard" external libraries > from 1.19.1.4, and the three source, lib, and artwork zipfiles. Here > are all four build log files: From dmahalko at gmail.com Sun Jun 29 18:17:44 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Jun 29 18:17:46 2008 Subject: [sldev] Source/VS2003 1.20.11 RC, all four builds won't compile In-Reply-To: References: Message-ID: Reference: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 Other Libraries (.......) It is a good idea to build an empty directory tree for the files below, then copy these library files there. Once completed, copy the whole tree to the actual source folder (like XCOPY olibs sl_1_16_0_5 /S). You will then only need to repeat the last step for each new release, reusing the tree you have already created. On Sun, Jun 29, 2008 at 5:32 PM, Soft wrote: > I'm confused. > > Are you aiming to use the library bundle from a 1.19 viewer and source > from 1.20? We don't support mixing versions. You should get the > library bundle matching your source. Otherwise, maybe you could > explain what you mean by the quoted "standard." > > On Sun, Jun 29, 2008 at 4:18 PM, Dale Mahalko wrote: >> Nothing will build for this using the "standard" external libraries >> from 1.19.1.4, and the three source, lib, and artwork zipfiles. Here >> are all four build log files: > From dmahalko at gmail.com Sun Jun 29 18:38:14 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Jun 29 18:38:18 2008 Subject: [sldev] Source/VS2003 1.20.11 RC, all four builds won't compile In-Reply-To: References: Message-ID: Actually I'm now walking backwards through the RC's trying to build them all. I don't really care which build is successful, just so long as I can find one RC that is past the preferences move to XML. For the caching rework project I am muddling along with, I'm going to have to splice in some new client preferences for the decode-cache and non-VFS settings, and I'd prefer to be designing that code for the new XML preferences method rather than the old way in 1.19.1.4. Wiki: SLDEV Discussion - Texture Cache Plan of Attack Implementation Experiments: Separate cache size controls http://tinyurl.com/4yeyeq - Scalar Tardis / Dale Mahalko On Sun, Jun 29, 2008 at 8:17 PM, Dale Mahalko wrote: > Reference: > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 > > Other Libraries > (.......) > It is a good idea to build an empty directory tree for the files > below, then copy these library files there. Once completed, copy the > whole tree to the actual source folder (like XCOPY olibs sl_1_16_0_5 > /S). You will then only need to repeat the last step for each new > release, reusing the tree you have already created. From danteferret at gmail.com Sun Jun 29 19:13:26 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sun Jun 29 19:13:28 2008 Subject: [sldev] Source/VS2003 1.20.11 RC, all four builds won't compile In-Reply-To: References: Message-ID: <4d211a610806291913y236e1b1bl6844dd2cba008e3@mail.gmail.com> Hmm, don't expect much luck, as all those should be buildable. If you failed on one expect to fail on the others. Maybe instead you should try to work out what your problem is. On Sun, Jun 29, 2008 at 9:38 PM, Dale Mahalko wrote: > Actually I'm now walking backwards through the RC's trying to build > them all. I don't really care which build is successful, just so long > as I can find one RC that is past the preferences move to XML. > > For the caching rework project I am muddling along with, I'm going to > have to splice in some new client preferences for the decode-cache and > non-VFS settings, and I'd prefer to be designing that code for the new > XML preferences method rather than the old way in 1.19.1.4. > > Wiki: SLDEV Discussion - Texture Cache Plan of Attack > Implementation Experiments: Separate cache size controls > http://tinyurl.com/4yeyeq > > > - Scalar Tardis / Dale Mahalko > > > On Sun, Jun 29, 2008 at 8:17 PM, Dale Mahalko wrote: > > Reference: > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 > > > > Other Libraries > > (.......) > > It is a good idea to build an empty directory tree for the files > > below, then copy these library files there. Once completed, copy the > > whole tree to the actual source folder (like XCOPY olibs sl_1_16_0_5 > > /S). You will then only need to repeat the last step for each new > > release, reusing the tree you have already created. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080629/1be3502f/attachment.htm From suzhanna.rossini at balsaestates.com Mon Jun 30 12:54:58 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Mon Jun 30 12:55:07 2008 Subject: [sldev] Building with VS2008? Message-ID: <48693A12.5020103@balsaestates.com> I'm struggling to build the client with VS2008, but I'm running into a whole lot of obstacles. Is there anybody out there that can give pointers and advice? I'm rather new to the Windows way of doing things, and VS2008 is the only environment I have available. Thank you! From soft at lindenlab.com Mon Jun 30 13:30:13 2008 From: soft at lindenlab.com (Soft) Date: Mon Jun 30 13:30:18 2008 Subject: [sldev] Building with VS2008? In-Reply-To: <48693A12.5020103@balsaestates.com> References: <48693A12.5020103@balsaestates.com> Message-ID: You will run into many problems with Visual Studio 2008 and the current release candidate viewer (1.20). Visual Studio 2003 is the only officially supported Windows compiler there. Things will be much easier if you pull the release branch and use cmake, which can generate Visual Studio 2008 project files. On Mon, Jun 30, 2008 at 2:54 PM, Suzhanna Rossini wrote: > I'm struggling to build the client with VS2008, but I'm running into a whole > lot of obstacles. > Is there anybody out there that can give pointers and advice? I'm rather new > to the Windows way of doing things, and VS2008 is the only environment I > have available. > > Thank you! > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From lenglish5 at cox.net Mon Jun 30 18:57:13 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 30 18:57:15 2008 Subject: [sldev] [AWG] Inter-grid permissions issues at Zero's office hours on Tuesday, 1PM In-Reply-To: <486542A1.4050804@cox.net> References: <486542A1.4050804@cox.net> Message-ID: <48698EF9.6080001@cox.net> Lawson English wrote: > Xen Linden will be guest-hosting Zero Linden's office hours on > Tuesday, 1 July, at 1PM. The topic will be issues pertaining to > intergrid permissions. > > http://slurl.com/secondlife/Grasmere/164/110/27 > 37 have rsvp-ed. Zero's office won't hold everyone, I'm certain. I suggest the Pooley Auditorium at the corner of Pooley, Seascale, Brampton, and Borrowdale. 1PM SL time. I'll leave a sign at Zero's office for stragglers and for Xan Linden since I can't get ahold of him to warn him (he'll be so pleased). L. From alissa_sabre at yahoo.co.jp Mon Jun 30 20:11:44 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Jun 30 20:11:47 2008 Subject: [sldev] while trying to match the argument list '(WCHAR [128])' (was: Can anyone help?) Message-ID: <20080701031144.34276.qmail@web3105.mail.kcd.yahoo.co.jp> Terry, > I'm having some trouble compiling 1.20.11RC can anyone help? I have never tried recent 1.20 RC sources, so I may be wrong. > llsys.cpp(144) : error C2665: 'utf16str_to_utf8str' : none of the 2 > overloads could convert all the argument types > i:\linden\indra\llcommon\llstring.h(430): could be 'std::string > utf16str_to_utf8str(const llutf16string &)' > while trying to match the argument list '(WCHAR [128])' This error seems to me that you failed to made wchat_t a typedef. Try turning off "Treat wchat_t as Build-in Type" option on the Configuration Properties > C/C++ > Language panel of all the project files (not just newview.) > I open the "indra_complete.sln" file. Did it opened as it is? Or, Visual Studio complained on the older version of the solution file and converted? (I really don't know what project files are included in recent source distribution...) If you got complained, you'd better consult the following page: http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 which, for whatever reason, is not referenced from any of the wiki pages, hmm... Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/