From hud at zurich.ibm.com Mon Oct 1 00:13:15 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 1 00:13:20 2007 Subject: [sldev] [Upcoming Changes] Website Viewer Authentication In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> Message-ID: <47009E0B.5010205@zurich.ibm.com> Donovan Linden wrote: > This remains an open issue. With the first iteration, you will just > launch the desired client and log in from the splash page. > > It seems like a possible design for a future iteration might be to > switch the secondlife: protocol handler registration to a small helper > application that lists installed clients and launches the chosen one, > passing the web login key. that's what i think should be in the first interation. how hard can it be to code that?. cheers, dirk > > Donovan > > On Sep 28, 2007, at 2:50 PM, Harold Brown wrote: > >> This does seem to pose another issue.... What if I want to use >> multiple clients? You wouldn't be able to pick which client to use, >> Standard, RC, First Look, Nicholaz, SLeek.. etc. >> >> On 9/28/07, *Candide LeMay* > > wrote: >> >> from the wiki: >> >> '"I have separate accounts that I use. How does this affect me?" >> >> Yes. If you wish to use a separate Second Life account, you must log >> out of your current account on the website and then log in with your >> separate account.' >> >> that's very cumbersome! I have several accounts (work, testing >> etc) I >> use daily and often at the same time (running several SL instances at >> once). I don't want to be logging in and out all the time on a >> website. On top of that, I start SL with a script, to feed it command >> line switches (for allowing multiple instances), start with lower >> priority, various stuff. I don't want the only way to start SL to be >> via secondlife:// >> >> candide >> _______________________________________________ >> 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 > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/30c5d849/attachment.htm From seg at haxxed.com Mon Oct 1 00:23:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 1 00:23:40 2007 Subject: [sldev] [Upcoming Changes] Website Viewer Authentication In-Reply-To: <47009E0B.5010205@zurich.ibm.com> References: <46FD72A7.7040603@lindenlab.com> <47009E0B.5010205@zurich.ibm.com> Message-ID: <1191223402.11151.2.camel@localhost> On Mon, 2007-10-01 at 09:13 +0200, dirk husemann wrote: > Donovan Linden wrote: > > It seems like a possible design for a future iteration might be to > > switch the secondlife: protocol handler registration to a small > > helper application that lists installed clients and launches the > > chosen one, passing the web login key. > that's what i think should be in the first interation. how > hard can it be to code that?. Or instead of using a protocol handler, use a mime type handler. On most OSs and browsers there's already a well developed system for choosing among multiple applications to "open with..." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071001/a5379ee2/attachment.pgp From hud at zurich.ibm.com Mon Oct 1 00:39:40 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 1 00:39:47 2007 Subject: [sldev] [META] Formal critique of new auth mechanism? In-Reply-To: <200709292050.22883.dale@daleglass.net> References: <46FD72A7.7040603@lindenlab.com> <200709291705.55676.dale@daleglass.net> <46FE8F10.6010608@lindenlab.com> <200709292050.22883.dale@daleglass.net> Message-ID: <4700A43C.6000106@zurich.ibm.com> Dale Glass wrote: > On Saturday 29 September 2007 19:44:48 Rob Lanphier wrote: > >> The goal is to have something >> that multiple people feel good attaching their name to; it doesn't have >> to be the unanimous consensus of the list, but the more names of people >> who we recognize as thoughtful contributors, the more weight it will >> carry. If this can be completed in a timely manner, I'll work with the >> team on a detailed response >> > On that, should we attach a list of names to the page? > > Something like a list of who endorses a particular criticism? > how about just adding your wiki signature to a paragraph (signing off on it) ---- just add ~~~~ -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/80572026/attachment-0001.htm From lnxhkr at gmail.com Mon Oct 1 00:53:16 2007 From: lnxhkr at gmail.com (=?ISO-8859-1?Q?J=FCrgen_Lehmann?=) Date: Mon Oct 1 00:53:21 2007 Subject: [sldev] [PATCH] Export Prims (complete) Message-ID: Here is the second version of my export prims patch now completed. I attached a simple output example although it does not show an example of supported things like linksets, lights, flexi-prims, and sculpties. As you can see the export code is very simple as it relies on the LLSD system in the viewer, maybe it can be the first step toward a prim storage format? Next step is the importer although it will be more complicated code. -------------- next part -------------- A non-text attachment was scrubbed... Name: primexport-20071001.patch Type: application/octet-stream Size: 11531 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071001/c47e69a7/primexport-20071001-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: plywoodcube.xml Type: text/xml Size: 8497 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071001/c47e69a7/plywoodcube-0001.bin From matthew.dowd at hotmail.co.uk Mon Oct 1 02:00:01 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Oct 1 02:00:03 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4700034C.5080805@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFB774.3080001@dzonux.net> <4700034C.5080805@gmail.com> Message-ID: You probably need to differentiate what the user sees, and what happens behind the scenes. I would hope what would happen is something like this: Logging on when certificate is still valid What the user sees: The client starts and either prompts them for their OpenID and password or autologs on depending on their setup and they are in... What happens behind the scenes: the client opens the certificate store, determines the certificate is valid and uses that to authenticate Logging on when certificate is expired What the user sees: The client starts and either prompts them for their OpenID and password or autologs on depending on their setup and they are in... What happens behind the scenes: the client opens the certificate store, determines the certificate has expired, contacts the IDP to renew and uses the renewed certificate to authenticate Matthew > Date: Sun, 30 Sep 2007 16:13:00 -0400> From: gigstaggart@gmail.com> To: dzonatas@dzonux.net> Subject: Re: [sldev] OpenID & SSL certificates> CC: sldev@lists.secondlife.com> > Dzonatas wrote:> > One of the users certificate may expire. In this case, the user logs > > into the OpenID system again to lease/create a new certificate. The > > system re-propagates as needed.> > > There is no way in hell users will accept something this complex. On > that Jira issue I posted before, I have users arguing they should have > the right to set their password to their login name or to "password" or > "god".> > Get some perspective here. Users aren't going to deal with certificate > management.> > -Jason> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/c24f6b99/attachment.htm From ryan at ngigroup.com Mon Oct 1 02:19:38 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 02:19:40 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> Message-ID: <1191230378.3023.29.camel@localhost.localdomain> Excuse my ignorance, but I was pretty sure secure token exchange was a solved problem: when you register your account, you create a Public/Private key set, and give the public key to linden. When you log in you do the exchange and receive a private, temporary authorization token. While this might have usability issues, its certainly solvable, even if you just hand out a small "LL Acme PKI Keygen Magic-Tool" (based on GPG). Of course this brings us back to the original use case, an adulterated client viewer source (where once you access, the game is up no matter what). So then the solution must be to not trust the viewer. Either: 1. Make a hard dependency on a system-installed key exchange system. This would reduce the security problem to one of breaking the OS's security, and thus we would wash our hands of it, not solve it. On Linux this would be easy, but I don't know what MS or Apple provides for their systems. 2. Put the security burden on distributors by creating a protocol that identifies the source of the viewer binary, so at the least you always know where your adulterated viewer came from. Say that unless the viewer distributor places a digital signature on a LL server along with the name of the downloader's name, LL will pop up a warning that the viewer is not known to LL and may be adulterated. Once again, apologies if I have totally missed the point. I look forward to be corrected. :) Cheers, Ryan From hud at zurich.ibm.com Mon Oct 1 02:21:53 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 1 02:22:35 2007 Subject: [sldev] Re: [META] Formal critique of new auth mechanism? In-Reply-To: <46FED9D2.4000603@blueflash.cc> References: <46FD72A7.7040603@lindenlab.com> <200709292024.58893.dale@daleglass.net> <200709292155.17606.dale@daleglass.net> <46FEB44A.8090708@lindenlab.com> <46FED9D2.4000603@blueflash.cc> Message-ID: <4700BC31.60807@zurich.ibm.com> Nicholaz Beresford wrote: > > Rob Lanphier wrote: > > We generally respond a lot better when light is shed on a problem > rather > > than heat. While I think the conversation so far has been very civil, > > it's only now getting organized, so that's what I'm focusing on. > > > > That's not to say that we won't respond to the issues that smaller > > groups have, but I want to make sure we're apply our energy in the > right > > proportions. > > I think (and would be surprised otherwise) there currently consensus > among > those who replied here on the list that ... > > 1) the new auth mechanism does nothing to significantly increase security > in terms of protecting user assets from malicious viewers (once the > viewer is logged in, you're at the mercy of the viewer, no matter how > you logged in) > > 2) the new auth mechanism makes login to SL cumbersome and breaks many > ways in which people are currently using SL (alts, switching between > viewers, etc.) > > 3) the new auth mechanism will make it impossible for some environments > to log in from at all (proxies, firewalls, security software, ...) > or prevent specific forms of viewers (lean viewers, mobile systems, > viewer on a memory stick, ...) > > 4) the new auth mechanism will break existing applications (bots, libsl, > etc.) and these will have to work around these. > > 5) Allowing these (4) to work around it, means that 3rd party viewers can > also work around it, meaning that you'll end up with 3rd party viewers > which are a lot more convenient than the official viewer, essentially > driving people away from the official viewer. > > 6) other mechanisms exist, which a) actually increase security and which > b) do not break existing use and c) are less cumbersome > > 7) (this is my personal addition but I'd be amazed if anyone disagreed) > people are losing a lot more assets and value through Linden > malfunctions (lost inventory, search & classifieds being not seen > because of outages, etc.) than have ever been lost through spoofing > or malicious viewers. > > 8) __whatever mechanism is implemented, should be a *choice* with the__ > __existing mechanisms remaining in place__ > > 9) (see (8) ) > > 10) (see (9) ) > > > Bottom line is that the new auth mechanism is something that offers > neglectible > improvement in security and will cause countless problems or developer > hours > on both sides. agree with that, too. nick, could you add that to the wiki? cheers, dirk > > > Nick > > > (Matt, feel free to copy that to the Wiki) > > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From jhurliman at wsu.edu Mon Oct 1 02:56:02 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Oct 1 02:55:58 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191230378.3023.29.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> Message-ID: <4700C432.4060202@wsu.edu> Ryan McDougall wrote: > Say that unless the viewer distributor places a digital signature on a > LL server along with the name of the downloader's name, LL will pop up a > warning that the viewer is not known to LL and may be adulterated. As long as the adulterated viewer behaves and displays this warning to the user, right? ... A users computer is acting as a proxy for the human to interact with other systems, and to do this there is an implicit trust that the users computer is accurately representing the user. In the current model of personal computers and the Internet this is a fundamental law, and no clever warning message or DRM system or UNIX permission model will ever change that law unless you change the model (ala Trusted Computing, which removes the implicit trust between the PC and the user). From soft at lindenlab.com Mon Oct 1 03:09:54 2007 From: soft at lindenlab.com (Soft) Date: Mon Oct 1 03:09:57 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> Message-ID: In looking for the difference here: Does 2.5 perhaps come with an updated lex and yacc? With 2.4.1 and 10.4, I've got flex 2.5.4 (ancient!) and Berkeley yacc 1.9 (ancient too). I've been hoping for an update on the former and a switch to bison for the latter. On 9/30/07, Michael Miller <1337mail@gmail.com> wrote: > Hmm... > Unfortunately, none of the macros seem to be working(Apple's macros > that is). Isn't there an option somewhere in XCode to force YACC to > output .h? > > -- Mike > > On 9/30/07, Argent Stonecutter wrote: > > > > On 30-Sep-2007, at 15:26, Michael Miller wrote: > > > > > I found some possible useful information for a patch(at > > > http://developer.apple.com/releasenotes/DeveloperTools/Xcode/RN- > > > Xcode/index.html#//apple_ref/doc/uid/TP40001051-DontLinkElementID_2). > > > > These variables are not automatically exposed in include files. It > > says "You may use these build settings to define other settings that > > affect the build (for example, to have different build folders for > > different Xcode versions) or to pass as preprocessor values for > > compilation or Info.plist preprocessing." > > > > Try this: > > > > #ifdef __APPLE_CC__ > > # if __APPLE_CC__ > 5250 > > # include AvailabilityMacros.h > > # ifdef MAC_OS_X_VERSION_10_5 > > # define YACC_GENERATES_HPP 1 > > # endif > > # endif > > #endif > > > > // something similar for Windows can go here > > > > # ifdef YACC_GENERATES_HPP > > # include "indra.y.hpp" > > # else > > # include "indra.y.h" > > # endif > > > > _______________________________________________ > > 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 nicholaz at blueflash.cc Mon Oct 1 04:11:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Oct 1 04:50:07 2007 Subject: [sldev] Re: [META] Formal critique of new auth mechanism? In-Reply-To: <4700BC31.60807@zurich.ibm.com> References: <46FD72A7.7040603@lindenlab.com> <200709292024.58893.dale@daleglass.net> <200709292155.17606.dale@daleglass.net> <46FEB44A.8090708@lindenlab.com> <46FED9D2.4000603@blueflash.cc> <4700BC31.60807@zurich.ibm.com> Message-ID: <4700D5D6.2080704@blueflash.cc> dirk husemann wrote: > Nicholaz Beresford wrote: >> Bottom line is that the new auth mechanism is something that offers >> neglectible >> improvement in security and will cause countless problems or developer >> hours >> on both sides. > agree with that, too. > > nick, could you add that to the wiki? Matt is the keeper of the page and added it to the talk section. Nick From secret.argent at gmail.com Mon Oct 1 06:11:18 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 06:11:20 2007 Subject: [sldev] [Upcoming Changes] Website Viewer Authentication In-Reply-To: <1191223402.11151.2.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <47009E0B.5010205@zurich.ibm.com> <1191223402.11151.2.camel@localhost> Message-ID: <207D8190-DF9D-44DD-AF6C-97D452FFCC3A@gmail.com> On 01-Oct-2007, at 02:23, Callum Lerwick wrote: > Or instead of using a protocol handler, use a mime type handler. From a security point of view there is no difference between these two options. They are both subject to the same filtering, blocking, and user interface issues. From secret.argent at gmail.com Mon Oct 1 06:17:39 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 06:17:40 2007 Subject: [sldev] [PATCH] Export Prims (complete) In-Reply-To: References: Message-ID: <2B9ED5D0-7D1B-455C-8BF2-1B264BD65701@gmail.com> On 01-Oct-2007, at 02:53, J?rgen Lehmann wrote: > As you can see the export code is very simple as it relies on the LLSD > system in the viewer, maybe it can be the first step toward a prim > storage format? Looks like the same kind of meta-xml as Apple's property list format. There's some examples of that in the viewer source in places like "linden/indra/newview/Info-SecondLife.plist". Change to and you're halfway there. :) From secret.argent at gmail.com Mon Oct 1 06:36:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 06:37:05 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191230378.3023.29.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> Message-ID: <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> On 01-Oct-2007, at 04:19, Ryan McDougall wrote: > Of course this brings us back to the original use case, an adulterated > client viewer source (where once you access, the game is up no matter > what). The solution is to not worry about that case, because unless you're using an Orange Book class B trusted computer system with mandatory access control at every level (and you'd have to port SL to it first, because it's unlikely to run on one as is), it doesn't matter whether you're using the official viewer or a third party viewer... as soon as you use any software other than that distributed by the OS vendor or Linden Labs the game is up no matter what. If you have the rights to install the copy of SL that you're running, then you have the rights to modify it. If you're being a Good UNIX Admin and you install it as a separate user ID just for Second Life that you don't normally have the rights to, then if you have the rights to run it, then you still have the rights to inject code into the copy of it you're running. There's canned scripts for doing this kind of thing after using the canned scripts from a virus toolkit that you used to compromise the user's computer in the first place. You drop the whole package on one of the well known accidentally-open FTP servers and link to it from a post by a cutout account on forums.secondlife.com and you're home free... so even sticking the exploit code inside J Random Sculpty Editor isn't necessary. This may seem an unlikely situation, but it's more likely than someone distributing a crocked client. This isn't the BBS era any more. You don't get software by trusting that the copy of RandomTerminal that J Random User uploaded to the local Pirates Cove is legit. You go to J Random User's public website, and if it's crocked, Linden Labs can subpoena his identity from the ISP and lay down a legal pimpsmack. From andrew at lindenlab.com Mon Oct 1 08:25:44 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Mon Oct 1 08:26:16 2007 Subject: [sldev] Havok4 Public Beta is here! In-Reply-To: References: <46FD8483.70406@lindenlab.com> <1191126249.3619.114.camel@localhost> Message-ID: <47011178.8060601@lindenlab.com> Here is some more info about the Havok4 project: (1) The RCCS system is the main thing that caps the crippling lag in the Havok4 physics engine, so I won't be providing any LSL override flags for it in the short term. Complex machines with spinning wheels, rotors, impellers, and so forth may have to wait for the improvements that will come sometime after Havok4 is working well enough for us to deploy it. The primary goal of the Havok4 project is to reduce the crash rate. (2) There is known problem where the script engine in Havok4 lags significantly more than in Havok1. I don't know why that would be the case, however the beta version of Bonifacio reproduces the problem reliably, so we're going to try to figure that out this week. Over the weekend I'd expect a few other regions to have succumbed to the problem. I mention this only to point out that not all the lag witnessed in the Havok4 public preview is coming from the physics engine. (3) The prim limit for dynamic objects is 31, not 21. The reason the limit was not changed in Havok4 is the border crossing problem, which is unrelated to the physics engine. The more primitives in an object (and scripts, and object contents, etc) the longer it takes save/load the object across the border. We'll be tackling that problem later -- reducing the crashes is more important. (4) Since I was overhauling most of the create-object code paths I took the time to insert some anti-megaprim code back into the project which some dev had accidentally removed a few years ago. However, at the request of the majority of LL (the "But Megaprims Are Cool" crowd) I was going to relax the anti-megaprim rules to allow existing megaprims with dimensions 256 or less. I just hadn't got around to doing it before it was pushed into public preview. (5) Many enhancements to the physics engine will happen after Havok4 is done enough to deliver. Some of the ones I already want to do have been discussed here, such as: (a) simplified collision proxies for linked collections of primitives (b) per-prim phantom settings (c) smarter management of activation/deactivation of simulation islands (waking up (or not waking up) collections of objects that are all touching) (6) One of the significant changes under the hood is that it will be much easier to upgrade or swap out the physics engine in the future. So this is a big step toward open sourcing the simulator code since our inability to distribute the Havok libs is the largest licensing obstacle we have to deal with. There is still lots of work to be done before we could open it up, but progress is being made. (7) I don't know if anyone noticed, but ground vehicles are pretty much busted in the current Havok4 preview. They tend to snag and and tumble on the terrain. I think I fixed it late Friday evening so that should go out in the next update to the preview. (8) There are only two LL developers working on the Havok4 project at the moment. I estimate that it will be in preview for at least two weeks, probably more. When we do start to deploy it we probably won't be releasing it all at once. More likely we'll put a few sandboxes up and move some misc regions over to Havok4, and then allow some private estates to upgrade. If everything looks good after while we'll push it to every region. - Andrew From secret.argent at gmail.com Mon Oct 1 09:08:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 09:08:56 2007 Subject: [sldev] Havok4 Public Beta is here! In-Reply-To: <47011178.8060601@lindenlab.com> References: <46FD8483.70406@lindenlab.com> <1191126249.3619.114.camel@localhost> <47011178.8060601@lindenlab.com> Message-ID: <435293D2-D886-40A8-82D4-8E340EC99422@gmail.com> On 01-Oct-2007, at 10:25, Andrew Meadows wrote: > (1) The RCCS system is the main thing that caps the crippling lag > in the Havok4 physics engine, so I won't be providing any LSL > override flags for it in the short term. How about a flag (scripted or not) that says "disable physics on this object instead"? that way the machine will stop working but at least it won't explode. > (3) The prim limit for dynamic objects is 31, not 21. The reason > the limit was not changed in Havok4 is the border crossing problem, > which is unrelated to the physics engine. Border crossing in vehicles seems to be pretty much hosed in beta. This applies to planes as well as ground vehicles. > (5) Many enhancements to the physics engine will happen after > Havok4 is done enough to deliver. Some of the ones I already want > to do have been discussed here, such as: > (a) simplified collision proxies for linked collections of > primitives > (b) per-prim phantom settings > (c) smarter management of activation/deactivation of simulation > islands > (waking up (or not waking up) collections of objects that > are all touching) How about New Joints? If you could re-introduce joints some of the complex machine issues would go away, since people have had to replace jointed objects with machines (eg, Beatfox Xevious' windchimes). From matthew.dowd at hotmail.co.uk Mon Oct 1 09:12:43 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Oct 1 09:12:45 2007 Subject: [sldev] Re: [META] Formal critique of new auth mechanism? In-Reply-To: <4700D5D6.2080704@blueflash.cc> References: <46FD72A7.7040603@lindenlab.com> <200709292024.58893.dale@daleglass.net> <200709292155.17606.dale@daleglass.net> <46FEB44A.8090708@lindenlab.com> <46FED9D2.4000603@blueflash.cc> <4700BC31.60807@zurich.ibm.com> <4700D5D6.2080704@blueflash.cc> Message-ID: I've put it in the talk section for reference. I've tried to make sure that Nick's key points are in the summary section on the main page, and the others are in the rest of the page. Oh, and thanks to the forum folk, I managed to get a pro for synchronising the website logon to the SL viewer logon ;-) Matthew > Date: Mon, 1 Oct 2007 13:11:18 +0200> From: nicholaz@blueflash.cc> To: hud@zurich.ibm.com> Subject: Re: [sldev] Re: [META] Formal critique of new auth mechanism?> CC: sldev@lists.secondlife.com> > > dirk husemann wrote:> > Nicholaz Beresford wrote:> >> Bottom line is that the new auth mechanism is something that offers> >> neglectible> >> improvement in security and will cause countless problems or developer> >> hours> >> on both sides.> > agree with that, too.> > > > nick, could you add that to the wiki?> > Matt is the keeper of the page and added it to the talk section.> > > Nick> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/1381f92a/attachment.htm From dmahalko at gmail.com Mon Oct 1 09:27:47 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 1 09:27:50 2007 Subject: [sldev] Idea: Client side rotation, relative to object motion Message-ID: Lately I was trying to think of other ways LL could improve the detail and appearance of objects, while not increasing the network and simulator processing load. One area where the simulation is extremely hard to do properly is the realistic rotation of wheels. A script can set a speed of rotation for wheels, and it can read vehicle speed to set the rotation of the wheels, but unfortunately this is not a very precise process due to script lag and network lag. This rotation of objects could potentially be offloaded onto the client, where the precision of wheel rotation can closely match the From dmahalko at gmail.com Mon Oct 1 09:30:49 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 1 09:30:57 2007 Subject: [sldev] Re: Idea: Client side rotation, relative to object motion In-Reply-To: References: Message-ID: Whoops, I hit "Send" rather than "Save" in GMail. Time to clean the glasses. :-( -Dale On 10/1/07, Dale Mahalko wrote: > Lately I was trying to think of other ways LL could improve the detail > and appearance of objects, while not increasing the network and > simulator processing load. > > One area where the simulation is extremely hard to do properly is the > realistic rotation of wheels. A script can set a speed of rotation for > wheels, and it can read vehicle speed to set the rotation of the > wheels, but unfortunately this is not a very precise process due to > script lag and network lag. > > This rotation of objects could potentially be offloaded onto the > client, where the precision of wheel rotation can closely match the > From andrew at lindenlab.com Mon Oct 1 09:37:07 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Mon Oct 1 09:38:02 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709220524i474f730bg1172aeeebcdc3bbf@mail.gmail.com> References: <200709201042.40855.dale@daleglass.net> <7992d0d60709220524i474f730bg1172aeeebcdc3bbf@mail.gmail.com> Message-ID: <47012233.5040307@lindenlab.com> If you take a concave object in Havok and replace it with a collection of convex parts that approximate the same shape you end up with more efficient collisions... sorta. It depends on how many pieces you used to approximate the concave mesh, if the number of sub-parts is very high you'll get diminishing returns. But... I've seen Havok2 improve performance when taking a 20-prim object made from hollow-cut-torii and replacing it with about 200 small boxes. Havok4.x still has a problem when colliding two of their "list shapes" (collections of smaller shapes) together. We solved it by wrapping their list shapes in a Memory Optimized Partial Polytope (MOPP) but constructing the MOPP is a little expensive. According to the Havok engineers they've fixed list-shapes vs list-shape collisions in Havok5 making them about 97% as efficient as a MOPP-wrapped-list, without the cost of computing the MOPP. One of the things I'd like to do eventually is to ignore Havok's concave-concave collision code, and just use their convex-convex algorithms, using largish collections of convex shapes to approximate the concave primitives available in SL. - Andrew Dirk Moerenhout wrote: > I never tested how SL (or rather the old Havok I guess) does it but I > can't imagine it's, currently, the fastest way to do it. Nor as you > noticed yourself is it really usable. > > If you build up the sphere with too few triangles you may end up > getting something that is (or maybe rather was) mathematically faster > as you can simplify the triangle math more easily. Still with todays > FPU power it'd be better to just calculate how a real sphere would > roll over that plane. > > This is what Nick Gray from Havok says about it in the PDF that was in > this thread earlier on: > "But we need one more piece of info to help us guide our choices for > efficiency, and it's that convex objects are easier to perform > collisions with than non-convex objects. > So triangles, spheres, capsules, cylinders, boxes, cones or convex > polyhedra are 'simple'. Arbitrary meshes (triangle soups), or even > just triangle representations of the above > convex shapes are 'complex'. And the rule-of-thumb is that collisions > between complex geometries are very costly to do in real-time." > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From andrew at lindenlab.com Mon Oct 1 09:51:48 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Mon Oct 1 09:52:21 2007 Subject: [sldev] Havok4: Offer LOD degrade priority to landowners and groups first In-Reply-To: References: Message-ID: <470125A4.7060909@lindenlab.com> Such complex machines may lie outside the possibility space in SL for a while. At the moment the shape LOD system is not very smart so yes, the grief mode you describe would work. More importantly, it may be possible for a griefer to cause someone's house to get boxified --> ejecting all the avatars therein. The next steps for making the RCCS smarter are probably going to be: (a) take some exceptions for avatars --> prefer to collide them against other objects highest LOD (b) make the RCCS system crack down on a simulation island basis --> figure out which piles of objects are causing the lag and only boxify those piles If (b) were done, and we had tighter parcel access enforcement (one of the other things I want to work on) it might be possible to prevent a particular contraption from suffering from shape LOD change by wrapping it in a parcel with sufficiently restrictive access settings. - Andrew Dale Mahalko wrote: > The new Havok-4 engine has the ability to degrade physics calculations down > to a cube per prim when the simulator is lagging. > > This has potential griefing effects against machine builders since some > random idiot could come by and rez up griefer objects which lag the sim and > blow my machine apart. > > I would like to request that LOD be controllable via a new "priority" > attribute assigned to each prim, and that landowners be assigned a > relatively high priority for degrading, then followed by group members for > that land. > > > This way when Random Idiot tries to lag the sim, the sim will first > LOD-degrade all of the visitor's objects before it begins to degrade any of > the landowner's objects. The landowner's objects may survive the lag > completely unscathed while the griefers objects lay there in a continuously > LOD-cubed degrade state. > > -Scalar Tardis / Dale Mahalko > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Mon Oct 1 09:53:38 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Oct 1 09:53:39 2007 Subject: [sldev] Compiling without LLMOZLIB In-Reply-To: <46FFC350.7070005@blueflash.cc> References: <46FFC350.7070005@blueflash.cc> Message-ID: <47012612.7010107@cox.net> Nicholaz Beresford wrote: > > I'm sometimes compiling without LLMozLib (especially when > leak debugging) but thinking about making a full version > without it. > > Is there anything else besides the into screen that would > get lost/dysfunctional when not having it? > > > Nick The Web panel in the avatar profile won't work. Haven't seen any other issue pop up though. SOMETIMES, the client still takes forever to start up, even after I've compiled without mozlib (via setting enable to 0), so there may be other interactions going on, at least on the Mac. Perhaps something is on a timer, waiting for a signal from the mozlib, which never occurs. L From bos at lindenlab.com Mon Oct 1 10:45:55 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Oct 1 10:46:02 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <1191017317.1456.7.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> Message-ID: <47013253.5000301@lindenlab.com> Callum Lerwick wrote: > Which is why LL should focus on working with Linux distributions to get > Second Life into the distributions themselves, rather than distributing > binary blobs. We're happy to see people packaging the viewer for different Linux distributions (for example, I'm watching the Fedora packaging tasks), and willing to help out where we can. I've done quite a bit of work to make it easier to build a standalone viewer, for example. If there are specific things you'd like to see done, file JIRA tasks, and we'll plug away at them as the opportunity presents itself. If you want to file an umbrella task and connect the subtasks to it so that it's easier to see which ones are intended to ease distro integration, all the better. Obviously, there are enough distros out there that we can't devote significant resources to each one individually, but that doesn't mean we lack enthusiasm for the idea. Tell us how we can help you most effectively, and we'll pitch in. References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> Message-ID: <470136F0.8020802@gmail.com> Bryan O'Sullivan wrote: > Callum Lerwick wrote: > >> Which is why LL should focus on working with Linux distributions to get >> Second Life into the distributions themselves, rather than distributing >> binary blobs. > > We're happy to see people packaging the viewer for different Linux > distributions (for example, I'm watching the Fedora packaging tasks), > and willing to help out where we can. I've done quite a bit of work to > make it easier to build a standalone viewer, for example. > > If there are specific things you'd like to see done, file JIRA tasks, > and we'll plug away at them as the opportunity presents itself. If you > want to file an umbrella task and connect the subtasks to it so that > it's easier to see which ones are intended to ease distro integration, > all the better. > > Obviously, there are enough distros out there that we can't devote > significant resources to each one individually, but that doesn't mean we > lack enthusiasm for the idea. Tell us how we can help you most > effectively, and we'll pitch in. > Well if the viewer would just build out of the box that would be a great help the Main issues for me are:- http://jira.secondlife.com/browse/VWR-2488 and http://jira.secondlife.com/browse/VWR-1853 Its very close to just being able to do "scons DISTCC=no STANDALONE=yes BTARGET=client ELFIO=no MOZLIB=no ARCH=x86_64 BUILD=releasefordownload" I think that's the only two issues stopping that and one of them is AMD64 specific anyway, but still needs updating. I am sure there are others but VWR-2488 " Standalone build is almost, but not quite there." might make a good umbrella for related issues as it seems bang on topic. Regards Robin From jhurliman at wsu.edu Mon Oct 1 11:08:19 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Oct 1 11:08:16 2007 Subject: [sldev] [PROTOCOL] What is AgentMovementComplete.SimData.ChannelVersion? Message-ID: <47013793.5030300@wsu.edu> http://libsecondlife.org/template/release/diff-1.18.3.5.txt Anyone? John Hurliman From robin.cornelius at gmail.com Mon Oct 1 11:36:55 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Oct 1 11:37:03 2007 Subject: [sldev] Compiling without LLMOZLIB In-Reply-To: <47012612.7010107@cox.net> References: <46FFC350.7070005@blueflash.cc> <47012612.7010107@cox.net> Message-ID: <47013E47.1080302@gmail.com> Lawson English wrote: > Nicholaz Beresford wrote: >> >> I'm sometimes compiling without LLMozLib (especially when >> leak debugging) but thinking about making a full version >> without it. >> >> Is there anything else besides the into screen that would >> get lost/dysfunctional when not having it? >> >> >> Nick > The Web panel in the avatar profile won't work. Haven't seen any other > issue pop up though. > > SOMETIMES, the client still takes forever to start up, even after I've > compiled without mozlib (via setting enable to 0), so there may be other > interactions going on, at least on the Mac. Perhaps something is on a > timer, waiting for a signal from the mozlib, which never occurs. > Think this is unrelated IMHO, I see this on official windows builds on only one PC at work. It didn't use to do this but does now, it can take a few minutes at least to show the logon screen, once past that its all OK. Never seen this on any other PC's but you say you see it on Mac so there might be a race condition blocking something at startup. May be i can get a debug build on that system and break it during the pause to see what is happening. Robin From bridie at lindenlab.com Mon Oct 1 12:08:17 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Mon Oct 1 12:08:24 2007 Subject: [sldev] New Viewer: Second Life 1.18.3 Viewer Available Today! Message-ID: <470145A1.2060103@lindenlab.com> Thanks for everyone's help with our first Release Candidate viewer --- Second Life 1.18.3 Viewer is now the primary viewer download! Download via the release viewer login screen or simply use get.secondlife.com to get the newest main viewer version. 1.18.3.5 source code is identical except for release notes, but we are planning on another drop anyway. --Bridie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/611d618d/attachment.htm From bridie at lindenlab.com Mon Oct 1 12:09:49 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Mon Oct 1 12:09:56 2007 Subject: [sldev] Help w/today's agenda? Message-ID: <470145FD.9050909@lindenlab.com> Hi folks- Does anyone have time to help with today's bug triage agenda? https://wiki.secondlife.com/wiki/Bug_triage/Monday_Agenda Aric, Soft, and I would really appreciate it -- thanks! See you @ 3. --Bridie From dzonatas at dzonux.net Mon Oct 1 12:33:25 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 1 12:31:31 2007 Subject: [sldev] Sculpties and Alpha channel (people think they broke in 1.18.3 and are screaming!) Message-ID: <47014B85.5000801@dzonux.net> Hi, I see there is a lot of people screaming about the changes in the alpha channel on the sculpties. They were never aware or missed the point that the alpha channel was never designated to be used as alpha mode on regular PNG of JPG type images. I suggest a quick fix to allow planned use of the alpha channel with the mode they expect is to use recently added extra bits on prims. It would mean a new UI button to toggle between different alpha modes. They main gotcha is that people will complain that they uploaded lots of textures and that they'll have to spend more money to fix and replace them. This extra toggle could prevent that mess with another viewer update. -- Power to Change the Void From odysseus654 at gmail.com Mon Oct 1 12:36:33 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Mon Oct 1 12:36:44 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> References: <46FF248E.10305@lindenlab.com> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> Message-ID: <1674f6c70710011236y5e8be88exf8ef3d51c166cd32@mail.gmail.com> I don't know if this helps in the conversation at all, but here is my (limited) experience with OpenID. I create an ID of the form username@someopenIDprovoder.com (there are ways to customize the domain name to something you host). This ID is given to an application. Then the application tries to open up the OpenID site and authenticate with that ID. The OpenID site will initially open up a web page asking you to login, select the identity that you wish to pass back, and verify that you really want that website to know about you. Optionally you can go through the process of creating a certificate on your local browser so that it simply asks you if you want to authenticate with the website. If you state "always yes", then the authentication would proceed without any prompts using the client certificate installed on your browser. The identity that you choose when logging into the OpenID provider does not seem to be the kind of information that could be used to establish alt accounts in SL, in the end the only thing that SL has is the OpenID, so multiple alts in SL would most likely require multiple OpenID accounts. I am kinda split on whether or not OpenId is a good direction to go with (as opposed to the integrated login that currently exists). I *really* don't want logging into the website to log into the SL client without authentication (for reasons that have been explained at great length here already). A lot of the site spoofing that I'm thinking is worried about here I'm guessing is the kind of spoofing that would confuse users (for instance, using international coding to make it look like the same domain name when it isn't) but would not as easily confuse applications (check the domain on the SSL certificate, make sure it matches the openID that the user has entered) None of this in my opinion has anything to do with modified clients though, nor could it. LL could do checks to try to track changing IP addresses and require more authentication if the login location changes to an unexpected place, but this is hardly anything that changing the authentication stream in this manner would affect at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/a61c5e88/attachment.htm From sean at dague.net Mon Oct 1 12:42:42 2007 From: sean at dague.net (Sean Dague) Date: Mon Oct 1 12:41:26 2007 Subject: [sldev] Re: New Viewer: Second Life 1.18.3 Viewer Available Today! In-Reply-To: <470145A1.2060103@lindenlab.com> References: <470145A1.2060103@lindenlab.com> Message-ID: <20071001194242.GM617@dague.net> On Mon, Oct 01, 2007 at 12:08:17PM -0700, Bridie Linden wrote: > Thanks for everyone's help with our first Release Candidate viewer --- > Second Life 1.18.3 Viewer is now the primary viewer download! Download > via the release viewer login screen or simply use get.secondlife.com to > get the newest main viewer version. > > 1.18.3.5 source code is identical except for release notes, but we are > planning on another drop anyway. It appears that the linux version doesn't work on systems where /bin/sh isn't bash. Modifying the secondlife script to start with #!/bin/bash instead of #!/bin/sh fixes things. -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/20071001/11c19374/attachment.pgp From bbyer at mm.st Mon Oct 1 12:46:36 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Oct 1 12:46:41 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> Message-ID: <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: >> Isn't there an option somewhere in XCode to force YACC to >> output .h? > > Did you try the change I suggested for the SConstruct? Unfortunately, that's not going to help -- XCode uses its own build system, bypassing SConstruct. On Oct 1, 2007, at 3:09 AM, Soft wrote: > In looking for the difference here: Does 2.5 perhaps come with an > updated lex and yacc? With 2.4.1 and 10.4, I've got flex 2.5.4 > (ancient!) and Berkeley yacc 1.9 (ancient too). I've been hoping for > an update on the former and a switch to bison for the latter. I'm not sure about 2.5, but 3.0 has: bbyer:lscript_compile bbyer$ lex --version flex 2.5.33 bbyer:lscript_compile bbyer$ yacc --version bison (GNU Bison) 2.3 Xcode seems to be automatically executing the following line when it encounters a .y file: bbyer:lscript_compile bbyer$ yacc -o indra.y.cpp -d indra.y conflicts: 88 reduce/reduce bbyer:lscript_compile bbyer$ ls -l indra.y* -rw-r--r-- 1 bbyer wheel 45812 Sep 20 12:33 indra.y -rw-r--r-- 1 bbyer wheel 146221 Oct 1 12:31 indra.y.cpp -rw-r--r-- 1 bbyer wheel 6131 Oct 1 12:31 indra.y.hpp This is, presumably, because: -d Write an extra output file containing macro definitions for the token type names defined in the grammar and the semantic value typeYYSTYPE, as well as a few extern variable declarations. If the parser output file is named name.c then this file is named name.h. -o outfile --output-file=outfile Specify the name outfile for the parser file. The other output files' names are constructed from outfile as described under the -v and -d switches. ... so I guess that that's how -d responds when you tell it you want a .cpp file. Do we want to fix this in the source code (by adding a third term to the #ifdef), or as a custom build step in the .xcodeproj? -b PS Also watch out for http://jira.secondlife.com/browse/VWR-2551 when building with late versions of XCode. From secret.argent at gmail.com Mon Oct 1 12:52:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 12:52:40 2007 Subject: [sldev] Re: New Viewer: Second Life 1.18.3 Viewer Available Today! In-Reply-To: <20071001194242.GM617@dague.net> References: <470145A1.2060103@lindenlab.com> <20071001194242.GM617@dague.net> Message-ID: <2A00D359-753C-4428-8707-B406FE0F5AA5@gmail.com> On 01-Oct-2007, at 14:42, Sean Dague wrote: > It appears that the linux version doesn't work on systems where / > bin/sh > isn't bash. Modifying the secondlife script to start with #!/bin/bash > instead of #!/bin/sh fixes things. What does the startup script do that's bash-specific? After all, it's possible that some people don't have bash installed at all. My experience has been that most scripts written using bash or zsh extensions are just as readable when modified to use standard shell behavior. From 1337mail at gmail.com Mon Oct 1 13:03:13 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 1 13:03:16 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> Message-ID: <2c99c46e0710011303ged275c1hfbbb197dff19315f@mail.gmail.com> I made a JIRA issue at http://jira.secondlife.com/browse/VWR-2620. I vote for an n-way ifdef statement. Adding more build steps adds (in my opinion) a considerable amount more bloat to the development environment and makes things messy. Moreover, I think it's proper to generate .hpp files for .cpp files. I consider this to be a bug in the older versions. Can someone write the n-way ifdef statement and post it here? Nothing I've tried so far works. Thanks, Mike PS: Does XCode 3.0 work for you? For me it gives a bunch of internal errors about inserting nil into an array. I filed a bug report with Apple, but I'm just wondering if you had a similar issue. On 10/1/07, Ben Byer wrote: > > On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: > >> Isn't there an option somewhere in XCode to force YACC to > >> output .h? > > > > Did you try the change I suggested for the SConstruct? > > Unfortunately, that's not going to help -- XCode uses its own build > system, bypassing SConstruct. > > On Oct 1, 2007, at 3:09 AM, Soft wrote: > > > In looking for the difference here: Does 2.5 perhaps come with an > > updated lex and yacc? With 2.4.1 and 10.4, I've got flex 2.5.4 > > (ancient!) and Berkeley yacc 1.9 (ancient too). I've been hoping for > > an update on the former and a switch to bison for the latter. > > I'm not sure about 2.5, but 3.0 has: > > bbyer:lscript_compile bbyer$ lex --version > flex 2.5.33 > bbyer:lscript_compile bbyer$ yacc --version > bison (GNU Bison) 2.3 > > Xcode seems to be automatically executing the following line when it > encounters a .y file: > > bbyer:lscript_compile bbyer$ yacc -o indra.y.cpp -d indra.y > conflicts: 88 reduce/reduce > bbyer:lscript_compile bbyer$ ls -l indra.y* > -rw-r--r-- 1 bbyer wheel 45812 Sep 20 12:33 indra.y > -rw-r--r-- 1 bbyer wheel 146221 Oct 1 12:31 indra.y.cpp > -rw-r--r-- 1 bbyer wheel 6131 Oct 1 12:31 indra.y.hpp > > This is, presumably, because: > > -d > Write an extra output file containing macro definitions > for the token type names defined in > the grammar and the semantic value typeYYSTYPE, as well as a few > extern variable declarations. > > If the parser output file is named name.c then this > file is named name.h. > > > -o outfile > --output-file=outfile > Specify the name outfile for the parser file. > > The other output files' names are constructed from > outfile as described under the -v and -d switches. > > > ... so I guess that that's how -d responds when you tell it you want > a .cpp file. > > Do we want to fix this in the source code (by adding a third term to > the #ifdef), or as a custom build step in the .xcodeproj? > > -b > > PS Also watch out for http://jira.secondlife.com/browse/VWR-2551 when > building with late versions of XCode. > From qarl at lindenlab.com Mon Oct 1 13:13:21 2007 From: qarl at lindenlab.com (Karl Stiefvater) Date: Mon Oct 1 13:15:39 2007 Subject: [sldev] Re: Sculpties and Alpha channel (people think they broke in 1.18.3 and are screaming!) In-Reply-To: <47014B85.5000801@dzonux.net> References: <47014B85.5000801@dzonux.net> Message-ID: Dzonatas - nothing has changed w/r/t alphas and sculpties. where is the screaming occurring? K. On Oct 1, 2007, at 12:33 PM, Dzonatas wrote: > Hi, > > I see there is a lot of people screaming about the changes in the > alpha channel on the sculpties. They were never aware or missed the > point that the alpha channel was never designated to be used as > alpha mode on regular PNG of JPG type images. > > I suggest a quick fix to allow planned use of the alpha channel > with the mode they expect is to use recently added extra bits on > prims. It would mean a new UI button to toggle between different > alpha modes. > > They main gotcha is that people will complain that they uploaded > lots of textures and that they'll have to spend more money to fix > and replace them. This extra toggle could prevent that mess with > another viewer update. > > > > -- > Power to Change the Void From secret.argent at gmail.com Mon Oct 1 13:16:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 13:16:04 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> Message-ID: On 01-Oct-2007, at 14:46, Ben Byer wrote: > On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: >>> Isn't there an option somewhere in XCode to force YACC to >>> output .h? >> Did you try the change I suggested for the SConstruct? > Unfortunately, that's not going to help -- XCode uses its own build > system, bypassing SConstruct. // This stuff can go in some include file with other os-specific code. // I removed the test for the compiler version, the availability macros predate any version of OS X that SL is going to run on. // To use the XCODE_VERSION_ACTUAL the project will need to be modified to expose that constant as a macro. #ifdef __APPLE_CC__ # include # ifdef MAC_OS_X_VERSION_10_5 /* Not defined for pre-leopard versions */ # define YACC_GENERATES_HPP 1 # endif # ifdef XCODE_VERSION_ACTUAL # if XCODE_VERSION_ACTUAL >= 0250 /* or 0300 */ # define YACC_GENERATES_HPP 1 # endif # endif #endif // something similar for Windows can go here, if we want to revert the hack in the build tools // then, replace the line including indra.y.h with this... # ifdef YACC_GENERATES_HPP # include "indra.y.hpp" # else # include "indra.y.h" # endif Incidentally, I think there's a bug in Apple's docs. 0250 is 168 decimal. If Apple's actually using that manifest constant in their include files they're going to be very unhappy when they get an xcode version with a minor version greater than 7. :) From 1337mail at gmail.com Mon Oct 1 13:20:34 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 1 13:20:38 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> Message-ID: <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> For some reason, XCODE_VERSION_ACTUAL is not defined for me(with XCode 2.5). I don't know why, but it is not defined. -- Mike On 10/1/07, Argent Stonecutter wrote: > On 01-Oct-2007, at 14:46, Ben Byer wrote: > > On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: > >>> Isn't there an option somewhere in XCode to force YACC to > >>> output .h? > > >> Did you try the change I suggested for the SConstruct? > > > Unfortunately, that's not going to help -- XCode uses its own build > > system, bypassing SConstruct. > > // This stuff can go in some include file with other os-specific code. > // I removed the test for the compiler version, the availability > macros predate any version of OS X that SL is going to run on. > // To use the XCODE_VERSION_ACTUAL the project will need to be > modified to expose that constant as a macro. > #ifdef __APPLE_CC__ > # include > # ifdef MAC_OS_X_VERSION_10_5 /* Not defined for pre-leopard > versions */ > # define YACC_GENERATES_HPP 1 > # endif > # ifdef XCODE_VERSION_ACTUAL > # if XCODE_VERSION_ACTUAL >= 0250 /* or 0300 */ > # define YACC_GENERATES_HPP 1 > # endif > # endif > #endif > > // something similar for Windows can go here, if we want to revert > the hack in the build tools > > // then, replace the line including indra.y.h with this... > # ifdef YACC_GENERATES_HPP > # include "indra.y.hpp" > # else > # include "indra.y.h" > # endif > > Incidentally, I think there's a bug in Apple's docs. 0250 is 168 > decimal. If Apple's actually using that manifest constant in their > include files they're going to be very unhappy when they get an xcode > version with a minor version greater than 7. :) > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Mon Oct 1 13:23:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 13:23:14 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011303ged275c1hfbbb197dff19315f@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011303ged275c1hfbbb197dff19315f@mail.gmail.com> Message-ID: <3E7CD925-A66B-4EE6-9600-71020AEA53C8@gmail.com> On 01-Oct-2007, at 15:03, Michael Miller wrote: > Can someone write the n-way ifdef statement and post it here? Nothing > I've tried so far works. // This stuff can go in some include file with other os-specific code. // I removed the test for the compiler version, the availability macros predate any version of OS X that SL is going to run on. // To use the XCODE_VERSION_ACTUAL the project will need to be modified to expose that constant as a macro. #ifdef __APPLE_CC__ # include # ifdef MAC_OS_X_VERSION_10_5 /* Not defined for pre-leopard versions */ # define YACC_GENERATES_HPP 1 # endif # ifdef XCODE_VERSION_ACTUAL # if XCODE_VERSION_ACTUAL >= 0250 /* or 0300 */ # define YACC_GENERATES_HPP 1 # endif # endif #endif #ifdef LL_WINDOWS # include "ytab.h" #else # ifdef YACC_GENERATES_HPP # include "indra.y.hpp" # else # include "indra.y.h" # endif #endif From secret.argent at gmail.com Mon Oct 1 13:31:18 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 13:31:17 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> Message-ID: <83BE709B-1A7D-4F5F-9FC0-D247BF926F94@gmail.com> On 01-Oct-2007, at 15:20, Michael Miller wrote: > For some reason, XCODE_VERSION_ACTUAL is not defined for me(with XCode > 2.5). I don't know why, but it is not defined. That's expected. That's why I noted "To use the XCODE_VERSION_ACTUAL the project will need to be modified to expose that constant as a macro." I've expended that comment a little in the version I just added to your Jira. From dzonatas at dzonux.net Mon Oct 1 13:33:46 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 1 13:31:47 2007 Subject: [sldev] Re: Sculpties and Alpha channel (people think they broke in 1.18.3 and are screaming!) In-Reply-To: References: <47014B85.5000801@dzonux.net> Message-ID: <470159AA.1090900@dzonux.net> Most of it came from Sculpty Dev. I was trying to figure it out. I suspect it was do to some confusion in relayed messages caused a little hype about the blog message, thinking that *any* sculpty with alpha would make the *entire* prim appear invisible in-world. =/ I'm thinking some kind of toggle (for what to do with the alpha channel) is still needed even after the confusion is cleared-up, but just not as urgently as it was being reported. Karl Stiefvater wrote: > Dzonatas - > > nothing has changed w/r/t alphas and sculpties. where is the > screaming occurring? > > > K. > > On Oct 1, 2007, at 12:33 PM, Dzonatas wrote: > >> Hi, >> >> I see there is a lot of people screaming about the changes in the >> alpha channel on the sculpties. They were never aware or missed the >> point that the alpha channel was never designated to be used as alpha >> mode on regular PNG of JPG type images. >> >> I suggest a quick fix to allow planned use of the alpha channel with >> the mode they expect is to use recently added extra bits on prims. >> It would mean a new UI button to toggle between different alpha modes. >> >> They main gotcha is that people will complain that they uploaded lots >> of textures and that they'll have to spend more money to fix and >> replace them. This extra toggle could prevent that mess with another >> viewer update. >> >> >> >> -- >> Power to Change the Void > > > -- Power to Change the Void From qarl at lindenlab.com Mon Oct 1 13:37:05 2007 From: qarl at lindenlab.com (Karl Stiefvater) Date: Mon Oct 1 13:37:08 2007 Subject: [sldev] Re: Sculpties and Alpha channel (people think they broke in 1.18.3 and are screaming!) In-Reply-To: <470159AA.1090900@dzonux.net> References: <47014B85.5000801@dzonux.net> <470159AA.1090900@dzonux.net> Message-ID: <61CE7619-C8CB-4A7F-8245-C79657692DF6@lindenlab.com> ahhh... yes. that's entirely hysteria. the JIRA task cited by the release notes was mis-named - the issue has nothing to do with alpha channels. (the bug is actually that some degenerate surfaces slipped through our filter. and the fix is waiting to merge into release.) and yes - if/when we do start using the sculpt's alpha channel - we'll accompany the feature with a user toggle - so as not to break existing content. K. On Oct 1, 2007, at 1:33 PM, Dzonatas wrote: > Most of it came from Sculpty Dev. > > I was trying to figure it out. I suspect it was do to some > confusion in relayed messages caused a little hype about the blog > message, thinking that *any* sculpty with alpha would make the > *entire* prim appear invisible in-world. =/ > > I'm thinking some kind of toggle (for what to do with the alpha > channel) is still needed even after the confusion is cleared-up, > but just not as urgently as it was being reported. > > > Karl Stiefvater wrote: >> Dzonatas - >> >> nothing has changed w/r/t alphas and sculpties. where is the >> screaming occurring? >> >> >> K. >> >> On Oct 1, 2007, at 12:33 PM, Dzonatas wrote: >> >>> Hi, >>> >>> I see there is a lot of people screaming about the changes in the >>> alpha channel on the sculpties. They were never aware or missed >>> the point that the alpha channel was never designated to be used >>> as alpha mode on regular PNG of JPG type images. >>> >>> I suggest a quick fix to allow planned use of the alpha channel >>> with the mode they expect is to use recently added extra bits on >>> prims. It would mean a new UI button to toggle between different >>> alpha modes. >>> >>> They main gotcha is that people will complain that they uploaded >>> lots of textures and that they'll have to spend more money to fix >>> and replace them. This extra toggle could prevent that mess with >>> another viewer update. >>> >>> >>> >>> -- >>> Power to Change the Void >> >> >> > > -- > Power to Change the Void From gigstaggart at gmail.com Mon Oct 1 12:22:24 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Oct 1 13:44:37 2007 Subject: [sldev] Help w/today's agenda? In-Reply-To: <470145FD.9050909@lindenlab.com> References: <470145FD.9050909@lindenlab.com> Message-ID: <470148F0.6010300@gmail.com> I'm on it, I was actually just about to get A Round Tuit anyway. :) -Jason Bridie Linden wrote: > Hi folks- > > Does anyone have time to help with today's bug triage agenda? > https://wiki.secondlife.com/wiki/Bug_triage/Monday_Agenda > > Aric, Soft, and I would really appreciate it -- thanks! See you @ 3. > > --Bridie > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From 1337mail at gmail.com Mon Oct 1 13:47:42 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 1 13:47:46 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> Message-ID: <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> One other thing I forgot to add: The initial part of the build(before files are compiled) contains this line: setenv XCODE_VERSION_ACTUAL 0250 This occurs even though the #ifdef doesn't work. Thus, bison is not able to access this information, it looks like, unfortunately. -- Mike On 10/1/07, Michael Miller <1337mail@gmail.com> wrote: > For some reason, XCODE_VERSION_ACTUAL is not defined for me(with XCode > 2.5). I don't know why, but it is not defined. > > -- Mike > > On 10/1/07, Argent Stonecutter wrote: > > On 01-Oct-2007, at 14:46, Ben Byer wrote: > > > On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: > > >>> Isn't there an option somewhere in XCode to force YACC to > > >>> output .h? > > > > >> Did you try the change I suggested for the SConstruct? > > > > > Unfortunately, that's not going to help -- XCode uses its own build > > > system, bypassing SConstruct. > > > > // This stuff can go in some include file with other os-specific code. > > // I removed the test for the compiler version, the availability > > macros predate any version of OS X that SL is going to run on. > > // To use the XCODE_VERSION_ACTUAL the project will need to be > > modified to expose that constant as a macro. > > #ifdef __APPLE_CC__ > > # include > > # ifdef MAC_OS_X_VERSION_10_5 /* Not defined for pre-leopard > > versions */ > > # define YACC_GENERATES_HPP 1 > > # endif > > # ifdef XCODE_VERSION_ACTUAL > > # if XCODE_VERSION_ACTUAL >= 0250 /* or 0300 */ > > # define YACC_GENERATES_HPP 1 > > # endif > > # endif > > #endif > > > > // something similar for Windows can go here, if we want to revert > > the hack in the build tools > > > > // then, replace the line including indra.y.h with this... > > # ifdef YACC_GENERATES_HPP > > # include "indra.y.hpp" > > # else > > # include "indra.y.h" > > # endif > > > > Incidentally, I think there's a bug in Apple's docs. 0250 is 168 > > decimal. If Apple's actually using that manifest constant in their > > include files they're going to be very unhappy when they get an xcode > > version with a minor version greater than 7. :) > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From 1337mail at gmail.com Mon Oct 1 13:49:23 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 1 13:49:27 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> Message-ID: <2c99c46e0710011349m6c9bb1g9d18c5f4cf27bd7f@mail.gmail.com> "Some include file"? What do you suggest? On 10/1/07, Michael Miller <1337mail@gmail.com> wrote: > One other thing I forgot to add: > The initial part of the build(before files are compiled) contains this line: > setenv XCODE_VERSION_ACTUAL 0250 > This occurs even though the #ifdef doesn't work. Thus, bison is not > able to access this information, it looks like, unfortunately. > > -- Mike > On 10/1/07, Michael Miller <1337mail@gmail.com> wrote: > > For some reason, XCODE_VERSION_ACTUAL is not defined for me(with XCode > > 2.5). I don't know why, but it is not defined. > > > > -- Mike > > > > On 10/1/07, Argent Stonecutter wrote: > > > On 01-Oct-2007, at 14:46, Ben Byer wrote: > > > > On Sep 30, 2007, at 6:35 PM, Argent Stonecutter wrote: > > > >>> Isn't there an option somewhere in XCode to force YACC to > > > >>> output .h? > > > > > > >> Did you try the change I suggested for the SConstruct? > > > > > > > Unfortunately, that's not going to help -- XCode uses its own build > > > > system, bypassing SConstruct. > > > > > > // This stuff can go in some include file with other os-specific code. > > > // I removed the test for the compiler version, the availability > > > macros predate any version of OS X that SL is going to run on. > > > // To use the XCODE_VERSION_ACTUAL the project will need to be > > > modified to expose that constant as a macro. > > > #ifdef __APPLE_CC__ > > > # include > > > # ifdef MAC_OS_X_VERSION_10_5 /* Not defined for pre-leopard > > > versions */ > > > # define YACC_GENERATES_HPP 1 > > > # endif > > > # ifdef XCODE_VERSION_ACTUAL > > > # if XCODE_VERSION_ACTUAL >= 0250 /* or 0300 */ > > > # define YACC_GENERATES_HPP 1 > > > # endif > > > # endif > > > #endif > > > > > > // something similar for Windows can go here, if we want to revert > > > the hack in the build tools > > > > > > // then, replace the line including indra.y.h with this... > > > # ifdef YACC_GENERATES_HPP > > > # include "indra.y.hpp" > > > # else > > > # include "indra.y.h" > > > # endif > > > > > > Incidentally, I think there's a bug in Apple's docs. 0250 is 168 > > > decimal. If Apple's actually using that manifest constant in their > > > include files they're going to be very unhappy when they get an xcode > > > version with a minor version greater than 7. :) > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > From sean at dague.net Mon Oct 1 14:28:19 2007 From: sean at dague.net (Sean Dague) Date: Mon Oct 1 14:27:02 2007 Subject: [sldev] Re: Re: New Viewer: Second Life 1.18.3 Viewer Available Today! In-Reply-To: <2A00D359-753C-4428-8707-B406FE0F5AA5@gmail.com> References: <470145A1.2060103@lindenlab.com> <20071001194242.GM617@dague.net> <2A00D359-753C-4428-8707-B406FE0F5AA5@gmail.com> Message-ID: <20071001212819.GN617@dague.net> On Mon, Oct 01, 2007 at 02:52:38PM -0500, Argent Stonecutter wrote: > On 01-Oct-2007, at 14:42, Sean Dague wrote: > >It appears that the linux version doesn't work on systems where / > >bin/sh > >isn't bash. Modifying the secondlife script to start with #!/bin/bash > >instead of #!/bin/sh fixes things. > > What does the startup script do that's bash-specific? After all, it's > possible that some people don't have bash installed at all. I've not seen a linux distro in the past 5 years that didn't install bash by default, so I think bash is fine. The problem line is line 75: export SL_OPT="`cat gridargs.dat` $@" that export fails if you actually attempt to pass in arguments (i.e. -loginuri ....). It looks like it passes if you don't give it any args, which is probably how it made it through qa, but it breaks with a: export: 75: url_you_passed_in: bad variable name At least on ubuntu where /bin/sh is dash, not bash. > My experience has been that most scripts written using bash or zsh > extensions are just as readable when modified to use standard shell > behavior. Agreed, but I try to avoid shell when possible. :) I'll leave that as an exercise for someone else, and just wanted to note my work around on list for any folks that could use the information. -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/20071001/24f527f9/attachment.pgp From secret.argent at gmail.com Mon Oct 1 15:10:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 15:10:14 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> Message-ID: <2903C027-19A2-4303-9C72-1D3D3AE6DA1D@gmail.com> On 01-Oct-2007, at 15:47, Michael Miller wrote: > One other thing I forgot to add: > The initial part of the build(before files are compiled) contains > this line: > setenv XCODE_VERSION_ACTUAL 0250 That doesn't really matter, because that is a UNIX environment variable and is not visible to the preprocessor. It would have to be turned into one (say, by passing - DXCODE_VERSION_ACTUAL="$XCODE_VERSION_ACTUAL" to cc) to be used that way. This is entirely consistent with the documentation and my previous comment. :) It's also kind of funky that that's a "setenv" rather than an "export", since that implies XCode is using csh to run its scripts, which is downright daft. From secret.argent at gmail.com Mon Oct 1 15:11:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 15:11:55 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011349m6c9bb1g9d18c5f4cf27bd7f@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> <2c99c46e0710011349m6c9bb1g9d18c5f4cf27bd7f@mail.gmail.com> Message-ID: <4AF788D7-4D04-42E5-A5E4-4DD2183FA356@gmail.com> On 01-Oct-2007, at 15:49, Michael Miller wrote: > "Some include file"? What do you suggest? I suggest none. For now, just stick it in indra.l. What file it finally goes into is Linden Policy. From sabin at lindenlab.com Mon Oct 1 14:56:14 2007 From: sabin at lindenlab.com (David Kaprielian (Sabin)) Date: Mon Oct 1 15:20:24 2007 Subject: [sldev] Re: Viewer Auth Feedback Message-ID: <47016CFE.1060509@lindenlab.com> Hello again SLDev! I asked for feedback and boy did I get feedback! We've been reading the e-mails and wiki critique page and it has sparked a few ongoing internal discussions. It looks like there are a lot of questions surrounding why we're working on this project. Initially, our goal was to consolidate our authentication implementation in order to support back-end anti-fraud work. This remains the priority! We understand your concerns of lost viewer functionality. Thus we are focusing on converting the current login screen to an embedded web login. This supports our back-end anti-fraud work and allows it to function without requiring you to login via a web page. We're working on putting out a beta with the new functionality that you can try out yourself. Until then, we'll continue to participate in this ongoing discussion. Thank you! ~Dave From bbyer at mm.st Mon Oct 1 15:24:25 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Oct 1 15:24:55 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011303ged275c1hfbbb197dff19315f@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709300812w57ff4346lcf619c03b72a38ad@mail.gmail.com> <6CC02761-94DC-4193-B9AD-FD3B418B447F@gmail.com> <2c99c46e0709300910m27fe161dlc599a58d22a7bd10@mail.gmail.com> <92099FB7-A377-41A1-88EF-E8893C9F8609@gmail.com> <2c99c46e0709301326u7254f2e0jde1735b0ba748da3@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011303ged275c1hfbbb197dff19315f@mail.gmail.com> Message-ID: <341454B3-ECE6-4FB8-BA83-56D948A1BAFD@mm.st> On Oct 1, 2007, at 1:03 PM, Michael Miller wrote: > PS: Does XCode 3.0 work for you? For me it gives a bunch of internal > errors about inserting nil into an array. I filed a bug report with > Apple, but I'm just wondering if you had a similar issue. Yup that's what I meant by: > PS Also watch out for http://jira.secondlife.com/browse/VWR-2551 when > building with late versions of XCode. :) (I've filed a bug report against Xcode explaining that this is not an acceptable way to indicate this error, fwiw.) -n -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/97c5438e/attachment-0001.htm From 1337mail at gmail.com Mon Oct 1 15:28:43 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 1 15:28:46 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <4AF788D7-4D04-42E5-A5E4-4DD2183FA356@gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> <2c99c46e0710011349m6c9bb1g9d18c5f4cf27bd7f@mail.gmail.com> <4AF788D7-4D04-42E5-A5E4-4DD2183FA356@gmail.com> Message-ID: <2c99c46e0710011528o34edd206ua44e2c888d09ab5d@mail.gmail.com> Sticking it into indra.l doesn't work. The XCODE_VERSION_ACTUAL is undefined here, and thus YACC_GENERATES_HPP is not defined. On 10/1/07, Argent Stonecutter wrote: > > On 01-Oct-2007, at 15:49, Michael Miller wrote: > > "Some include file"? What do you suggest? > > I suggest none. For now, just stick it in indra.l. What file it > finally goes into is Linden Policy. > > > _______________________________________________ > 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/20071001/870a41f6/attachment.htm From secret.argent at gmail.com Mon Oct 1 15:47:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 15:47:11 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> On 01-Oct-2007, at 16:56, David Kaprielian (Sabin) wrote: > We understand your concerns of lost viewer functionality. What about the concerns regarding browser security? > Thus we are focusing on converting the current login screen to an > embedded web login. What do you mean by "an embedded web login"? Do you mean using the internal web browser to render a web page? If so, you absolutely need to make HTTP proxies work. From secret.argent at gmail.com Mon Oct 1 16:12:10 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 16:12:14 2007 Subject: [sldev] Build errors(in XCode 2.5) with indra.y.h In-Reply-To: <2c99c46e0710011528o34edd206ua44e2c888d09ab5d@mail.gmail.com> References: <2c99c46e0709300750i7129ad69p22372d2f059ac867@mail.gmail.com> <2c99c46e0709301739l7bbeef7bk3ef7cc11ac4c1c74@mail.gmail.com> <05C18D31-CBEA-4FFF-BB8F-2C1F135679E1@mm.st> <2c99c46e0710011320k21dd4842wf603cd4d4c62bd3e@mail.gmail.com> <2c99c46e0710011347g3642107av8297efadcd5b316f@mail.gmail.com> <2c99c46e0710011349m6c9bb1g9d18c5f4cf27bd7f@mail.gmail.com> <4AF788D7-4D04-42E5-A5E4-4DD2183FA356@gmail.com> <2c99c46e0710011528o34edd206ua44e2c888d09ab5d@mail.gmail.com> Message-ID: <719307C1-64A8-4AA3-8B98-9481EA42CC78@gmail.com> On 01-Oct-2007, at 17:28, Michael Miller wrote: > Sticking it into indra.l doesn't work. Any problem you're having isn't anything to do with where it's stuck. > The XCODE_VERSION_ACTUAL is undefined here, and thus > YACC_GENERATES_HPP is not defined. You shouldn't need the XCODE_VERSION_ACTUAL. It should be getting YACC_GENERATES_HPP from the availability macros file having MAC_OS_X_VERSION_10_5 defined. If that's not the case, then to get XCODE_VERSION_ACTUAL in you need to go into the project: Project->Edit Project Settings Build tab Collection: Preprocessing Setting: Preprocessor Macros Edit, and add -DXCODE_VERSION_ACTUAL=$(XCODE_VERSION_ACTUAL) From ettore_pasquini at 3dconnexion.com Mon Oct 1 16:57:10 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Mon Oct 1 16:57:12 2007 Subject: [sldev] [VWR] [PATCH] Flycam support for Mac OS X In-Reply-To: <94b4a6520709281816s7fd4d801jd9e16c1ba0adf37e@mail.gmail.com> Message-ID: On 9/28/07 6:16 PM, "Michael Verdi" wrote: > On 9/28/07, Boroondas Gupte wrote: >> I'd do a test compile before applying any patches, so you know if it's >> working. >> > > I did that and it worked. I was able to log into SL and everything. (I > do machinima - I've never compiled anything before) > >> Then apply the patch ... >> https://wiki.secondlife.com/wiki/Submitting_code#Applying_patches_to_your_sou >> rce >> (I the case of VWR-2516, it might be somewhat more complicated, consult >> the README within the .zip-Archive) >> ... and recompile. >> > > This is where I run into trouble. I read though those instructions on > the wiki and in the patch's readme but I'm just not clear about what > to do. The wiki shows commands like: > c:\cygwin\bin\patch -p 0 -i changes.patch but I'm on Mac. > > Again, if anyone can help me figure this out I'd really appreciate it. Sorry Michael, I just saw your msg. Assuming you have your linden folder somewhere like /Users/michael/secondlife/linden then, applying patches on OS X is pretty much like any average Un*x machine: $ cd /Users/michael/secondlife $ patch -p0 < ./patches/ll-flycam-osx.patch Now, my patch relies on a library. The zip file includes Windoze + Mac OS X builds and the header file of the library (source is included too if you care) relatively placed in a linden folder. You just have to copy the linden folder included in the zip to your SL root: cp -R /linden /Users/michael/secondlife Finally, add the library binary you just copied to Xcode (newview target) Then rebuild. Ettore Ps. I used the 1.18.3.5 branch from svn. From michael at michaelverdi.com Mon Oct 1 17:42:09 2007 From: michael at michaelverdi.com (Michael Verdi) Date: Mon Oct 1 17:42:12 2007 Subject: [sldev] [VWR] [PATCH] Flycam support for Mac OS X In-Reply-To: References: <94b4a6520709281816s7fd4d801jd9e16c1ba0adf37e@mail.gmail.com> Message-ID: <94b4a6520710011742q4540bb8pc0d7234f7e6e14a4@mail.gmail.com> On 10/1/07, Ettore Pasquini wrote: > > Finally, add the library binary you just copied to Xcode (newview target) > > Then rebuild. Hi Ettore, Thanks for getting back to me. I think I've got it right up to that last step. How do I add the library binary to Xcode? This is my first time doing anything like this. Thanks, Michael From ryan at ngigroup.com Mon Oct 1 18:03:14 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 18:03:25 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4700C432.4060202@wsu.edu> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <4700C432.4060202@wsu.edu> Message-ID: <1191286994.3045.7.camel@localhost.localdomain> On Mon, 2007-10-01 at 02:56 -0700, John Hurliman wrote: > Ryan McDougall wrote: > > Say that unless the viewer distributor places a digital signature on a > > LL server along with the name of the downloader's name, LL will pop up a > > warning that the viewer is not known to LL and may be adulterated. > > As long as the adulterated viewer behaves and displays this warning to > the user, right? Rez and in world object with a warning texture? Have the warning printed on the LL website? > ... Oooh, dramatic pause. ;) > > A users computer is acting as a proxy for the human to interact with > other systems, and to do this there is an implicit trust that the users > computer is accurately representing the user. In the current model of > personal computers and the Internet this is a fundamental law, and no > clever warning message or DRM system or UNIX permission model will ever > change that law unless you change the model (ala Trusted Computing, > which removes the implicit trust between the PC and the user). No, but there is such a thing as cryptosystems. They are a fruitful area of research by people smarter than you and I. A system that works mostly is better than nothing. Don't confuse DRM with crypto. DRM is a system of not trusting the user with their own computer, and often involves the use of crypto. You'll not what I'm advocating is using a crypto system to establish _Identity_, not trust. In crypto research you start off always by assuming you cannot trust anything. This is not easily confused with "Trusted Computing (tm)". Cheers, From ryan at ngigroup.com Mon Oct 1 18:09:04 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 18:09:06 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> Message-ID: <1191287344.3045.12.camel@localhost.localdomain> On Mon, 2007-10-01 at 08:36 -0500, Argent Stonecutter wrote: > On 01-Oct-2007, at 04:19, Ryan McDougall wrote: > > Of course this brings us back to the original use case, an adulterated > > client viewer source (where once you access, the game is up no matter > > what). > > The solution is to not worry about that case, because unless you're > using an Orange Book class B trusted computer system with mandatory > access control at every level (and you'd have to port SL to it first, > because it's unlikely to run on one as is), it doesn't matter whether > you're using the official viewer or a third party viewer... as soon > as you use any software other than that distributed by the OS vendor > or Linden Labs the game is up no matter what. Most linux distro's ship SELinux enabled. I dont know if that technically "orange book", but its a sight better the old-fashioned naive UNIX you describe. If MS refuses to ship a similar solution its really beyond the scope of this discussion. While youre definitely right, there is more than one way to attack a crypto binary from a compromised SL viewer, the point is, as I said, the problem isnt necessarily "solved" so much as it reduces to a problem of OS or crypt-system security, which at the very least takes it off our plate. This, IMO, was LL intention in trying to offload the work to Mozilla -- not because Moz is leet security, but because its something for Mozilla et al to worry about. Cheers, From ryan at ngigroup.com Mon Oct 1 18:17:48 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 18:17:49 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> Message-ID: <1191287868.3045.20.camel@localhost.localdomain> On Mon, 2007-10-01 at 08:36 -0500, Argent Stonecutter wrote: > On 01-Oct-2007, at 04:19, Ryan McDougall wrote: Sorry this should have been one mail... > The solution is to not worry about that case I think this discussion is suffering from a serious lack of clarification on exactly what case we are trying to fix. I'd love to hear from Sabin what he thinks of the discussion, and what use cases he is after. > is legit. You go to J Random User's public website, and if it's > crocked, Linden Labs can subpoena his identity from the ISP and lay > down a legal pimpsmack. Thats exactly why my second solution, which no one seems to be commenting on, is all about taking the burden off the user with all this OpenID, custom URL handlers, SSL certs rot -- where the complexity and thus chance of failure is high, and go to certifying the _Identity_ of the binary provider (so LL can sue, as you state). Its not hard, it covers the case well enough to make a difference, and is easy enough to do in a way that makes things fair and open to any potential viewer distributor. Cheers, From tateru.nino at gmail.com Mon Oct 1 18:41:44 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Oct 1 18:41:51 2007 Subject: Goals for viewer authentication (was: Re: [sldev] Re: Viewer Auth Feedback) In-Reply-To: <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> Message-ID: <4701A1D8.7060808@gmail.com> One of the things about the proposed viewer authentication that I'm hazy on is Linden Lab's actual _goals_ for the new system. Most of what I've seen is assumption of goals, or allusion to goals. It occured to be today, reading through the viewer critique that a lot of the goals seem to be the ones we _assume_ Linden Lab to have for the system. What, exactly is the bulleted list of goals that a change to the authentication system is to meet? I mean, we can criticize the system generally - but we can't necessarily propose one that is more acceptable to Linden Lab unless we're sure of their acceptance criteria, no? Otherwise we're talking in circles hoping to stumble on something that's acceptable by happy accident. -- Tateru Nino http://dwellonit.blogspot.com/ From dzonatas at dzonux.net Mon Oct 1 19:01:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 1 18:59:35 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191287868.3045.20.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> Message-ID: <4701A67C.4080800@dzonux.net> Ryan McDougall wrote: > The solution is to not worry about that case > > > I think this discussion is suffering from a serious lack of > clarification on exactly what case we are trying to fix. I'd love to > hear from Sabin what he thinks of the discussion, and what use cases he > is after. This is where smartness is not better at experience with security. Some one could be a complete genius at crypto systems, but it doesn't do one bit of good not to know what affects of lack of security can do and how it has been done. Most cases, it is not something the experienced (with some decent common sense) really want to share and explain in complete detail. What has been requested, or revealed out of fear by the public general, is the need to supply a password each and every time one enters the SL world. They've shown how easy that is to exploit. Okay, so simple solution: drop the password entirely upon login. The question then becomes how do we validate identity after that step. Simple solution: why worry about it. Perhaps the user just wants to browse the virtual world just like anybody can browse the web. Does that mean they get complete access to browse the entire world? Again... simple solution... no... require access verification at that time when it is actually needed. It is not really needed just to get in the world. When it is actually needed is when we should augment security. Flame away! -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/ccfd03d8/attachment.htm From odysseus654 at gmail.com Mon Oct 1 19:25:11 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Mon Oct 1 19:25:14 2007 Subject: Goals for viewer authentication (was: Re: [sldev] Re: Viewer Auth Feedback) In-Reply-To: <4701A1D8.7060808@gmail.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> Message-ID: <1674f6c70710011925i66f7872fu69e5fa04518f1fa8@mail.gmail.com> >From what i'm hearing, I'm guessing that the purpose of this proposal was to place all back-end authentication logic under the umbrella of a single "login management" application. After this is done, they can create something like the Risk API to track down and rate potentially fraudulent user logins. I doubt that they need to have everything go through the SecondLife.com website in order for this to work though, although it makes it easier for them to develop. On 10/1/07, David Kaprielian (Sabin) wrote: > > It looks like there are a lot of > questions surrounding why we're working on this project. Initially, our > goal was to consolidate our authentication implementation in order to > support back-end anti-fraud work. This remains the priority! We > understand your concerns of lost viewer functionality. Thus we are > focusing on converting the current login screen to an embedded web > login. This supports our back-end anti-fraud work and allows it to > function without requiring you to login via a web page. We're working > on putting out a beta with the new functionality that you can try out > yourself. Until then, we'll continue to participate in this ongoing > discussion. Thank you! > > ~Dave > On 10/1/07, Tateru Nino wrote: > > One of the things about the proposed viewer authentication that I'm hazy > on is Linden Lab's actual _goals_ for the new system. Most of what I've > seen is assumption of goals, or allusion to goals. It occured to be > today, reading through the viewer critique that a lot of the goals seem > to be the ones we _assume_ Linden Lab to have for the system. > > What, exactly is the bulleted list of goals that a change to the > authentication system is to meet? I mean, we can criticize the system > generally - but we can't necessarily propose one that is more acceptable > to Linden Lab unless we're sure of their acceptance criteria, no? > Otherwise we're talking in circles hoping to stumble on something that's > acceptable by happy accident. > > -- > Tateru Nino > http://dwellonit.blogspot.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/20071001/83675026/attachment.htm From bbyer at mm.st Mon Oct 1 19:35:52 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Oct 1 19:35:58 2007 Subject: [sldev] [VWR] Crash Reports In-Reply-To: <46FA7C94.4010006@blueflash.cc> References: <46FA7C94.4010006@blueflash.cc> Message-ID: On Sep 26, 2007, at 8:36 AM, Nicholaz Beresford wrote: > > If possible I'd like to see an updated version of the > current crashers (top crashes), only 1.18.3-RC crashes if > possible. Here's what we're seeing on the Mac, at least, for whatever identifies itself as 1.18.3.5: (The first three have different stack traces but are probably the same problem) Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00989485 operator*(LLVector3 const&, LLQuaternion const&) + 21 1 com.secondlife.indra.viewer 0x004ef5bc LLSelectMgr::saveSelectedObjectTransform(e_action_type) + 1016 2 com.secondlife.indra.viewer 0x00505554 LLSelectMgr::selectObjectAndFamily(LLViewerObject*, int) + 310 3 com.secondlife.indra.viewer 0x0012ac9e LLViewerObjectList::processUpdateCore(LLViewerObject*, void**, unsigned, e_object_update_type, LLDataPacker*, int) + 256 4 com.secondlife.indra.viewer 0x0012e939 LLViewerObjectList::processObjectUpdate(LLMessageSystem*, void**, e_object_update_type, bool, bool) + 1249 5 com.secondlife.indra.viewer 0x001538fd process_object_update(LLMessageSystem*, void**) + 85 6 com.secondlife.indra.viewer 0x00933111 LLTemplateMessageReader::decodeData(unsigned char const*, LLHost const&) + 1719 7 com.secondlife.indra.viewer 0x009ca69b LLMessageSystem::checkMessages(long long) + 1953 8 com.secondlife.indra.viewer 0x009cb397 LLMessageSystem::checkAllMessages(long long, LLPumpIO*) + 33 9 com.secondlife.indra.viewer 0x005294de idle_network() + 202 10 com.secondlife.indra.viewer 0x0052e4bb idle() + 801 11 com.secondlife.indra.viewer 0x005345cd main_loop() + 505 12 com.secondlife.indra.viewer 0x0053bf96 main + 11666 13 com.secondlife.indra.viewer 0x00002792 _start + 216 14 com.secondlife.indra.viewer 0x000026b9 start + 41 Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00989485 operator*(LLVector3 const&, LLQuaternion const&) + 21 1 com.secondlife.indra.viewer 0x004ef5bc LLSelectMgr::saveSelectedObjectTransform(e_action_type) + 1016 2 com.secondlife.indra.viewer 0x00505554 LLSelectMgr::selectObjectAndFamily(LLViewerObject*, int) + 310 3 com.secondlife.indra.viewer 0x0067e537 LLToolSelect::handleObjectSelection(LLViewerObject*, unsigned, int, int) + 279 4 com.secondlife.indra.viewer 0x000149f9 LLToolPie::pickAndShowMenu(int, int, unsigned, int) + 1115 5 com.secondlife.indra.viewer 0x00015bb0 LLToolPie::rightMouseCallback(int, int, unsigned) + 48 6 com.secondlife.indra.viewer 0x000df462 LLViewerWindow::performPick() + 2078 7 com.secondlife.indra.viewer 0x005a12bb display(int, float, int) + 411 8 com.secondlife.indra.viewer 0x00534a94 main_loop() + 1728 9 com.secondlife.indra.viewer 0x0053bf96 main + 11666 10 com.secondlife.indra.viewer 0x00002792 _start + 216 11 com.secondlife.indra.viewer 0x000026b9 start + 41 Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00989485 operator*(LLVector3 const&, LLQuaternion const&) + 21 1 com.secondlife.indra.viewer 0x004ef5bc LLSelectMgr::saveSelectedObjectTransform(e_action_type) + 1016 2 com.secondlife.indra.viewer 0x00505554 LLSelectMgr::selectObjectAndFamily(LLViewerObject*, int) + 310 3 com.secondlife.indra.viewer 0x0012ac9e LLViewerObjectList::processUpdateCore(LLViewerObject*, void**, unsigned, e_object_update_type, LLDataPacker*, int) + 256 4 com.secondlife.indra.viewer 0x0012e637 LLViewerObjectList::processObjectUpdate(LLMessageSystem*, void**, e_object_update_type, bool, bool) + 479 5 com.secondlife.indra.viewer 0x0012f104 LLViewerObjectList::processCompressedObjectUpdate(LLMessageSystem*, void**, e_object_update_type) + 54 6 com.secondlife.indra.viewer 0x00153965 process_compressed_object_update(LLMessageSystem*, void**) + 69 7 com.secondlife.indra.viewer 0x00933111 LLTemplateMessageReader::decodeData(unsigned char const*, LLHost const&) + 1719 8 com.secondlife.indra.viewer 0x009ca69b LLMessageSystem::checkMessages(long long) + 1953 9 com.secondlife.indra.viewer 0x009cb397 LLMessageSystem::checkAllMessages(long long, LLPumpIO*) + 33 10 com.secondlife.indra.viewer 0x005294de idle_network() + 202 11 com.secondlife.indra.viewer 0x0052e4bb idle() + 801 12 com.secondlife.indra.viewer 0x005345cd main_loop() + 505 13 com.secondlife.indra.viewer 0x0053bf96 main + 11666 14 com.secondlife.indra.viewer 0x00002792 _start + 216 15 com.secondlife.indra.viewer 0x000026b9 start + 41 etc. Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 <<00000000>> 0x00000000 0 + 0 1 com.secondlife.indra.viewer 0x00122860 LLViewerObject::getBoundingBoxAgent() const + 416 2 com.secondlife.indra.viewer 0x00096a10 LLVOAvatar::getHUDBBox() + 200 3 com.secondlife.indra.viewer 0x0053f864 setup_hud_matrices(int) + 232 4 com.secondlife.indra.viewer 0x00544364 display(int, float, int) + 5692 5 com.secondlife.indra.viewer 0x004dd010 main_loop() + 1460 6 com.secondlife.indra.viewer 0x004e6938 main + 21908 7 com.secondlife.indra.viewer 0x000032dc _start + 760 8 com.secondlife.indra.viewer 0x00002fe0 start + 48 Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x0097960f LLError::crashAndLoop(std::basic_string, std::allocator > const&) + 3 1 com.secondlife.indra.viewer 0x0097bfec LLError::Log::flush(std::basic_ostringstream, std::allocator >*, LLError::CallSite const&) + 678 2 com.secondlife.indra.viewer 0x0031bdf4 LLAgent::parseTeleportMessages(LLStringBase const&) + 256 3 com.secondlife.indra.viewer 0x0053b81a main + 9750 4 com.secondlife.indra.viewer 0x00002792 _start + 216 5 com.secondlife.indra.viewer 0x000026b9 start + 41 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xff00021c Thread 0 Crashed: 0 libSystem.B.dylib 0x90002f26 szone_malloc + 308 1 libSystem.B.dylib 0x90002b0f malloc + 597 2 libstdc++.6.dylib 0x90b4e5b3 operator new(unsigned long) + 35 3 com.secondlife.indra.viewer 0x00cf173f std::_Rb_tree, std::less, std::allocator >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, LLViewerImage* const&) + 27 4 com.secondlife.indra.viewer 0x00cf1826 std::_Rb_tree, std::less, std::allocator >::insert_unique(LLViewerImage* const&) + 150 5 com.secondlife.indra.viewer 0x002b21a9 LLViewerImageList::updateImagesFetchTextures(float) + 215 6 com.secondlife.indra.viewer 0x002b9e17 LLViewerImageList::updateImages(float) + 251 7 com.secondlife.indra.viewer 0x0052ebb9 idle() + 2591 8 com.secondlife.indra.viewer 0x005345cd main_loop() + 505 9 com.secondlife.indra.viewer 0x0053bf96 main + 11666 10 com.secondlife.indra.viewer 0x00002792 _start + 216 11 com.secondlife.indra.viewer 0x000026b9 start + 41 PID: 843 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00d86a36 std::_Rb_tree >, std::_Select1st > >, std::less, std::allocator > > >::find(LLUUID const&) + 12 1 com.secondlife.indra.viewer 0x00945a6a LLSpeakerMgr::findSpeaker(LLUUID const&) + 32 2 com.secondlife.indra.viewer 0x009479b5 LLSpeakerMgr::speakerChatted(LLUUID const&) + 33 3 com.secondlife.indra.viewer 0x0050ea4a LLFloaterIMPanel::addHistoryLine(LLUUID const&, std::basic_string, std::allocator > const&, LLColor4 const&, bool) + 62 4 com.secondlife.indra.viewer 0x008b275c LLIMMgr::addMessage(LLUUID const&, LLUUID const&, char const*, char const*, char const*, EInstantMessage, unsigned, LLUUID const&, LLVector3 const&) + 418 5 com.secondlife.indra.viewer 0x008b562e LLIMMgr::addSystemMessage(LLUUID const&, LLStringBase const&, std::map, std::allocator >, std::basic_string, std::allocator >, std::less, std::allocator > >, std::allocator, std::allocator > const, std::basic_string, std::allocator > > > > const&) + 748 6 com.secondlife.indra.viewer 0x0050f797 LLVoiceChannel::setState(LLVoiceChannel::e_voice_channel_state) + 327 7 com.secondlife.indra.viewer 0x0051299a LLVoiceChannelGroup::deactivate() + 116 8 com.secondlife.indra.viewer 0x0050cb6c LLFloaterIMPanel::~LLFloaterIMPanel [in-charge deleting]() + 80 9 com.secondlife.indra.viewer 0x006ca492 LLView::~LLView [not-in- charge]() + 332 10 com.secondlife.indra.viewer 0x006c06fa LLUICtrl::~LLUICtrl [not-in-charge]() + 70 11 com.secondlife.indra.viewer 0x00719316 LLPanel::~LLPanel [not- in-charge]() + 376 12 com.secondlife.indra.viewer 0x00757953 LLTabContainer::~LLTabContainer [in-charge deleting]() + 45 13 com.secondlife.indra.viewer 0x006ca492 LLView::~LLView [not-in- charge]() + 332 14 com.secondlife.indra.viewer 0x006c06fa LLUICtrl::~LLUICtrl [not-in-charge]() + 70 15 com.secondlife.indra.viewer 0x00719316 LLPanel::~LLPanel [not- in-charge]() + 376 16 com.secondlife.indra.viewer 0x006fe22c LLFloater::~LLFloater [not-in-charge]() + 390 17 com.secondlife.indra.viewer 0x0095844a LLFloaterChatterBox::~LLFloaterChatterBox [in-charge deleting]() + 94 18 com.secondlife.indra.viewer 0x006ca492 LLView::~LLView [not-in- charge]() + 332 19 com.secondlife.indra.viewer 0x006c06fa LLUICtrl::~LLUICtrl [not-in-charge]() + 70 20 com.secondlife.indra.viewer 0x00d4b67b LLFloaterView::~LLFloaterView [in-charge deleting]() + 45 21 com.secondlife.indra.viewer 0x006ca492 LLView::~LLView [not-in- charge]() + 332 22 com.secondlife.indra.viewer 0x00d8021f LLRootView::~LLRootView [in-charge deleting]() + 45 23 com.secondlife.indra.viewer 0x000f012e LLViewerWindow::~LLViewerWindow [in-charge deleting]() + 236 24 com.secondlife.indra.viewer 0x00537ad0 cleanup_app() + 1344 25 com.secondlife.indra.viewer 0x0053bf9b main + 11671 26 com.secondlife.indra.viewer 0x00002792 _start + 216 27 com.secondlife.indra.viewer 0x000026b9 start + 41 This last one looks like infinite recursion: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbf7fffa0 Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00cd98ab LLOctreeState::insert(LLDrawable*) + 159 1 com.secondlife.indra.viewer 0x00cd5840 LLTreeNode::insert(LLDrawable*) + 30 2 com.secondlife.indra.viewer 0x00cd9acf LLOctreeState::insert(LLDrawable*) + 707 3 com.secondlife.indra.viewer 0x00cd5840 LLTreeNode::insert(LLDrawable*) + 30 4 com.secondlife.indra.viewer 0x00cd9acf LLOctreeState::insert(LLDrawable*) + 707 5 com.secondlife.indra.viewer 0x00cd5840 LLTreeNode::insert(LLDrawable*) + 30 6 com.secondlife.indra.viewer 0x00cd9acf LLOctreeState::insert(LLDrawable*) + 707 7 com.secondlife.indra.viewer 0x00cd5840 LLTreeNode::insert(LLDrawable*) + 30 8 com.secondlife.indra.viewer 0x00cd9acf LLOctreeState::insert(LLDrawable*) + 707 9 com.secondlife.indra.viewer 0x00cd5840 LLTreeNode::insert(LLDrawable*) + 30 [....] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/dc324625/attachment-0001.htm From secret.argent at gmail.com Mon Oct 1 19:38:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 19:38:26 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191287344.3045.12.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> Message-ID: <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> On 01-Oct-2007, at 20:09, Ryan McDougall wrote: > Most linux distro's ship SELinux enabled. That's nice. Look, I've been working with "better than C2" UNIX for decades, and none of them implement the kind of mandatory access control at every level that I'm talking about here. The closer they get the more of a pain in the ass they are. Maybe one percent of the people even running SL on Linux are going to bother, and they're the people who least need it, because Linux users (let alone paranoid Linux users) aren't the kind of people likely to get phished in the first place. > While youre definitely right, there is more than one way to attack a > crypto binary from a compromised SL viewer, If you have a compromised SL viewer you don't have to attack anything. You already have the golden ring, you've won. The goal here is not protecting the cryptosystem, it's protecting the viewer. The big sloppy viewer that's using a couple of dozen big sloppy shared libraries. Once the bad guy has ANY compromised software on your computer, the viewer is dead meat. So that's the trick. How do you protect the viewer? Well, one, you don't require people to run any other big sloppy GUI applications to use it. Like, you know, a browser? So... This doesn't solve the problem that's important to solve, it just makes it worse, by bringing in a previously unnecessary component... without actually making the viewer itself any more resistant to compromise. You haven't put up another door in front of the valuables, you've knocked a hole in the wall NEXT to the door that's already there, and put a really secure door up in its place. From secret.argent at gmail.com Mon Oct 1 19:45:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 19:46:00 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191287868.3045.20.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> Message-ID: <8C1C6CD9-94CB-4F49-95C4-2CFAF8D75E45@gmail.com> On 01-Oct-2007, at 20:17, Ryan McDougall wrote: > Thats exactly why my second solution, which no one seems to be > commenting on, is all about taking the burden off the user with all > this > OpenID, custom URL handlers, SSL certs rot -- where the complexity and > thus chance of failure is high, and go to certifying the _Identity_ of > the binary provider (so LL can sue, as you state). You're not making it that much harder for a crook to hide... because it's pretty hard for the kind of crook you're talking about to begin with... and doing nothing to deal with scenarios that are actually likely to happen. And at the same time you're requiring me, if I want to download the source and build my own copy of the SL client to connect to SL, to go through certification rigamarole every time I do a test run? From secret.argent at gmail.com Mon Oct 1 19:51:46 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 1 19:51:49 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4701A67C.4080800@dzonux.net> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <4701A67C.4080800@dzonux.net> Message-ID: <9CCDC11D-4141-407E-98DB-4DC73596C6FA@gmail.com> I would just like to note that Dzonatas comments and proposed solution have nothing to do with my comment "The solution is to not worry about that case" that he appears to be explaining here. The recent URL vulnerability had little to do with the dangers of using passwords. It was all about Windows lack of an out-of-band mechanism for separating components of a command line, and about the implementation of the authentication from the server. There are plenty of ways to use a secret to authenticate yourself that don't involve passing a replayable secret over the network, encrypted or not. From bbyer at mm.st Mon Oct 1 19:52:43 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Oct 1 19:52:46 2007 Subject: [sldev] [PROTOCOL] What is AgentMovementComplete.SimData.ChannelVersion? In-Reply-To: <47013793.5030300@wsu.edu> References: <47013793.5030300@wsu.edu> Message-ID: <70FCC85A-C8A8-4E0C-B938-C650D1998AC4@mm.st> Lemme guess: Sim version number, to support HetGrid? -b On Oct 1, 2007, at 11:08 AM, John Hurliman wrote: > http://libsecondlife.org/template/release/diff-1.18.3.5.txt > > Anyone? > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Mon Oct 1 19:57:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 1 19:55:11 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191286994.3045.7.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <4700C432.4060202@wsu.edu> <1191286994.3045.7.camel@localhost.localdomain> Message-ID: <4701B385.8000507@dzonux.net> Ryan McDougall wrote: > On Mon, 2007-10-01 at 02:56 -0700, John Hurliman wrote: > >> Ryan McDougall wrote: >> >>> Say that unless the viewer distributor places a digital signature on a >>> LL server along with the name of the downloader's name, LL will pop up a >>> warning that the viewer is not known to LL and may be adulterated. >>> >> As long as the adulterated viewer behaves and displays this warning to >> the user, right? >> > > Rez and in world object with a warning texture? Have the warning printed > on the LL website? > None of that would be required if, instead of an in-world prim with a warning, the in-world prim actually displayed the login prompt. (Someone wanted HTML on a prim?) -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/886d6a2d/attachment.htm From dzonatas at dzonux.net Mon Oct 1 20:00:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 1 19:58:17 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <8C1C6CD9-94CB-4F49-95C4-2CFAF8D75E45@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <8C1C6CD9-94CB-4F49-95C4-2CFAF8D75E45@gmail.com> Message-ID: <4701B441.8010105@dzonux.net> Argent Stonecutter wrote: > And at the same time you're requiring me, if I want to download the > source and build my own copy of the SL client to connect to SL, to go > through certification rigamarole every time I do a test run? No. =) This is where you would login to something like OpenID to sign-off on the version you made. (and.. lol... possibly upload it for ugly DRM checks and what not) -- Power to Change the Void From ryan at ngigroup.com Mon Oct 1 20:05:00 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 20:05:02 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> Message-ID: <1191294300.3045.42.camel@localhost.localdomain> On Mon, 2007-10-01 at 21:38 -0500, Argent Stonecutter wrote: > > If you have a compromised SL viewer you don't have to attack > anything. You already have the golden ring, you've won. Actually I thought the goal was to protect the user's valuables, specifically L$, but also his in game assets. > And at the same time you're requiring me, if I want > to download the source and build my own copy of the SL client to > connect to SL, to go through certification rigamarole every time I do > a test run? Only if you care if your users get told that they may be running an unknown viewer. If you care and have a large user base, you download GPG and create a key, then publish it -- that simple. All the linux distros' package security currently works like this. If you run an unsigned RPM, you get a warning, caveat emptor. Cheers, From tateru.nino at gmail.com Mon Oct 1 20:17:58 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Oct 1 20:18:07 2007 Subject: [sldev] Re: Goals for viewer authentication In-Reply-To: <1674f6c70710011925i66f7872fu69e5fa04518f1fa8@mail.gmail.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> <1674f6c70710011925i66f7872fu69e5fa04518f1fa8@mail.gmail.com> Message-ID: <4701B866.7010709@gmail.com> A lot depends on the requirements then. One centralized design might support it, and another might impede it. The devil, as they say, is in the details. Erik Anderson wrote: > >From what i'm hearing, I'm guessing that the purpose of this proposal > was to place all back-end authentication logic under the umbrella of a > single "login management" application. After this is done, they can > create something like the Risk API to track down and rate potentially > fraudulent user logins. I doubt that they need to have everything go > through the SecondLife.com website in order for this to work though, > although it makes it easier for them to develop. > > > On 10/1/07, *David Kaprielian (Sabin)* < sabin@lindenlab.com > > wrote: > > It looks like there are a lot of > questions surrounding why we're working on this > project. Initially, our > goal was to consolidate our authentication implementation in order to > support back-end anti-fraud work. This remains the priority! We > understand your concerns of lost viewer functionality. Thus we are > focusing on converting the current login screen to an embedded web > login. This supports our back-end anti-fraud work and allows it to > function without requiring you to login via a web page. We're > working > on putting out a beta with the new functionality that you can try out > yourself. Until then, we'll continue to participate in this ongoing > discussion. Thank you! > > ~Dave > > > > > On 10/1/07, *Tateru Nino* > wrote: > > One of the things about the proposed viewer authentication that > I'm hazy > on is Linden Lab's actual _goals_ for the new system. Most of what > I've > seen is assumption of goals, or allusion to goals. It occured to be > today, reading through the viewer critique that a lot of the goals > seem > to be the ones we _assume_ Linden Lab to have for the system. > > What, exactly is the bulleted list of goals that a change to the > authentication system is to meet? I mean, we can criticize the system > generally - but we can't necessarily propose one that is more > acceptable > to Linden Lab unless we're sure of their acceptance criteria, no? > Otherwise we're talking in circles hoping to stumble on something > that's > acceptable by happy accident. > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From ryan at ngigroup.com Mon Oct 1 20:18:50 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Mon Oct 1 20:18:56 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> Message-ID: <1191295130.3045.54.camel@localhost.localdomain> On Mon, 2007-10-01 at 21:38 -0500, Argent Stonecutter wrote: > > If you have a compromised SL viewer you don't have to attack > anything. You already have the golden ring, you've won. The goal here > is not protecting the cryptosystem, it's protecting the viewer. The > big sloppy viewer that's using a couple of dozen big sloppy shared > libraries. Once the bad guy has ANY compromised software on your > computer, the viewer is dead meat. In case I havent been clear: I assume that the issue here is allowing Open Sourced viewers, which could contain any kind of code, to connect to LL servers. I assume that the largest issue with a compromised viewer is that it allows a nefarious 3rd party to access your on-server assets. I propose that an out of process PKI library be used to transfer an temporary authorization token to the client viewer. Once the token has been handed to the viewer, then the viewer can do anything to the user's account. We rely on the server and the PKI system to only hand the token off when the Private Key, located on the user's machine, matches the Public Key stored on the LL server (given over SSL during registration). The security of the system would rely on the assumption that a compromised viewer cannot break the OS's security, and access the Private Key. This assumption is not rock solid, as we all know, but it does put the blame where it belongs, on the OS to provide a secure system. It is my belief that this is better than what I've heard so far. Also, this is not entirely unlike many other PKI systems in use, including the one my wife uses to work from home at one of the worlds largest investment banks. Cheers, From seg at haxxed.com Mon Oct 1 20:39:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 1 20:39:27 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <470136F0.8020802@gmail.com> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <470136F0.8020802@gmail.com> Message-ID: <1191296349.11151.29.camel@localhost> On Mon, 2007-10-01 at 19:05 +0100, Robin Cornelius wrote: > Well if the viewer would just build out of the box that would be a great > help the Main issues for me are:- > > http://jira.secondlife.com/browse/VWR-2488 > > and > > http://jira.secondlife.com/browse/VWR-1853 > > Its very close to just being able to do "scons DISTCC=no STANDALONE=yes > BTARGET=client ELFIO=no MOZLIB=no ARCH=x86_64 BUILD=releasefordownload" > > I think that's the only two issues stopping that and one of them is > AMD64 specific anyway, but still needs updating. If you're talking about VWR-1853, you're mixing up two issues. There may be install manifest problems on x86_64, but the inability to find system fonts to use out of the box affects all architectures. Note my RPM package just does a "release" build, with SConstruct patched to build as a "releasefordownload", basically to bypass the tarball building. It handles the install itself. So I'm not going to notice manifest problems. :) The "make" and "make install" stages should probably be separated, like every other build system on the planet does. (And "install to an FHS compliant tree" and the current "build a binary tarball" separated as well) scons really is a glorified make, not a full blown build system like autotools or cmake. ;P > I am sure there are others but VWR-2488 " Standalone build is almost, > but not quite there." might make a good umbrella for related issues as > it seems bang on topic. No, there's bigger issues than just building. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071001/ca7aacf0/attachment.pgp From gigstaggart at gmail.com Mon Oct 1 20:44:45 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Oct 1 20:44:44 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: <4701BEAD.4080606@gmail.com> David Kaprielian (Sabin) wrote: > understand your concerns of lost viewer functionality. Thus we are > focusing on converting the current login screen to an embedded web > login. If you do this, I sure hope you make llmozlib go from "nearly impossible to compile with the client code drops" to "slightly less than impossible". As far as I know, no one has actually gotten the client to compile with llmozlib on Linux. If they have, they haven't documented it on the wiki because we still don't have any instructions on how. -Jason From hud at zurich.ibm.com Mon Oct 1 08:48:09 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 1 21:28:20 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <46FFB774.3080001@dzonux.net> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> Message-ID: <470116B9.9050806@zurich.ibm.com> Argent Stonecutter wrote: [...] > > "What I need to know is... can this be handled entirely in the viewer > application, from start to finish, without involving any third parties > and without involving any applications other than the viewer at any > point (including web browsers, whether embedded in the viewer or > otherwise), including generating any certificates required using only > such authentication information that I am able to easily carry in my > head, even if SL's design doesn't work this way." it certainly would make much more sense than forcing a split login model on the users. and i don't see why it shouldn't work in the client. after all the browser can only do HTTPS? calls --- the client should be able to do the same. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Oct 1 08:56:53 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 1 21:28:21 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <47005697.50502@dzonux.net> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> Message-ID: <470118C5.20702@zurich.ibm.com> Dzonatas wrote: > [...] > > Instead of inviting people to groups, why not just send them an e-mail > with a certificate that allows them access to an SL group? Automation... > hmm, interesting...so we'd use OpenID to generate capabilities so to speak? -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From Anders at Arnholm.se Mon Oct 1 22:24:03 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Mon Oct 1 22:25:42 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <4701BEAD.4080606@gmail.com> References: <47016CFE.1060509@lindenlab.com> <4701BEAD.4080606@gmail.com> Message-ID: <1191302643.2055.2.camel@kitiara> On Mon, 2007-10-01 at 23:44 -0400, Jason Giglio wrote: > David Kaprielian (Sabin) wrote: > As far as I know, no one has actually gotten the client to compile with > llmozlib on Linux. If they have, they haven't documented it on the wiki > because we still don't have any instructions on how. If you mean making you own libmoz, sure hard, but using the script on the wiki i got "scons DISTCC=no BTARGET=client OPENSOURCE=no BUILD=releasefordownload CHANNEL=Release MOZLIB=Yes" as build command, for all i can see the libmoz is in the viewer. (Then i added Nicholaz pathces.) / Balp -- Anders Arnholm http://anders.arnholm.se/ Balp Allen -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From labrat.hb at gmail.com Mon Oct 1 22:56:06 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Oct 1 22:56:09 2007 Subject: [sldev] [PROPOSAL] Authentication Model Message-ID: The current authentication model is a common single factor authentication based on username / password. This method is not secure in that once those two pieces of information are in the hands of someone. They have complete access to your account. This information can be obtained through many different methods. This proposal is for a multi-factor authentication method to be added to the login system. This method should be easy for the end user without greatly affecting their current login experience. PROPOSAL: Each user should (at account creation, or after logging in to the system for the first time without this enabled) upload a personal image. This image should be something that they can easily identify from a group of images at login. When logging in the system should present a preset number of images that the user must select their personal image from. Upon presentation the images must have a randomly generated watermark of some kind, perhapse a simple captcha overlayed onto the image that must be typed in to continue the login process. The images must be modified at presentation to prevent identification of the image by MD5 or some other hash method. The system could allow for a personal image pool, and users could designate images as being available to the system image pool for display for other logins. DRAWBACKS: This excludes the possibility of using a text based browser or automated systems for logging in. An alternative multi-factor authentication would need to be available for these clients. The key to this method is insuring that one piece of the identification process is not in possesion of the client. It must be able to be presented to, and identified by the user, without allowing the client application or browser identify what that piece of identification is. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071001/6e469f64/attachment.htm From tateru.nino at gmail.com Tue Oct 2 00:26:59 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 2 00:27:07 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: References: Message-ID: <4701F2C3.4040606@gmail.com> Hmm. Just as a note, I'm not real good with captcha codes. It often takes me twenty or thirty attempts to correctly identify the characters by hand - due to the way I process visual information. Instead, I've got software that I use to access the screen buffer and read the codes for me, which gets them right nearly every time. Harold Brown wrote: > The current authentication model is a common single factor > authentication based on username / password. This method is not > secure in that once those two pieces of information are in the hands > of someone. They have complete access to your account. This > information can be obtained through many different methods. > > This proposal is for a multi-factor authentication method to be added > to the login system. This method should be easy for the end user > without greatly affecting their current login experience. > > > PROPOSAL: > Each user should (at account creation, or after logging in to the > system for the first time without this enabled) upload a personal > image. This image should be something that they can easily identify > from a group of images at login. When logging in the system should > present a preset number of images that the user must select their > personal image from. Upon presentation the images must have a > randomly generated watermark of some kind, perhapse a simple captcha > overlayed onto the image that must be typed in to continue the login > process. The images must be modified at presentation to prevent > identification of the image by MD5 or some other hash method. > > The system could allow for a personal image pool, and users could > designate images as being available to the system image pool for > display for other logins. > > DRAWBACKS: > > This excludes the possibility of using a text based browser or > automated systems for logging in. An alternative multi-factor > authentication would need to be available for these clients. > > > The key to this method is insuring that one piece of the > identification process is not in possesion of the client. It must be > able to be presented to, and identified by the user, without allowing > the client application or browser identify what that piece of > identification is. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From matthew.dowd at hotmail.co.uk Tue Oct 2 01:13:42 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:13:44 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191287868.3045.20.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> Message-ID: > I think this discussion is suffering from a serious lack of> clarification on exactly what case we are trying to fix. I'd love to> hear from Sabin what he thinks of the discussion, and what use cases he> is after. I'm also getting confused by the subject line too ;-) for me OpenID offers the following potentials (I meant to send a similar e-mail to the list yesterday but forgot to cc the list!): OpenID is *part* of the solution for allowing a single userid to be used for multiple services (both from LL and others) - if that was felt to be a desirable option. OpenID (and similar systems) are being used as the basis for brokered trust based identity verification systems which if adopted would provide a much more reliable mechanism for online verification than existing attempts whilst allowing the user fine grained control on what information is provided to which service. But OpenID per se does not attempt to address the various things being discussed such as viewer trust, anti-fraud etc. Matthew _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/165a0dfc/attachment.htm From labrat.hb at gmail.com Tue Oct 2 01:20:35 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Oct 2 01:20:37 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. Message-ID: As another factor in increased account security. Account owners should have the ability to see what IP's have successfully logged in to their account and those IP's that have made any attempts to log into their account. Along with this a method to Black, White or Greylist IP (specific or network ranges).... This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. IP's on the blacklist would not be able to log into the account at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/48ca7b18/attachment.htm From matthew.dowd at hotmail.co.uk Tue Oct 2 01:25:20 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:25:22 2007 Subject: Goals for viewer authentication (was: Re: [sldev] Re: Viewer Auth Feedback) In-Reply-To: <4701A1D8.7060808@gmail.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> Message-ID: > One of the things about the proposed viewer authentication that I'm hazy> on is Linden Lab's actual _goals_ for the new system. Most of what I've> seen is assumption of goals, or allusion to goals. It occured to be> today, reading through the viewer critique that a lot of the goals seem> to be the ones we _assume_ Linden Lab to have for the system. Indeed - and I've been wondering whether to edit the critique to make it clear that the Goals listed *are* what we *think* the goals/objectives are based on the original wiki page on some correspondence with LL. I thought it useful to be explicit in our assumptions (a) as it is clear to LL what these are, as they do colour our responses (b) to prompt LL into being more explicit in *what* they want to achieve rather than jumping straight into the *how* which is really the information we have at present. Matthew _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/b60d5bb3/attachment.htm From matthew.dowd at hotmail.co.uk Tue Oct 2 01:34:23 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:34:24 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: Message-ID: Mmmmm, greylisting could cause problems when the viewer crashes or otherwise drops the connection. I can easily make multiple logon attempts within 5 minutes which fail with the message "your account is still logging on". There was also one occasion when the viewer crashed twice just after log on, and it was only on the third attempt that I managed to get a connection which actually enabled me to do something! greylisting sounds a good idea but would require a much more stale viewer first. The log is a good idea - I'm less sure about the black/white/grey, as I would suspect that a sizeable fraction of the userbase will not have static or semi-static ips, and a far small fraction of the userbase would actually know what a static or semi-static ip address is (lot alone whether they have one). Matthew Date: Tue, 2 Oct 2007 01:20:35 -0700From: labrat.hb@gmail.comTo: sldev@lists.secondlife.comSubject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. As another factor in increased account security. Account owners should have the ability to see what IP's have successfully logged in to their account and those IP's that have made any attempts to log into their account. Along with this a method to Black, White or Greylist IP (specific or network ranges).... This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. IP's on the blacklist would not be able to log into the account at all. _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/7159f372/attachment.htm From jhurliman at wsu.edu Tue Oct 2 01:34:48 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 01:34:43 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: Message-ID: <470202A8.2000503@wsu.edu> Harold Brown wrote: > As another factor in increased account security. Account owners > should have the ability to see what IP's have successfully logged in > to their account and those IP's that have made any attempts to log > into their account. > > Along with this a method to Black, White or Greylist IP (specific or > network ranges).... This would allow someone with a static, or > semi-static IP to prevent client logons to their account unless they > appear on the Whitelist of approved IP's. Greylisting would allow one > login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all. > Do most web services provide this feature? Do your banks and credit cards and brokerage accounts give you this feature? None of mine do, and I'm curious why these measures are needed for Second Life but not to manage any other assets over the net. John Hurliman From matthew.dowd at hotmail.co.uk Tue Oct 2 01:36:01 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:36:02 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: I'm not clear why this consolidation could not be acheived by having a single backend webservice which did the authentication step, and which was then fronted by a GUI frontend for the client and a web front end for the websites? Matthew> Date: Mon, 1 Oct 2007 14:56:14 -0700> From: sabin@lindenlab.com> To: sldev@lists.secondlife.com> Subject: [sldev] Re: Viewer Auth Feedback> > Hello again SLDev! I asked for feedback and boy did I get feedback!> > We've been reading the e-mails and wiki critique page and it has sparked > a few ongoing internal discussions. It looks like there are a lot of > questions surrounding why we're working on this project. Initially, our > goal was to consolidate our authentication implementation in order to > support back-end anti-fraud work. This remains the priority! We > understand your concerns of lost viewer functionality. Thus we are > focusing on converting the current login screen to an embedded web > login. This supports our back-end anti-fraud work and allows it to > function without requiring you to login via a web page. We're working > on putting out a beta with the new functionality that you can try out > yourself. Until then, we'll continue to participate in this ongoing > discussion. Thank you!> > ~Dave> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/32cd4f43/attachment.htm From robin.cornelius at gmail.com Tue Oct 2 01:42:50 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Oct 2 01:42:53 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <1191296349.11151.29.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <470136F0.8020802@gmail.com> <1191296349.11151.29.camel@localhost> Message-ID: Hi Callum, On 10/2/07, Callum Lerwick wrote: > If you're talking about VWR-1853, you're mixing up two issues. There may > be install manifest problems on x86_64, but the inability to find system > fonts to use out of the box affects all architectures. Yes i was mixing two issues :-) my bad. Yes the fonts is perhapses the most annoying as you have to either patch the viewer and add your own fonts, or symlink away. > > Note my RPM package just does a "release" build, with SConstruct patched > to build as a "releasefordownload", basically to bypass the tarball > building. It handles the install itself. So I'm not going to notice > manifest problems. :) The "make" and "make install" stages should "> probably be separated, like every other build system on the planet does. > (And "install to an FHS compliant tree" and the current "build a binary > tarball" separated as well) Ok i see your point that the build system should work as *expected* and do things as we are all use to seeing not do its own thing and a "install" option that did the right thing would also be very nice. I have not got as far as using my own makefile, I was relying on the tarball building with all the correct contents then i was unpacking this to a deploy directory with a .deb control file, moving a few files around my hand and creating a deb that way. Have you posted your makefile anywhere or could you send me a copy, could be pretty handy for me building my debs. > > > I am sure there are others but VWR-2488 " Standalone build is almost, > > but not quite there." might make a good umbrella for related issues as > > it seems bang on topic. > > No, there's bigger issues than just building. :) > Point taken, I would just like to see the viewer build with out any source code patching as a minimum first step, with whatever build tool. ATM there are a few issues, the font one and "expat/expat.h" is not where it is expected to be (its just "expat.h"). Thats it for me but i am sure there are others So what would anyone say the next step would be, move to a different build system? Are you saying a full automake/autoconf setup to replace scons so that things build correctly on different arch's and even cross arch? and can install files into correct (FSH) locations etc. This would certainly make packaging easier. Are there any other blocking issues here as well? Robin From matthew.dowd at hotmail.co.uk Tue Oct 2 01:47:15 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:47:16 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: <470202A8.2000503@wsu.edu> References: <470202A8.2000503@wsu.edu> Message-ID: > Do most web services provide this feature? Do your banks and credit > cards and brokerage accounts give you this feature? None of mine do, and > I'm curious why these measures are needed for Second Life but not to > manage any other assets over the net. My bank displays the time date and ip of the last successful/unsuccesful logon - but doesn't do whitelisting etc. Matthew _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/4f3a3c9e/attachment.htm From labrat.hb at gmail.com Tue Oct 2 01:51:48 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Oct 2 01:51:51 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: <470202A8.2000503@wsu.edu> Message-ID: Banks and Credit card companies have insurance for fraud. On 10/2/07, John Hurliman wrote: > > Harold Brown wrote: > > As another factor in increased account security. Account owners > > should have the ability to see what IP's have successfully logged in > > to their account and those IP's that have made any attempts to log > > into their account. > > > > Along with this a method to Black, White or Greylist IP (specific or > > network ranges).... This would allow someone with a static, or > > semi-static IP to prevent client logons to their account unless they > > appear on the Whitelist of approved IP's. Greylisting would allow one > > login attempt every 5-10 minutes and could be used when traveling. > > IP's on the blacklist would not be able to log into the account at all. > > > > Do most web services provide this feature? Do your banks and credit > cards and brokerage accounts give you this feature? None of mine do, and > I'm curious why these measures are needed for Second Life but not to > manage any other assets over the net. > > John Hurliman > _______________________________________________ > 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/20071002/d92334ea/attachment.htm From jhurliman at wsu.edu Tue Oct 2 01:52:06 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 01:51:57 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: <470202A8.2000503@wsu.edu> Message-ID: <470206B6.6020108@wsu.edu> Matthew Dowd wrote: > > > Do most web services provide this feature? Do your banks and credit > > cards and brokerage accounts give you this feature? None of mine do, > and > > I'm curious why these measures are needed for Second Life but not to > > manage any other assets over the net. > > My bank displays the time date and ip of the last > successful/unsuccesful logon - but doesn't do whitelisting etc. > > Matthew That's because the first time someone setup a whitelist without having any idea what an IP address or dynamic IPs were and locked themselves out of the account the bank would have to pay someone in tech support to walk them through unlocking the account. If you are working on a technical solution to a problem and it requires end users to understand what an IP address, certificate, or public/private keypair are you should stop right there and start over again. John From matthew.dowd at hotmail.co.uk Tue Oct 2 01:55:54 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:55:57 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: > Initially, our > goal was to consolidate our authentication implementation in order to > support back-end anti-fraud work. I must confess that I'm still uncertain what this means - what are the features you need from a consolidation which your anti-fraud work needs? This is important to understand why you need the authentication in the viewer to be done via a web form as opposed to both the website and the viewer using the same backend webservice to do the authentication step! However, i've added consolidation as an objective (with a note that the goals and objectives in the critique are currently assumed or derived ones). I've added issues around llmozlib (e.g compilation problems under linux, proxy support etc.) are Cons for embedding the webform in the viewer I've added fronting a backend webservice in different ways as an alternative. I've also added Harold's logging of previous logon attempts and black/white/grey listing as *seperate* alternatives. Matthew _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/7e9f4091/attachment.htm From matthew.dowd at hotmail.co.uk Tue Oct 2 01:58:47 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 01:58:49 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: <470206B6.6020108@wsu.edu> References: <470202A8.2000503@wsu.edu> <470206B6.6020108@wsu.edu> Message-ID: > That's because the first time someone setup a whitelist without having > any idea what an IP address or dynamic IPs were and locked themselves > out of the account the bank would have to pay someone in tech support to > walk them through unlocking the account. If you are working on a > technical solution to a problem and it requires end users to understand > what an IP address, certificate, or public/private keypair are you > should stop right there and start over again. Agreed - see my original response to Harold's suggestion ;-) In the wiki, I've listed the black/white/grey list as an alternative but also the comment "How many people have a static or semi stati ip, or even know whether they have?" Matthew _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/0267a153/attachment.htm From tshephard at gmail.com Tue Oct 2 02:14:36 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Oct 2 02:14:38 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: Message-ID: <3b19a500710020214r51564345jcca36ff3bf93e33c@mail.gmail.com> This is a great idea. Some kind of highlighting when you've logged in via a different IP address would be very nice. I sure wish paypal and some other sites I used did this. On 10/2/07, Harold Brown wrote: > As another factor in increased account security. Account owners should have > the ability to see what IP's have successfully logged in to their account > and those IP's that have made any attempts to log into their account. > > Along with this a method to Black, White or Greylist IP (specific or network > ranges).... This would allow someone with a static, or semi-static IP to > prevent client logons to their account unless they appear on the Whitelist > of approved IP's. Greylisting would allow one login attempt every 5-10 > minutes and could be used when traveling. IP's on the blacklist would not > be able to log into the account at all. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From tshephard at gmail.com Tue Oct 2 02:17:18 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Oct 2 02:17:20 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: <470206B6.6020108@wsu.edu> References: <470202A8.2000503@wsu.edu> <470206B6.6020108@wsu.edu> Message-ID: <3b19a500710020217i1e3effb6x24dd2a1274f94620@mail.gmail.com> Paypal has an RSA token they provide. I guess we could do RSA token, but that seems a lot more involved than simply locking to an IP address. I know a lot of people who have oodles of L$ in their account would dearly dearly love this feature. On 10/2/07, John Hurliman wrote: > Matthew Dowd wrote: > > > > > Do most web services provide this feature? Do your banks and credit > > > cards and brokerage accounts give you this feature? None of mine do, > > and > > > I'm curious why these measures are needed for Second Life but not to > > > manage any other assets over the net. > > > > My bank displays the time date and ip of the last > > successful/unsuccesful logon - but doesn't do whitelisting etc. > > > > Matthew > > That's because the first time someone setup a whitelist without having > any idea what an IP address or dynamic IPs were and locked themselves > out of the account the bank would have to pay someone in tech support to > walk them through unlocking the account. If you are working on a > technical solution to a problem and it requires end users to understand > what an IP address, certificate, or public/private keypair are you > should stop right there and start over again. > > John > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From Alias.Schilling at TalkTalk.net Tue Oct 2 02:23:35 2007 From: Alias.Schilling at TalkTalk.net (Alias.Schilling) Date: Tue Oct 2 02:24:43 2007 Subject: [sldev] [Upcoming Changes] Website Viewer Authentication In-Reply-To: <46FD72A7.7040603@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> Message-ID: Oh joy! A third level of SL - grid, viewer and now the net too...?!? I really question the security of large quantitities of id info flowing from a web page to a viewer on a regular basis and am really not sure I'd want to use it... Is one thing to do basic account issues on the net but surely the log-in screen - or an elemnt of it - could be a "secure unit" that HAS to occur in every viewer as part of the terms of service? Why not get a security firm to implement security authentication into the viewer front-end?!? A Linden Labss Secure Log-in Module should occur in EVERY viewer as aay of providing the security required and this security should be implemented by security specialists bought in by Linden Labs not an internal team (eg "Second Life Log-in - auhenticated by Symantec") Regards, Alias Schilling > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of > David Kaprielian (Sabin) > Sent: 28 September 2007 22:31 > To: Second Life Developer Mailing List > Subject: [sldev] [Upcoming Changes] Website Viewer Authentication > > Hey all. I'm Sabin Linden, a developer here at Linden Lab. > You may know me as that Linden with the pixel avatar or > maybe... well... > actually I don't do much external facing work so you probably > don't know me at all. Don't worry, you're not missing out on much. > > In any case, I wanted to take a moment and send to this list > some security changes Linden is going to make in order to > further the efforts of anti-fraud and phishing prevention. > Pretty soon we're going to consolidate logins to our website > so we can eventually centralize the process. In other words, > residents will not have to type their name and password into > SL viewers and applications, they'll type them into our > website instead. The process that occurs is as follows: > 1: After logging into the website, you'll be taken to a new > page that has the same login location options the current SL > viewer has. > 2: When you hit the Go button, a form is submitted to a php > page, which redirects to a secondlife:/// url that has a web > key appended to it. > 3: The secondlife:/// url itself will launch Second Life with > locational details and the web key will authorize your > account for login. > Note: You can find more detailed information (the whys and > hows) on the public wiki at > https://wiki.secondlife.com/wiki/Viewer_Authentication > > This method works for Windows and Mac machines, but > unfortunately due to the nature of how Linux handles > secondlife:/// links (it doesn't), we have been unable to > come up with a proper, catch-all solution that would allow > this method of login to work for 100% of the Linux using > population. We estimate (aka: make an educated guess) that > we can catch about 70% of Linux users at first and will be > working to get that number as close to 100% as possible. > However, because there are so many different distributions > and configurations of Linux available, there's always the > possibility of people who cannot launch Second Life from the > website. Fortunately, we will be implementing a login screen > for each of our viewers (similar to the one you see now) > which goes through our website. Although this doesn't allow > as much security as we would like (since you're still > technically typing your password into the viewer) it will, at > least, allow all Linux users to log in. Additionally, it > will provide a fall-back for those who are used to the > current way of logging in. > > With this information, I wanted to get your feedback! Do you > think there's a way we could make website viewer > authentication work for all Linux users? Do you have any > specifications for how this will interact with your third > party viewers and applications? Anything I haven't covered > that you're worried about? Thanks for your time everyone, > we'd love to hear what you have to say. > > ~Sabin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Tue Oct 2 02:32:29 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 02:32:20 2007 Subject: [sldev] [Upcoming Changes] Website Viewer Authentication In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> Message-ID: <4702102D.8000107@wsu.edu> Alias.Schilling wrote: > Oh joy! A third level of SL - grid, viewer and now the net too...?!? I > really question the security of large quantitities of id info flowing from a > web page to a viewer on a regular basis and am really not sure I'd want to > use it... > > Is one thing to do basic account issues on the net but surely the log-in > screen - or an elemnt of it - could be a "secure unit" that HAS to occur in > every viewer as part of the terms of service? > > Why not get a security firm to implement security authentication into the > viewer front-end?!? A Linden Labss Secure Log-in Module should occur in > EVERY viewer as aay of providing the security required and this security > should be implemented by security specialists bought in by Linden Labs not > an internal team (eg "Second Life Log-in - auhenticated by Symantec") > > Regards, > Alias Schilling > My main viewer (TestClient in libsecondlife) works by passing username and password on the command line, and I'm not about to hire Symantec to rubber stamp that :-). John Hurliman From tofu.linden at lindenlab.com Tue Oct 2 03:14:43 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Oct 2 03:21:30 2007 Subject: [sldev] Re: New Viewer: Second Life 1.18.3 Viewer Available Today! In-Reply-To: <20071001194242.GM617@dague.net> References: <470145A1.2060103@lindenlab.com> <20071001194242.GM617@dague.net> Message-ID: <47021A13.2000801@lindenlab.com> See: https://jira.secondlife.com/browse/VWR-379 Sean Dague wrote: > On Mon, Oct 01, 2007 at 12:08:17PM -0700, Bridie Linden wrote: >> Thanks for everyone's help with our first Release Candidate viewer --- >> Second Life 1.18.3 Viewer is now the primary viewer download! Download >> via the release viewer login screen or simply use get.secondlife.com to >> get the newest main viewer version. >> >> 1.18.3.5 source code is identical except for release notes, but we are >> planning on another drop anyway. > > It appears that the linux version doesn't work on systems where /bin/sh > isn't bash. Modifying the secondlife script to start with #!/bin/bash > instead of #!/bin/sh fixes things. > > -Sean From dmahalko at gmail.com Tue Oct 2 03:29:53 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Oct 2 03:29:56 2007 Subject: [sldev] ATTN-LL: Adding / Extending SL wiki to discuss Havok-4 ? Message-ID: Well, I'd like to help expand on the information in the SL wiki and help document the features and limitations of the new engine, but I'm not sure what the protocol should be for this. Should a subpage be started linked from the main page, or is it okay to extend off the main page for now, until enough content accumulates to justify a subpage? I've experimentally added a new section to the bottom of the Havok 4 Beta Home page, though this is possibly not a good spot to add anything since it may seem like what I've added speaks for LL as part of the announcement of the beta grid. But, the page isn't locked against editing by us non-LL editors.... I don't know what to do. I'm going to leave it there for review, and if you (at LL) don't like it, then move it, edit it, or whatever is you think is appropriate: == New experiences that are normal == === Simulator lag from huge piles of stacked objects === === Thousands of objects that don't touch do not lag === https://wiki.secondlife.com/wiki/Havok_4_Beta_Home I've also created two documentary Google Videos to go along with the new sections, in order to make what's going on more visually understandable. (The second video is a bit long, and I'll probably redo it with an automated cube-dropper.) -Scalar Tardis / Dale Mahalko From jessesa at gmail.com Tue Oct 2 03:52:31 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Oct 2 03:52:33 2007 Subject: Goals for viewer authentication (was: Re: [sldev] Re: Viewer Auth Feedback) In-Reply-To: References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> Message-ID: On 10/2/07, Matthew Dowd wrote: > > > Indeed - and I've been wondering whether to edit the critique to make it > clear that the Goals listed *are* what we *think* the goals/objectives are > based on the original wiki page on some correspondence with LL. > > I thought it useful to be explicit in our assumptions (a) as it is clear > to LL what these are, as they do colour our responses (b) to prompt LL into > being more explicit in *what* they want to achieve rather than jumping > straight into the *how* which is really the information we have at present. > > Matthew > It seems that the stated goal of protecting our authentication data from a 3rd party viewer was either incomplete, poorly worded or intentional misdirection. The 2 points of vulnerability so far have been the wiki and the forum. LL still refuses to come out and even discuss the forum bbcode problem where we were vulnerable for over a year. When I mentioned it in the forum, the thread was moved to moderation. It does not take a rocket scientist to see that we have been incredibly lucky so far and need increased security across the board with our log in data; viewer, wiki, jira, forum, account page. How to achieve this extra security i sof course what we are talking about now. But I really wish we could split and narrow the use of our log in name and password to just our account page and viewer. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/7bf47475/attachment.htm From Anders at Arnholm.se Tue Oct 2 04:45:49 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Oct 2 04:47:35 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: <470202A8.2000503@wsu.edu> References: <470202A8.2000503@wsu.edu> Message-ID: <20071002114549.GJ16971@arnholm.se> On Tue, Oct 02, 2007 at 01:34:48AM -0700, John Hurliman wrote: > >appear on the Whitelist of approved IP's. Greylisting would allow one > >login attempt every 5-10 minutes and could be used when traveling. > >IP's on the blacklist would not be able to log into the account at all. > I'm curious why these measures are needed for Second Life but not to > manage any other assets over the net. And why can't this be solved in the current way of logging in. This kine of featurs sems totally independent of how the authentications is transferbned from the user to lindenlabs. As a end user i perfere having the log in in the client. Much easiet. I would like to specify where to staore the ~/.secondlife/ as well. Easy on the command line. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.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/20071002/173db0bc/attachment.pgp From hud at zurich.ibm.com Tue Oct 2 05:27:57 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 2 05:28:02 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: References: <47016CFE.1060509@lindenlab.com> Message-ID: <4702394D.5040202@zurich.ibm.com> Matthew Dowd wrote: > I'm not clear why this consolidation could not be acheived by having a > single backend webservice which did the authentication step, and which > was then fronted by a GUI frontend for the client and a web front end > for the websites? > IFF i understand sabin (and zero, who was talking about this in recent weeks off and on), they want to be able to login on the web page and then --- by some "magic" --- have that login carry over to the viewer... ...which i think will just confuse the heck out of people: "why do i have to login at the web site to use the application?" --- let alone all those security issues such as XSS et al. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/e64bf09d/attachment.htm From matthew.dowd at hotmail.co.uk Tue Oct 2 05:55:59 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 05:56:00 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <4702394D.5040202@zurich.ibm.com> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> Message-ID: "IFF i understand sabin (and zero, who was talking about this in recent weeks off and on), they want to be able to login on the web page and then --- by some "magic" --- have that login carry over to the viewer..." I understand that aspect - what I can't understand is *how* this would help LL in its anti-fraud activities. I *can* understand why having a single backend directory of usernames and passwords (or password hashes) would be better than copying the usernames/passwords between different directories for forums, accounts, SL, support etc. would be beneficial, just not why the viewer should use the exact same webform to authenticate as the website. That said there is a good counter argument that the forums should use a different username and password than the SL accounts (my own ISP has just moved from an integrated forum to a seperate one just so that a compomise in the forums software would not compromise the account with the ISP). Matthew _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/6bf4945d/attachment.htm From nicholaz at blueflash.cc Tue Oct 2 06:48:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Oct 2 06:48:38 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> Message-ID: <47024C26.6050304@blueflash.cc> Matthew Dowd wrote: > That said there is a good counter argument that the forums should > use a different username and password than the SL accounts (my own > ISP has just moved from an integrated forum to a seperate one just > so that a compomise in the forums software would not compromise the > account with the ISP). Which brings me back to my previous suggestion of making different passwords. Explanding on that, assuming a centralized back end is created, I'd say let it create password and assign/select services which can be used with them. ----------------------------------------------------------------- Password manager for Nicholaz Beresford Forum Wiki Account inworld-restricted inworld-full aaa111 [x] [x] [ ] [x] [ ] q$44&9A [ ] [ ] [x] [ ] [x] [add Password] ----------------------------------------------------------------- Nick From tateru.nino at gmail.com Tue Oct 2 06:51:31 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 2 06:51:36 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47024C26.6050304@blueflash.cc> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> Message-ID: <47024CE3.5020707@gmail.com> Nicholaz Beresford wrote: > Matthew Dowd wrote: >> That said there is a good counter argument that the forums should >> use a different username and password than the SL accounts (my own >> ISP has just moved from an integrated forum to a seperate one just >> so that a compomise in the forums software would not compromise the >> account with the ISP). > > Which brings me back to my previous suggestion of making different > passwords. Explanding on that, assuming a centralized back end is > created, I'd say let it create password and assign/select services > which can be used with them. > > ----------------------------------------------------------------- > > Password manager for Nicholaz Beresford > > Forum Wiki Account inworld-restricted inworld-full > aaa111 [x] [x] [ ] [x] [ ] > q$44&9A [ ] [ ] [x] [ ] [x] > > [add Password] > > ----------------------------------------------------------------- > Personally, I'd like to get out-of-band confirmation for the exercise of capabilities. An email with a link, for example, before rezzing an object, or doing anything that debits my account, or much else other than walking and talking. So I can configure which ones are always on, never on, or that the system has to ask me out-of-band to grant for the rest of the session. -- Tateru Nino http://dwellonit.blogspot.com/ From secret.argent at gmail.com Tue Oct 2 07:12:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 07:12:42 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4701B385.8000507@dzonux.net> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <4700C432.4060202@wsu.edu> <1191286994.3045.7.camel@localhost.localdomain> <4701B385.8000507@dzonux.net> Message-ID: On 01-Oct-2007, at 21:57, Dzonatas wrote: > None of that would be required if, instead of an in-world prim with > a warning, the in-world prim actually displayed the login prompt. > (Someone wanted HTML on a prim?) Noooooooooooooooooooooooo..... From andrew at lindenlab.com Tue Oct 2 07:17:47 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Tue Oct 2 07:18:25 2007 Subject: [sldev] ATTN-LL: Adding / Extending SL wiki to discuss Havok-4 ? In-Reply-To: References: Message-ID: <4702530B.6010307@lindenlab.com> It's a wiki. I'd recommend creating your own pages and putting links on the Havok_4_Beta_Home page. Eventually Havok_4_Beta_Home should go away when th Beta is old hat, however information relevant to how the physics engine works should stay. The effect you're noticing where large contiguous piles hit the physics engine harder than smaller distributed piles is their "simulation island" (SI) management. Each SI is a data structure that has a list of potentially colliding objects and an axis aligned bounding box (AABB) that encloses all of the objects. When two SI's meet they are merged into one; when the pile spreads out the SI may be split into multiple SI. Havok4 uses the SI AABB's to rapidly cull the input for the "broadphase collision" test (the rough test that builds a list of "might be colliding" pairs of objects). The list of pairs is then passed to the "narrowphase collision" tests which generate the detailed contact points where the objects are actually hitting, if any. You could think of the SI system as a meta broadphase, so Havok4 has three layers of collision tests. When all of the dynamic objects are in a single pile, the SI layer collapses to a point and all you're left with is the broad- and narrowphase tests. The SI management is the main source of Havok4's speed over Havok1 -- there are lots of other improvements, but the SI layer is the biggest win. So a huge pile of dynamic objects is going to lag Havok4, but without the crashing. Havok1 doesn't actually crash... it just blocks. It might block for 20 seconds, or maybe an hour, but it would eventually return. Years ago the simulator could return from 15 minutes of blockage and you'd still be logged on, and you could IM the whole time. Now, if the simulator blocks for more that 90 seconds there is a watchdog process that sends it a signal to bring it down -- that is the "crash in Havok1" that you're all familiar with. Turns out that Havok4 can also block, but not as long (I was able to get it to block for about 10 seconds without pushing too hard) by using their hkListShape colliding against another hkListShape, which would generate N^2 potential collision points. Hence the use of the memory optimized partial polytope (MOPP) that I mentioned in an earlier email. There, link some new wiki pages to the Havok_4_Beta_Home page about how Havok4 works and I'll help fill in the gaps. It's a wiki. - Andrew Dale Mahalko wrote: > Well, I'd like to help expand on the information in the SL wiki and > help document the features and limitations of the new engine, but I'm > not sure what the protocol should be for this. Should a subpage be > started linked from the main page, or is it okay to extend off the > main page for now, until enough content accumulates to justify a > subpage? > > I've experimentally added a new section to the bottom of the Havok 4 > Beta Home page, though this is possibly not a good spot to add > anything since it may seem like what I've added speaks for LL as part > of the announcement of the beta grid. But, the page isn't locked > against editing by us non-LL editors.... I don't know what to do. > > > I'm going to leave it there for review, and if you (at LL) don't like > it, then move it, edit it, or whatever is you think is appropriate: > > == New experiences that are normal == > === Simulator lag from huge piles of stacked objects === > === Thousands of objects that don't touch do not lag === > > https://wiki.secondlife.com/wiki/Havok_4_Beta_Home > > I've also created two documentary Google Videos to go along with the > new sections, in order to make what's going on more visually > understandable. (The second video is a bit long, and I'll probably > redo it with an automated cube-dropper.) > > > -Scalar Tardis / Dale Mahalko > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Tue Oct 2 07:38:14 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Oct 2 07:38:20 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47024CE3.5020707@gmail.com> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> <47024CE3.5020707@gmail.com> Message-ID: <470257D6.1060101@blueflash.cc> Tateru Nino wrote: >> ----------------------------------------------------------------- >> >> Password manager for Nicholaz Beresford >> >> Forum Wiki Account inworld-restricted inworld-full >> aaa111 [x] [x] [ ] [x] [ ] >> q$44&9A [ ] [ ] [x] [ ] [x] >> >> [add Password] >> >> ----------------------------------------------------------------- >> > Personally, I'd like to get out-of-band confirmation for the exercise of > capabilities. An email with a link, for example, before rezzing an > object, or doing anything that debits my account, or much else other > than walking and talking. So I can configure which ones are always on, > never on, or that the system has to ask me out-of-band to grant for the > rest of the session. Only if you can't use the password (the one which you gave the viewer) to reconfigure these options. If 3rd party viewer security is the goal, the only way to enforce that, is (like everything these days) server side by not allowing the viewer to do specific things. Nick From secret.argent at gmail.com Tue Oct 2 07:51:11 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 07:51:18 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191294300.3045.42.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191294300.3045.42.camel@localhost.localdomain> Message-ID: On 01-Oct-2007, at 22:05, Ryan McDougall wrote: > On Mon, 2007-10-01 at 21:38 -0500, Argent Stonecutter wrote: >> If you have a compromised SL viewer you don't have to attack >> anything. You already have the golden ring, you've won. > Actually I thought the goal was to protect the user's valuables, > specifically L$, but also his in game assets. Which is what a compromised SL viewer gives you. The whole "oh no, it can steal your password" schtick is a red herring. > Only if you care if your users get told that they may be running an > unknown viewer. OK, let me get this straight. If my viewer is legitimate but I haven't got a certificate, the LL server will send the viewer a message to tell the user that the viewer may not be legitimate, which being legitimate, I'll pass on to them. If my viewer is crocked, the LL server will still send the viewer a message, but the crocked viewer will hide it, and thus it will appear more legitimate than the legitimate viewer that hasn't jumped through the certificate hoops. > If you care and have a large user base, you download GPG > and create a key, then publish it -- that simple. That doesn't do anything more to help Linden Labs "track me down" unless I need to do more than that. If the viewer on my website is crocked, they've got me. If the viewer is crocked and signed by a private key, and I've put the public key on my website, well... the only thing they've got is what they started with... it was distributed from my website. This would protect people from getting a package from Joe's BBS that claimed to be from Linden Labs, sure, but we don't distribute software that way on the Internet... you don't go to Joe's BBS to download the SL client, you go to secondlife.com. > All the linux distros' package security currently works like this. Ah, that's right, Linux does have half a dozen crack-brained packaging schemes that involve trusting third-party repositories, harking back to the days when Linus was using well-known FTP servers like BBSes instead of running his own site, and because Linux doesn't actually have a core OS... it's thousands of packages flying in close formation. That doesn't apply here, because that's not how software gets distributed outside the Linux world. Unless Linden Labs does the signing, this wouldn't provide any more assurance for Joe's Viewer than the fact that it was downloaded from the website where joe published his public key. From secret.argent at gmail.com Tue Oct 2 07:58:33 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 07:58:49 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1191295130.3045.54.camel@localhost.localdomain> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191295130.3045.54.camel@localhost.localdomain> Message-ID: <37941B29-FB20-43AF-90AA-BB0C663F11B2@gmail.com> On 01-Oct-2007, at 22:18, Ryan McDougall wrote: > I propose that an out of process PKI library be used to transfer an > temporary authorization token to the client viewer. Once the token has > been handed to the viewer, then the viewer can do anything to the > user's > account. We rely on the server and the PKI system to only hand the > token > off when the Private Key, located on the user's machine, matches the > Public Key stored on the LL server (given over SSL during > registration). > The security of the system would rely on the assumption that a > compromised viewer cannot break the OS's security, and access the > Private Key. If the user has downloaded the viewer (voluntarily, by his choice) then why would the user prevent the viewer he downloaded from getting to the private key he created? The viewer is expected to be able to read this key. It doesn't matter whether the viewer is from Linden Labs or J Random hacker, the user's GOT to be able to grant it the rights to get whatever information it needs to log in to Second Life, otherwise why is he downloading it? It doesn't matter whether those rights are granted by typing in his password or by right-clicking on an icon and selecting "Allow this program to access my keychain" or by responding to a dialog from teh OS when it asks to access the keychain. The user has downloaded and installed the package, because the user wants to use it to play Second Life. This isn't like your wife's Chase bank account, because your wife isn't downloading a third party Chase Bank Account Viewer. From dzonatas at dzonux.net Tue Oct 2 08:05:54 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 08:03:53 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> Message-ID: <47025E52.9090509@dzonux.net> Matthew Dowd wrote: > > I think this discussion is suffering from a serious lack of > > clarification on exactly what case we are trying to fix. I'd love to > > hear from Sabin what he thinks of the discussion, and what use cases he > > is after. > > I'm also getting confused by the subject line too ;-) for me OpenID > offers the following potentials (I meant to send a similar e-mail to > the list yesterday but forgot to cc the list!): > > OpenID is *part* of the solution for allowing a single userid to be > used for multiple services (both from LL and others) - if that was > felt to be a desirable option. I think what is being confused is the thought that the login ID itself for OpenID is being directly tied (as part of the security token) to access in-world. You only need a SSL certificate instead of the login (ID/password). The login with ID and password is not needed to get in-world. At this point in time, you won't get far in-world being indentity-less. LL's proposal is a quick fix to use the technology that now exists in the viewer offset the login out of the viewer and take it one step towards server side with a temporary (MD5) certificate to login. I look at this and say we could have the option to take it another step further with SSL certificates. One is created already by means of HTTPS in the same manner of LL's proposal. The MD5 certificate would allow HTTP based logins, but that should be an option, which really does appear to be a transitional option just to get over public fear caused by the URL pwngd. Now, we could transition from the proposed embedded login to OpenID. Notice how the original SSL certificate (mentioned above) is being created with the HTTPS connection without ever there being a need to login to OpenID or in-world. If you are not that familiar with HTTPS, then the SSL certificates are just completely hidden until an application (like a web browser) asks you if you want to verify or accept them. We could take this all a step further with OpenID and verification brokerage with higher persistence on SSL certificates that get signed by a 3rd party. Yes, OpenID is *part* of the solution, but it does not need to be included at first transition. There was the question, however, if we should jump ahead on this and skip a transitional. What I read is if we jump ahead then what would be the justification to do such then to just settle for LL's proposal as it now stands? I asked to allow OpenID and SSL certificates as an option. My justification for it is that the technology already exists in the viewer, and that being partially because there still needs to be implementation to access OpenID and implementation to use SSL certificates independently of HTTPS or the web browser. The OpenSSL library already exists, so yes we can use SSL certificates independently. We already have a web browser to access the basic of OpenID, but it is noted many times in this thread how it can be a pain to rely on the web browser being present in the viewer. I also stated that with higher persistent SSL certificates, the web browser is not needed in the viewer as such certificates can be established independently of the viewer. The other thing I see that confuses this thread is that there exists lots irrelevant arguments over implementation rather than just focus on justification. If we worry too much about implementation and not stay focused on the analysis of this (with justification), then we are over-planning and wasting time. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/42ca1aa5/attachment-0001.htm From secret.argent at gmail.com Tue Oct 2 08:16:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 08:16:06 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: References: Message-ID: <40E48DD8-6CDE-4BC8-9273-6C98905CFB98@gmail.com> On 02-Oct-2007, at 00:56, Harold Brown wrote: > This proposal is for a multi-factor authentication method to be > added to the login system. This method should be easy for the end > user without greatly affecting their current login experience. [followed by a scheme that most users are going to run screaming from] This, or any other scheme that involves more than a user ID and password, had better be optional. From hud at zurich.ibm.com Tue Oct 2 08:18:06 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 2 08:18:10 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> Message-ID: <4702612E.8000604@zurich.ibm.com> Matthew Dowd wrote: > > > > > "IFF i understand sabin (and zero, who was talking about this in > recent weeks off and on), they want to be able to login on the web > page and then --- by some "magic" --- have that login carry over > to the viewer..." > > I understand that aspect - what I can't understand is *how* this > would help LL in its anti-fraud activities. I *can* understand why > having a single backend directory of usernames and passwords (or > password hashes) would be better than copying the > usernames/passwords between different directories for forums, > accounts, SL, support etc. would be beneficial, just not why the > viewer should use the exact same webform to authenticate as the > website. > neither do i understand the anti-fraud angle...time to discuss with zero on thursday :-) -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/ce222e05/attachment.htm From secret.argent at gmail.com Tue Oct 2 08:18:11 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 08:18:13 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: References: Message-ID: <84E8EE3B-7088-4F97-B254-A01333F49EB8@gmail.com> On 02-Oct-2007, at 03:20, Harold Brown wrote: > As another factor in increased account security. Account owners > should have the ability to see what IP's have successfully logged > in to their account and those IP's that have made any attempts to > log into their account. Heck, I'd like to just be able to get a list of times I'd logged in and out. From secret.argent at gmail.com Tue Oct 2 08:26:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 08:26:05 2007 Subject: [sldev] [PROPOSAL] IP / Computer Black / White / Greylist and attempted login log. In-Reply-To: <3b19a500710020217i1e3effb6x24dd2a1274f94620@mail.gmail.com> References: <470202A8.2000503@wsu.edu> <470206B6.6020108@wsu.edu> <3b19a500710020217i1e3effb6x24dd2a1274f94620@mail.gmail.com> Message-ID: On 02-Oct-2007, at 04:17, Tim Shephard wrote: > Paypal has an RSA token they provide. I guess we could do RSA token, > but that seems a lot more involved than simply locking to an IP > address. It's also a lot more useful. > I know a lot of people who have oodles of L$ in their account would > dearly dearly love this feature. Oh yes... I have no objection to extra authentication that a user can request, but you really don't want to see the results of having a zillion random newbies trying to deal with anything more than the current user ID and password. From iseki at solar-system.tuis.ac.jp Tue Oct 2 08:32:17 2007 From: iseki at solar-system.tuis.ac.jp (iseki@solar-system.tuis.ac.jp) Date: Tue Oct 2 08:32:30 2007 Subject: [sldev] Second Life Proxy Server Message-ID: <20071002153217.5348BBA360@jupiter.solar-system.tuis.ac.jp> Hi. I made Second Life Proxy program. This software is Proxy Server for Second Life on Linux. It has aimed to connect to Second Life Server from the PC in the firewall such as university. Merits: 1. You can execute Seconf Life from PC with private IP address in the firewall. 2. The access control (for viewer) and specification of use port number (for proxy server) are possible. 3. Full HTTPS access is possible. 4. OpenSim is supported. Inconvenience: 1. It uncorresponds to slvoice. 2. Data cache is not supported. 3. Speed is down. If it is interested, please download from http://www.solar-system.tuis.ac.jp/SoftWare/software_eng.html Program name is sl_relay. Now version is 1.0.2 Thank you. ---------------------------------------------------------------- Tokyo Joho Univ. Fumikazu Iseki mailto:seki@solar-system.tuis.ac.jp http://www.solar-system.tuis.ac.jp/~iseki From sl at phoca.com Tue Oct 2 08:38:13 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Oct 2 08:38:31 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <4702394D.5040202@zurich.ibm.com> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> Message-ID: <8C699D6D56AA4B93A86649698310A7E8@SanMiguel> I believe that LL said that the primary reason for doing it that way was to remove the log-in from the client because third party clients /could/ be used to harvest name/password data from users that used them. By logging into the web site and having a web page launch the viewer then that specifically can't happen. Sounds like a good idea at that point... HOWEVER. Of course there are actually even MORE ways to spoof webpages and exploit bugs to harvest that SAME info from the browser as well as the fact that even of the log-in info is secure, once logged in a malicious client could STILL transfer lindens or do /anything/ the user could do once logged in. So the stated goal of increasing login security by logging into the web page to protect the used from malicious clients at this point seems pretty moot... At this point ALL of the security issues to date (that I know about) have been caused by the Linden's own website or by the fact that the current client login method and data stream is insecure on shared networks. Farallon ----- Original Message ----- From: dirk husemann To: Matthew Dowd Cc: Second Life Developer Mailing List Sent: Tuesday, October 02, 2007 5:27 AM Subject: Re: [sldev] Re: Viewer Auth Feedback Matthew Dowd wrote: I'm not clear why this consolidation could not be acheived by having a single backend webservice which did the authentication step, and which was then fronted by a GUI frontend for the client and a web front end for the websites? IFF i understand sabin (and zero, who was talking about this in recent weeks off and on), they want to be able to login on the web page and then --- by some "magic" --- have that login carry over to the viewer... ...which i think will just confuse the heck out of people: "why do i have to login at the web site to use the application?" --- let alone all those security issues such as XSS et al. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From jessesa at gmail.com Tue Oct 2 08:42:05 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Oct 2 08:42:09 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <47025E52.9090509@dzonux.net> References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> Message-ID: On 10/2/07, Dzonatas wrote: > > The other thing I see that confuses this thread is that there exists lots > irrelevant arguments over implementation rather than just focus on > justification. If we worry too much about implementation and not stay > focused on the analysis of this (with justification), then we are > over-planning and wasting time. > > -- > Power to Change the Void > Agree completely with this. Until we get calrification from LL as to what they are trying to do, everything else means nothing. The only reason given at first was to protect us from hacked 3rd party viewers. That reason was shown to be nonsense because once a hacked viewer has logged into the account they already have everything they came for. Our account data is vulnerable in several spots. So far the viewer hasn't been the weakest link. As I pointed out in another thread we use the exact same user name to log into jira, the LL website, including our account page, the forums, the wiki AGAIN and the viewer. You could also halfway argue too about throwing 3rd party sites like SLexchange into the mix, I wonder how many people use the same password there. We were already hacked in the wiki and there has been no clarification or even anyone admitting that we were vulnerable for over a year in the forums before bbcode was disabled. That's right, a vulnerability was discovered in VBulletin on 1/31/05 and bbcode wasn't disabled till this year. I would suspect that the new login scheme is the reason that LL has finally hopped off the fence and appointed new moderators to the forums. I completely understand everything BUT the viewer needing a better form of security, otherwise it will just be time before we are hit once again. Especially if the forums are finally upgraded to the latest VBulletin version and bbcode is re-enabled. All you have to do is google the terms bbcode and secuirty to see that it is a very popular point of entry for hackers. So yes, please LL step forward and state clearly what you are trying to achieve and then we can help throw out ideas that have a clear target. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/b01a30e1/attachment-0001.htm From secret.argent at gmail.com Tue Oct 2 08:42:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 08:42:30 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <470257D6.1060101@blueflash.cc> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> <47024CE3.5020707@gmail.com> <470257D6.1060101@blueflash.cc> Message-ID: <10D153B0-B3D7-4689-9849-E6FA6EF12FA0@gmail.com> On 02-Oct-2007, at 09:38, Nicholaz Beresford wrote: > Only if you can't use the password (the one which you gave the viewer) > to reconfigure these options. If 3rd party viewer security is the > goal, > the only way to enforce that, is (like everything these days) server > side by not allowing the viewer to do specific things. Since, for most people, the viewer is more secure than the web browser... this would lead to an overall reduction in security. That's something I can't emphasize enough. For most people, the web browser is far more likely to be compromised than the viewer, whether they're using a third-party viewer or not. And with XSS the browser can be compromised without the browser sandbox being breached. For example... I'm glad I use POP for most of my gmail reading, so I'm usually not logged in to google. THIS is one (of many) reasons I don't want to use the same identity on multiple sites, regardless of whether I authenticate by a password, certificate, OpenID, or magic wand. From dzonatas at dzonux.net Tue Oct 2 09:33:57 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 09:31:56 2007 Subject: [sldev] Second Life Proxy Server In-Reply-To: <20071002153217.5348BBA360@jupiter.solar-system.tuis.ac.jp> References: <20071002153217.5348BBA360@jupiter.solar-system.tuis.ac.jp> Message-ID: <470272F5.4010307@dzonux.net> iseki@solar-system.tuis.ac.jp wrote: > Hi. > > I made Second Life Proxy program. > Awesome! ... > 3. Full HTTPS access is possible. > ... > 2. Data cache is not supported. > > Please see the wiki page that we created: https://wiki.secondlife.com/wiki/SLSquid_Proxy It has the data cache, but it doesn't have full https support. You're work would combine nicely with that project to create and complete a reverse proxy. The goal included a way to make it a drop-in solution as much as possible for users, like 0-configuration. The HTTPS factor is what made it a bit of challenge as it would have to use certificates more dynamically than the model Squid provides by itself. I look forward to see if your software provides a piece to the puzzle. =) -- Power to Change the Void From dzonatas at dzonux.net Tue Oct 2 10:41:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 10:39:17 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> Message-ID: <470282BD.5030508@dzonux.net> Jesse Barnett wrote: > > So yes, please LL step forward and state clearly what you are trying > to achieve and then we can help throw out ideas that have a clear target. > That would be on the page: https://wiki.secondlife.com/wiki/Viewer_Authentication Under: "Why we're making this change." The confusion there is that the statements on that page use "open source" as leverage to say that the official viewer is more secure. The is not true as you pointed out over a hacked viewer. Any viewer is, rather open source or not, is really on the same level of security. In fact, we could take all viewers out of this argument and say that the network protocols themselves as they exist are where the questionable security exists. Does the mere attempt to move authentication (as it exists now) from the viewer to the web-site change anything? No because it still is a login prompt. It would change accountability from the implementation being more in the viewer to being more in the web browser. If that web browser is Mozilla based, then they have resulted to use another "open source" solution. That attempt to leverage on "open source" as the official viewer is more secure doesn't make sense at all. Why try to say "open source" is not secure and to make it more secure the solution is another "open source" environment? (Hence, I signed the critique) The thing here to recognize is that these facts are not straight on the WVA wiki page. The why is really the need to improve the authentication protocol (not the viewer). To pawn other non-official viewers as less secure in the process of its justification is a horrible attempt to discredit developers. I gave the benefit of the doubt and kept in mind the "maybe it was not intended that way" thought. I also realized that the WVA method as on the wiki page is verify similar to a method I suggested about a year ago (on the forums, mainly). Mine mainly meant one could use llhttprequest() to verify keys or authenticate avatars, which mainly sprung out of the CC verification arguments. This here, with WVA, is a more complex implementation to involve much more persistence than what a single llhttprequest() can do. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Tue Oct 2 11:57:13 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 2 11:57:16 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: > Thus we are > focusing on converting the current login screen to an embedded web > login. Actually I knew there was something else I meant to ask about the embedded web login idea what is to stop me modding the source code so that the form data is logged before being POSTed to server the web form is on? Indeed how will the use know that the web form really is from the SL website and really will generate a POST to the SL website? Matthew _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/876fb5e2/attachment.htm From josh at lindenlab.com Tue Oct 2 12:02:59 2007 From: josh at lindenlab.com (Joshua Bell) Date: Tue Oct 2 12:01:07 2007 Subject: [sldev] [PROTOCOL] What is AgentMovementComplete.SimData.ChannelVersion? In-Reply-To: <70FCC85A-C8A8-4E0C-B938-C650D1998AC4@mm.st> References: <47013793.5030300@wsu.edu> <70FCC85A-C8A8-4E0C-B938-C650D1998AC4@mm.st> Message-ID: <470295E3.2050609@lindenlab.com> If you're running 1.18.3 and cross a region boundary and the new region is running different code than the old version, you get a popup with release notes. We'll use this for scenarios such as deploying Havok4 to part of the main grid (Het Grid, as surmised), so we can warn you that (e.g.) physics updates are in beta and there are known issues with vehicles in the new region. Although I knew about the feature, it surprised a few of us yesterday (in a good way!) during the rolling restart as we ran across a boundary from an old sim to a new sim. Ben Byer wrote: > Lemme guess: Sim version number, to support HetGrid? > -b > > On Oct 1, 2007, at 11:08 AM, John Hurliman wrote: > >> http://libsecondlife.org/template/release/diff-1.18.3.5.txt >> >> Anyone? >> >> John Hurliman >> _______________________________________________ >> 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 labrat.hb at gmail.com Tue Oct 2 12:09:50 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Oct 2 12:09:56 2007 Subject: [sldev] [PROTOCOL] What is AgentMovementComplete.SimData.ChannelVersion? In-Reply-To: <470295E3.2050609@lindenlab.com> References: <47013793.5030300@wsu.edu> <70FCC85A-C8A8-4E0C-B938-C650D1998AC4@mm.st> <470295E3.2050609@lindenlab.com> Message-ID: You can experiance this on the Beta Grid now crossing in and out of the Havok4 sims On 10/2/07, Joshua Bell wrote: > > If you're running 1.18.3 and cross a region boundary and the new region > is running different code than the old version, you get a popup with > release notes. We'll use this for scenarios such as deploying Havok4 to > part of the main grid (Het Grid, as surmised), so we can warn you that > (e.g.) physics updates are in beta and there are known issues with > vehicles in the new region. > > Although I knew about the feature, it surprised a few of us yesterday > (in a good way!) during the rolling restart as we ran across a boundary > from an old sim to a new sim. > > Ben Byer wrote: > > Lemme guess: Sim version number, to support HetGrid? > > -b > > > > On Oct 1, 2007, at 11:08 AM, John Hurliman wrote: > > > >> http://libsecondlife.org/template/release/diff-1.18.3.5.txt > >> > >> Anyone? > >> > >> John Hurliman > >> _______________________________________________ > >> 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/20071002/176b1294/attachment.htm From philo at hybridsl.com Tue Oct 2 12:28:34 2007 From: philo at hybridsl.com (Philo Sion) Date: Tue Oct 2 12:28:38 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: <40E48DD8-6CDE-4BC8-9273-6C98905CFB98@gmail.com> References: <40E48DD8-6CDE-4BC8-9273-6C98905CFB98@gmail.com> Message-ID: <5d551a6b0710021228h2d711b7dr5852ed8587fc6e79@mail.gmail.com> I'm going to have to agree with Tateru and Argent on that one. From dzonatas at dzonux.net Tue Oct 2 14:50:23 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 14:48:26 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: References: Message-ID: <4702BD1F.7040609@dzonux.net> Harold Brown wrote: > PROPOSAL: > Each user should (at account creation, or after logging in to the > system for the first time without this enabled) upload a personal > image. This image should be something that they can easily identify > from a group of images at login. When logging in the system should > present a preset number of images that the user must select their > personal image from. Upon presentation the images must have a randomly ... Your proposal is not an anti-fraud measure. It may help prevent phishing attacks, but it gives no ability to aide in anti-fraud. -- Power to Change the Void From nicholaz at blueflash.cc Tue Oct 2 15:10:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Oct 2 15:11:02 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <47016CFE.1060509@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> Message-ID: <4702C1ED.2010506@blueflash.cc> David Kaprielian (Sabin) wrote: > Initially, our > goal was to consolidate our authentication implementation in order > to support back-end anti-fraud work. This remains the priority! I guess our priorities here differ a bit ... Nick From robla at lindenlab.com Tue Oct 2 15:28:34 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Oct 2 15:28:48 2007 Subject: [sldev] Re: Goals for viewer authentication In-Reply-To: <4701A1D8.7060808@gmail.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> Message-ID: <4702C612.9050705@lindenlab.com> On 10/1/07 6:41 PM, Tateru Nino wrote: > One of the things about the proposed viewer authentication that I'm hazy > on is Linden Lab's actual _goals_ for the new system. Most of what I've > seen is assumption of goals, or allusion to goals. It occured to be > today, reading through the viewer critique that a lot of the goals seem > to be the ones we _assume_ Linden Lab to have for the system. > > What, exactly is the bulleted list of goals that a change to the > authentication system is to meet? I mean, we can criticize the system > generally - but we can't necessarily propose one that is more acceptable > to Linden Lab unless we're sure of their acceptance criteria, no? > Otherwise we're talking in circles hoping to stumble on something that's > acceptable by happy accident. > After talking to the team that's been working on this, I'm getting a better understanding of what the goal is. Unfortunately, there's only so much we can talk about at this point, other than to say that it's part of a necessary consolidation of entry points to the system. The main thing this accomplishes is the ability to leverage a number of well understood web technologies for login support, as well as well-understood back-end systems for managing it. The critique has been helpful for me to understand the basic thrust of the criticism here: https://wiki.secondlife.com/wiki/Viewer_Authentication_Critique ...and I think that will serve as good outline for a real-time discussion when Zero is back in the office (timing TBD). This is still early in the conversation, so don't panic about us being slower than you might like to discuss this. One thing that will be useful in the interim is a short list of compiled questions. Put your nominations here: https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication_FAQ ....and sign (~~~~) the ones you agree are good ones to go into the FAQ (and, for that matter, put "Bad Q" on the questions that you think is rather silly to spend time on). We'll answer the most popular ones here: https://wiki.secondlife.com/wiki/Viewer_Authentication_FAQ Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071002/5ef3c076/signature.pgp From secret.argent at gmail.com Tue Oct 2 15:30:27 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 15:30:24 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <470282BD.5030508@dzonux.net> References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> Message-ID: <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> On 02-Oct-2007, at 12:41, Dzonatas wrote: > Does the mere attempt to move authentication (as it exists now) > from the viewer to the web-site change anything? Absolutely. * Using the website means that you can't use an enforced challenge- response mechanism... the password has to be sent over the network. Yes, it could be inside an SSL tunnel, but it still has to be sent to the server, so it can be stolen by a crocked server. * Using the website means that if you can present people with a prompt that looks like the server you can use that to phish for their passwords. And you can do that even without breaking the browser sandbox. That is, the viewer is inherently more secure than a website, and moving the authentication to the web reduces security. In addition, the fact that the website connection is a persistent connection with no clear session model, rather than one where exiting the viewer automatically tears down a connection and thus the session, opens up additional opportunities for an attack. So, yeh, it changes things... for the worse. > The why is really the need to improve the authentication protocol > (not the viewer). 1. Make the server connection via SSL to prevent sniffing. 2. Use challenge-response (eg, kerberos), hidden from the user. 3. Use a challenge-response key agreement protocol (eg, EKE) to both avoid sending the password AND to generate a shared key. Given that it's using plaintext passwords over an unencrypted connection, there's nowhere to go but up. I just want to make sure that the road leading upward doesn't end up in a dead end. From jhurliman at wsu.edu Tue Oct 2 15:32:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 15:32:28 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation Message-ID: <4702C702.1030100@wsu.edu> I merged my own documentation skeleton page on the wiki with the "Protocol" page at http://wiki.secondlife.com/wiki/Protocol, this is still the official home of all protocol documentation for Second Life and I assume will be the closest thing there is to an official specification of "How Second Life Works". Community driven documentation is going to be more important then it was previously due to the way the protocol is changing. Traditionally we had everything going over UDP and the format of things was documented by a file called message_template.msg. This allowed clients to either build packets and verify them at runtime (such as the SL viewer) or pre-generate code to represent packets in memory (such as libsecondlife). With the new capabilities system we have no message_template.msg, and there is no way to pre-generate code to represent message structures or verify the correctness of code at runtime. Right now you can't even query what capabilities are available to clients although this may change in the future. The message_template party was fun while it lasted but we are going to have to go back to the traditional method of development, meaning good documentation that unit tests can be built from and third party implementations can work off of, since runtime or compile time verification is no longer possible. Linden Lab internally uses the viewer and simulator source code for documentation (I'm told), so if we want a specification the community will be responsible for generating it. Some open questions: * Is the current structure of the page a good breakdown of the different sections of the protocol? Should things be split up or consolidated in any places? * Since all of the capabilities will need to be described here we need a standard markup to document them. Should the LLSD notation format be used, or some other pseudo-markup? For some background, this was discussed at Zero Linden's office hour today (Zero was out but other Lindens filled in). The conversation went something like this: LL: the capabilities API may not necessarily be the same as the old message template Me: so we need to hand-write new processing code for each capability, unlike the old udp system Others: wouldn't a server-side changelog fix this? Me: if i understand right, things are transitioning from a system where we have a file format detailing the structure of messages, to a system where there is no documentation, no way of the client knowing what it is supposed to handle or not, and no idea what means what once you figure out the capabilities you are supposed to handle LL: we can't log every change, it would be cluttered and irrelevant LL: the source code is very clear on how all of this works Others: the viewer isn't documentation, it's GPL licensed source code that is neither a preferred medium for documenting a protocol nor a license-compatible method of providing docs LL: it is very clear documentation Me: so we can look through the SL viewer source code to learn how things work and reimplement it in BSD licensed libsecondlife correct? [13:31] Rob Linden: Eddy, as long as you don't steal code, yes LL: so this whole discussion about documenting the capability API is just so people can steal code? Others: no, we don't want your source code. please keep it Me: we would like documentation to write independent implementations though Others: independent implementations... part of that whole architecture working group thing John Hurliman From dzonatas at dzonux.net Tue Oct 2 16:44:14 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 16:42:11 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> Message-ID: <4702D7CE.401@dzonux.net> Argent Stonecutter wrote: > On 02-Oct-2007, at 12:41, Dzonatas wrote: >> Does the mere attempt to move authentication (as it exists now) from >> the viewer to the web-site change anything? > > Absolutely. It is an illusion. One is 2D and the other is virtual 3D on 2D. > > Given that it's using plaintext passwords over an unencrypted > connection, there's nowhere to go but up. I just want to make sure > that the road leading upward doesn't end up in a dead end. The best anti-phishing mechanism still does not solve the bottom line goal of anti-fraud. It is not just the login that matters, but there is the need to verify identity. The login itself can not help verify real identity, as it just allows anyone pass that knows the secret word. The login does, however, need to be implemented in a way that people can still enjoy anonymity. If someone breaks the login, then we are screwed if there is no anti-fraud measure. It would be comparable to the famous disruption at the Anshe Chung interview... they couldn't stop it or tell who really caused it! It could have been worse (legally) especially if the teen grid and main grid were united. (Yes, I would love to see these grids united, as families belong together!) -- Power to Change the Void From labrat.hb at gmail.com Tue Oct 2 16:48:47 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Oct 2 16:48:50 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: <4702BD1F.7040609@dzonux.net> References: <4702BD1F.7040609@dzonux.net> Message-ID: Considering I never once mentioned fraud / anti-fraud... yes you are correct it has nothing to do with fraud, other then as a login method that consists of a piece of information held by the Linden Labs servers that can only be identified by the account owner. The authentication model proposed by Linden Labs was nothing more or less then exactly what my proposal was. A method to allow an untrusted client the ability to log onto the grid without having access to your full credentials. Why is this important? Because once you have the username and password to the account, you have full access to use that accounts payment information to buy lindens or sell lindens, change the account password, etc. Yes a compromised client can delete your items, transfer your lindens on hand, etc. But having the Username and Password currently gives you even more access to the account. On 10/2/07, Dzonatas wrote: > > Harold Brown wrote: > > PROPOSAL: > > Each user should (at account creation, or after logging in to the > > system for the first time without this enabled) upload a personal > > image. This image should be something that they can easily identify > > from a group of images at login. When logging in the system should > > present a preset number of images that the user must select their > > personal image from. Upon presentation the images must have a randomly > ... > > > Your proposal is not an anti-fraud measure. It may help prevent phishing > attacks, but it gives no ability to aide in anti-fraud. > > > -- > Power to Change the Void > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/9c02192a/attachment.htm From secret.argent at gmail.com Tue Oct 2 17:11:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 17:11:36 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4702D7CE.401@dzonux.net> References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> Message-ID: <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> On 02-Oct-2007, at 18:44, Dzonatas wrote: > The best anti-phishing mechanism still does not solve the bottom > line goal of anti-fraud. It is not just the login that matters, but > there is the need to verify identity. And that's the user name and password. It doesn't matter how many hoops you jump through, it's still coming down to a user name and password. There is NO WAY that people are going to put up with having to know anything more than a username and password to log in to a game. So anything stronger has to be optional, and if it's optional it doesn't do anything to prove identity where it isn't used. On the other hand, you can design the system so that phishing is hard, and you can design the system so that phishing is easy. Any mechanism where logging into the web is a normal step in logging in to SL makes phishing easier. And making phishing easier makes fraud easier. This is like saying that improving web client security won't help reduce fraud. People don't say that so often since botnets started getting really big. From dzonatas at dzonux.net Tue Oct 2 17:42:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 17:40:15 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> References: <46FF248E.10305@lindenlab.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> Message-ID: <4702E569.6040200@dzonux.net> Argent Stonecutter wrote: > > On 02-Oct-2007, at 18:44, Dzonatas wrote: >> The best anti-phishing mechanism still does not solve the bottom line >> goal of anti-fraud. It is not just the login that matters, but there >> is the need to verify identity. > > And that's the user name and password. Real identity... not just account identity. To verify the account is the easy part. To verify the identity of the real person behind the account at any given time is what is more difficult, but it can be done without a username and password. -- Power to Change the Void From jessesa at gmail.com Tue Oct 2 17:59:42 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Oct 2 17:59:45 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4702E569.6040200@dzonux.net> References: <46FF248E.10305@lindenlab.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> <4702E569.6040200@dzonux.net> Message-ID: On 10/2/07, Dzonatas wrote: > > Argent Stonecutter wrote: > Real identity... not just account identity. To verify the account is > the easy part. To verify the identity of the real person behind the > account at any given time is what is more difficult, but it can be done > without a username and password. > After all of this discussion and people jumping through hoops making the wiki pages and all it comes down to this latest statement from Rob: "After talking to the team that's been working on this, I'm getting a better understanding of what the goal is. Unfortunately, there's only so much we can talk about at this point, other than to say that it's part of a necessary consolidation of entry points to the system. The main thing this accomplishes is the ability to leverage a number of well understood web technologies for login support, as well as well-understood back-end systems for managing it." Basically I take that to mean that: Viewer security is the least of what they are working on. LL is going to do what they said they were going to do anyways and we no longer have any real input into the matter. From this point on LL will make a few token responses such as answering the questions but that is all. First time I have ever made such a pessimistic statement concerning Linden Labs, but just the way I feel now. After over a year of lurking here in sldev, this was important enough to me to come out and fight for it. Now it seems it was all for nothing. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/a0684d6d/attachment.htm From dzonatas at dzonux.net Tue Oct 2 18:05:00 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 2 18:02:56 2007 Subject: [sldev] [PROPOSAL] Authentication Model In-Reply-To: References: <4702BD1F.7040609@dzonux.net> Message-ID: <4702EABC.2010704@dzonux.net> Harold Brown wrote: > The authentication model proposed by Linden Labs was nothing more or > less then exactly what my proposal was. A method to allow an > untrusted client the ability to log onto the grid without having > access to your full credentials. > As long as it randomly doesn't pull any of the images from one of the known ones, it can be useful. I'm sure you saw this: http://blog.secondlife.com/2007/10/02/new-captcha-system (and early slashdotted news) -- Power to Change the Void From rdw at lindenlab.com Tue Oct 2 18:03:29 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Oct 2 18:03:07 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> <4702E569.6040200@dzonux.net> Message-ID: <4702EA61.7030102@lindenlab.com> Jesse Barnett wrote: > Basically I take that to mean that: > > Viewer security is the least of what they are working on. LL is going to do > what they said they were going to do anyways and we no longer have any > real input into the matter. Aw, the very next thing he said was: "This is still early in the conversation, so don't panic about us being slower than you might like to discuss this." -RYaN From donovan at lindenlab.com Tue Oct 2 18:04:04 2007 From: donovan at lindenlab.com (Donovan Linden) Date: Tue Oct 2 18:04:42 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: In the long run, we want to implement some sort of runtime service description query ability, perhaps invoked using the OPTIONS verb. I believe zero talked about this in one of his office hours quite a while back, but we haven't started on this yet. I do have some code that I wrote with this use case in mind in the mulib/shaped.py module, but it's not really being used by anything yet. I'm not sure how this approach would be combined with one-shot capabilities; maybe they can notice OPTIONS and not expire. In both the short term and the long term, we definitely should be documenting the API of the client-accessible capabilities on the public wiki. As we go forward with the architecture working group, perhaps these API wiki pages could even be created before any of the code was written. As for the markup to describe the capabilities in the wiki in the near term, I think plain old LLSD should be fine. Something like: foo bar Thanks for pushing on this! We totally need a public love machine. Donovan On Oct 2, 2007, at 3:32 PM, John Hurliman wrote: > I merged my own documentation skeleton page on the wiki with the > "Protocol" page at http://wiki.secondlife.com/wiki/Protocol, this > is still the official home of all protocol documentation for Second > Life and I assume will be the closest thing there is to an official > specification of "How Second Life Works". > > Community driven documentation is going to be more important then > it was previously due to the way the protocol is changing. > Traditionally we had everything going over UDP and the format of > things was documented by a file called message_template.msg. This > allowed clients to either build packets and verify them at runtime > (such as the SL viewer) or pre-generate code to represent packets > in memory (such as libsecondlife). With the new capabilities system > we have no message_template.msg, and there is no way to pre- > generate code to represent message structures or verify the > correctness of code at runtime. Right now you can't even query what > capabilities are available to clients although this may change in > the future. > > The message_template party was fun while it lasted but we are going > to have to go back to the traditional method of development, > meaning good documentation that unit tests can be built from and > third party implementations can work off of, since runtime or > compile time verification is no longer possible. Linden Lab > internally uses the viewer and simulator source code for > documentation (I'm told), so if we want a specification the > community will be responsible for generating it. Some open questions: > > * Is the current structure of the page a good breakdown of the > different sections of the protocol? Should things be split up or > consolidated in any places? > * Since all of the capabilities will need to be described here we > need a standard markup to document them. Should the LLSD notation > format be used, or some other pseudo-markup? > > > For some background, this was discussed at Zero Linden's office > hour today (Zero was out but other Lindens filled in). The > conversation went something like this: > > LL: the capabilities API may not necessarily be the same as the old > message template > Me: so we need to hand-write new processing code for each > capability, unlike the old udp system > Others: wouldn't a server-side changelog fix this? > Me: if i understand right, things are transitioning from a system > where we have a file format detailing the structure of messages, to > a system where there is no documentation, no way of the client > knowing what it is supposed to handle or not, and no idea what > means what once you figure out the capabilities you are supposed to > handle > LL: we can't log every change, it would be cluttered and irrelevant > LL: the source code is very clear on how all of this works > Others: the viewer isn't documentation, it's GPL licensed source > code that is neither a preferred medium for documenting a protocol > nor a license-compatible method of providing docs > LL: it is very clear documentation > Me: so we can look through the SL viewer source code to learn how > things work and reimplement it in BSD licensed libsecondlife correct? > [13:31] Rob Linden: Eddy, as long as you don't steal code, yes > LL: so this whole discussion about documenting the capability API > is just so people can steal code? > Others: no, we don't want your source code. please keep it > Me: we would like documentation to write independent > implementations though > Others: independent implementations... part of that whole > architecture working group thing > > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From iridium at lindenlab.com Tue Oct 2 18:05:15 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Tue Oct 2 18:06:20 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: References: <4702C702.1030100@wsu.edu> Message-ID: <4702EACB.6000709@lindenlab.com> Donovan, yeah, we really do re: public love machine. Donovan Linden wrote: > In the long run, we want to implement some sort of runtime service > description query ability, perhaps invoked using the OPTIONS verb. I > believe zero talked about this in one of his office hours quite a > while back, but we haven't started on this yet. I do have some code > that I wrote with this use case in mind in the mulib/shaped.py module, > but it's not really being used by anything yet. I'm not sure how this > approach would be combined with one-shot capabilities; maybe they can > notice OPTIONS and not expire. > > In both the short term and the long term, we definitely should be > documenting the API of the client-accessible capabilities on the > public wiki. As we go forward with the architecture working group, > perhaps these API wiki pages could even be created before any of the > code was written. > > As for the markup to describe the capabilities in the wiki in the near > term, I think plain old LLSD should be fine. Something like: > > > foo > > bar > > > > Thanks for pushing on this! We totally need a public love machine. > > Donovan > > On Oct 2, 2007, at 3:32 PM, John Hurliman wrote: > >> I merged my own documentation skeleton page on the wiki with the >> "Protocol" page at http://wiki.secondlife.com/wiki/Protocol, this is >> still the official home of all protocol documentation for Second Life >> and I assume will be the closest thing there is to an official >> specification of "How Second Life Works". >> >> Community driven documentation is going to be more important then it >> was previously due to the way the protocol is changing. Traditionally >> we had everything going over UDP and the format of things was >> documented by a file called message_template.msg. This allowed >> clients to either build packets and verify them at runtime (such as >> the SL viewer) or pre-generate code to represent packets in memory >> (such as libsecondlife). With the new capabilities system we have no >> message_template.msg, and there is no way to pre-generate code to >> represent message structures or verify the correctness of code at >> runtime. Right now you can't even query what capabilities are >> available to clients although this may change in the future. >> >> The message_template party was fun while it lasted but we are going >> to have to go back to the traditional method of development, meaning >> good documentation that unit tests can be built from and third party >> implementations can work off of, since runtime or compile time >> verification is no longer possible. Linden Lab internally uses the >> viewer and simulator source code for documentation (I'm told), so if >> we want a specification the community will be responsible for >> generating it. Some open questions: >> >> * Is the current structure of the page a good breakdown of the >> different sections of the protocol? Should things be split up or >> consolidated in any places? >> * Since all of the capabilities will need to be described here we >> need a standard markup to document them. Should the LLSD notation >> format be used, or some other pseudo-markup? >> >> >> For some background, this was discussed at Zero Linden's office hour >> today (Zero was out but other Lindens filled in). The conversation >> went something like this: >> >> LL: the capabilities API may not necessarily be the same as the old >> message template >> Me: so we need to hand-write new processing code for each capability, >> unlike the old udp system >> Others: wouldn't a server-side changelog fix this? >> Me: if i understand right, things are transitioning from a system >> where we have a file format detailing the structure of messages, to a >> system where there is no documentation, no way of the client knowing >> what it is supposed to handle or not, and no idea what means what >> once you figure out the capabilities you are supposed to handle >> LL: we can't log every change, it would be cluttered and irrelevant >> LL: the source code is very clear on how all of this works >> Others: the viewer isn't documentation, it's GPL licensed source code >> that is neither a preferred medium for documenting a protocol nor a >> license-compatible method of providing docs >> LL: it is very clear documentation >> Me: so we can look through the SL viewer source code to learn how >> things work and reimplement it in BSD licensed libsecondlife correct? >> [13:31] Rob Linden: Eddy, as long as you don't steal code, yes >> LL: so this whole discussion about documenting the capability API is >> just so people can steal code? >> Others: no, we don't want your source code. please keep it >> Me: we would like documentation to write independent implementations >> though >> Others: independent implementations... part of that whole >> architecture working group thing >> >> >> John Hurliman >> _______________________________________________ >> 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 jhurliman at wsu.edu Tue Oct 2 18:06:36 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 18:06:25 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4702EA61.7030102@lindenlab.com> References: <46FF248E.10305@lindenlab.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> <4702E569.6040200@dzonux.net> <4702EA61.7030102@lindenlab.com> Message-ID: <4702EB1C.3040207@wsu.edu> Ryan Williams (Which) wrote: > Jesse Barnett wrote: > >> Basically I take that to mean that: >> >> Viewer security is the least of what they are working on. LL is going to do >> what they said they were going to do anyways and we no longer have any >> real input into the matter. >> > > Aw, the very next thing he said was: > > "This is still early in the conversation, so don't panic about us being > slower than you might like to discuss this." > > -RYaN I think it is still important to point out the gross miscommunication that happened here. LL is working on something to reduce fraud by consolidating their login services, someone misunderstood this to mean they were trying to make the login process more secure, and about 100 e-mails of argument were generated as a result. There are some legitimate concerns (that could probably be addressed without scrapping anything) buried deep deep deep inside the largest off-topic thread on sldev yet. John Hurliman From secret.argent at gmail.com Tue Oct 2 18:18:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 18:18:47 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: OK, that conversation strikes at the very heart of the distinction between "Open Source" and "Open Systems". If the source is the only documentation for the system, then there is no open documentation for the system, and it's not possible for it to be treated as an "Open System". It's an open source implementation of a proprietary system... in that the system is the property of whoever controls the source code to the "real" implementation. If you know the protocol, you can implement something to talk to it or act like it or whatever, and you don't need anyone's source code to do it. If you can do that and get a system that keeps working through multiple generations of the system, because the people implementing it are sticking to the standard, then what you have is an open system. If you don't know the protocol, and you have the source code, you can guess what the protocol is... but if there's no spec, and no commitment to backwards compatibility, you're in trouble. You're stuck with tracking someone else's source. Both Open Source and Open Systems are valuable, but don't confuse one for the other. SL is a proprietary system, not an open one. From tateru.nino at gmail.com Tue Oct 2 18:19:13 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 2 18:19:16 2007 Subject: [sldev] Re: Goals for viewer authentication In-Reply-To: <4702C612.9050705@lindenlab.com> References: <47016CFE.1060509@lindenlab.com> <2DBB00F5-068C-401C-9F2A-597074396749@gmail.com> <4701A1D8.7060808@gmail.com> <4702C612.9050705@lindenlab.com> Message-ID: <4702EE11.9000208@gmail.com> Rob Lanphier wrote: > On 10/1/07 6:41 PM, Tateru Nino wrote: > >> One of the things about the proposed viewer authentication that I'm hazy >> on is Linden Lab's actual _goals_ for the new system. Most of what I've >> seen is assumption of goals, or allusion to goals. It occured to be >> today, reading through the viewer critique that a lot of the goals seem >> to be the ones we _assume_ Linden Lab to have for the system. >> >> What, exactly is the bulleted list of goals that a change to the >> authentication system is to meet? I mean, we can criticize the system >> generally - but we can't necessarily propose one that is more acceptable >> to Linden Lab unless we're sure of their acceptance criteria, no? >> Otherwise we're talking in circles hoping to stumble on something that's >> acceptable by happy accident. >> >> > > After talking to the team that's been working on this, I'm getting a > better understanding of what the goal is. Unfortunately, there's only > so much we can talk about at this point, other than to say that it's > part of a necessary consolidation of entry points to the system. The > main thing this accomplishes is the ability to leverage a number of well > understood web technologies for login support, as well as > well-understood back-end systems for managing it. > Devil=>details. :) Okay, so there's confidential and/or potentially undecided stuff or stuff linked to stuff that is perhaps confidential, and that can't be talked about. There's bound to be a quite a number of resident-friendly solutions that will be completely incompatible with LL's internal goals, though. Obviously we don't want to burn a ton of threads on those. Anything we can get to weed out and head-off unproductive discussion tracks would be a bonus. Saves LL time. Saves us time. Everyone wins. Not asking for confidential or privileged info. Just want to get what we _can_ have, to make sure we're all not wasting our time arguing the finer points of the completely non-useful. -- Tateru Nino http://dwellonit.blogspot.com/ From tateru.nino at gmail.com Tue Oct 2 18:28:40 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 2 18:28:45 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: <4702F048.7050900@gmail.com> John Hurliman wrote: > > LL: we can't log every change, it would be cluttered and irrelevant For heaven's sake _please_ inundate us with this irrelevant clutter. Other people will sift and sort it. -- Tateru Nino http://dwellonit.blogspot.com/ From tateru.nino at gmail.com Tue Oct 2 18:35:31 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 2 18:35:37 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: <4702F1E3.5080700@gmail.com> Okay, once more, with feeling :) John Hurliman wrote: > LL: the source code is very clear on how all of this works No. Actually, it's exactly *not* that. The source code shows exactly what the viewer *does*. No more, and no less. It doesn't tell you what features/capabilities are available for use from the services side that the viewer may not presently use. It doesn't tell you what is intended or correct. It only tells you what subset the viewer implements *today* - some of which may well work by happy accident, rather than by design (remember we've had some bugfixes that were just that - where the data and the viewer were talking completely different formats but it worked by accident despite this). In the future, we assume that more functionality will be available from the web-services than any given viewer implementation will actually be using at any given time. This may already be the case (and quite likely is). There's no way for an implementer to find out, except to see the very narrow use-cases currently implemented in the official viewer source. -- Tateru Nino http://dwellonit.blogspot.com/ From ryan at ngigroup.com Tue Oct 2 20:44:41 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Tue Oct 2 20:43:00 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <37941B29-FB20-43AF-90AA-BB0C663F11B2@gmail.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191295130.3045.54.camel@localhost.localdomain> <37941B29-FB20-43AF-90AA-BB0C663F11B2@gmail.com> Message-ID: <47031029.4080301@ngigroup.com> First a word of advice: your style of communication is very flippant. Im not sure if you intend it so, but it comes across as off-putting, to put it mildly. You might consider how this helps or hurts your causes. Argent Stonecutter wrote: > On 01-Oct-2007, at 22:18, Ryan McDougall wrote: >> I propose that an out of process PKI library be used to transfer an >> temporary authorization token to the client viewer. Once the token has >> been handed to the viewer, then the viewer can do anything to the user's >> account. We rely on the server and the PKI system to only hand the token >> off when the Private Key, located on the user's machine, matches the >> Public Key stored on the LL server (given over SSL during registration). > >> The security of the system would rely on the assumption that a >> compromised viewer cannot break the OS's security, and access the >> Private Key. > > If the user has downloaded the viewer (voluntarily, by his choice) then > why would the user prevent the viewer he downloaded from getting to the > private key he created? The viewer is expected to be able to read this > key. It doesn't matter whether the viewer is from Linden Labs or J > Random hacker, the user's GOT to be able to grant it the rights to get > whatever information it needs to log in to Second Life, otherwise why is > he downloading it? It doesn't matter whether those rights are granted by > typing in his password or by right-clicking on an icon and selecting > "Allow this program to access my keychain" or by responding to a dialog > from teh OS when it asks to access the keychain. The user has downloaded > and installed the package, because the user wants to use it to play > Second Life. The case I was thinking of if was one where the compromised viewer would harvest your account information to give to a 3rd party for later use. In that case it would fail because the 3rd party would lack your private key. You are right about a compromised viewer would just immediately transfer your money to another account while it holds a valid token. Thats why the viewer should be signed. > This isn't like your wife's Chase bank account, because your wife isn't > downloading a third party Chase Bank Account Viewer. I don't know what youre talking about. My wife, as a programmer for mission critical trading systems for an investment bank that is as yet unnamed, worked from home using a Java applet + Terminal Server. I don't know how it all worked exactly, but Im pretty sure it was the RSA dongle she used that made it secure, not the fact that the applet was closed source. From ryan at ngigroup.com Tue Oct 2 20:54:02 2007 From: ryan at ngigroup.com (Ryan McDougall) Date: Tue Oct 2 20:52:10 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191294300.3045.42.camel@localhost.localdomain> Message-ID: <4703125A.6010105@ngigroup.com> Argent Stonecutter wrote: > On 01-Oct-2007, at 22:05, Ryan McDougall wrote: >> On Mon, 2007-10-01 at 21:38 -0500, Argent Stonecutter wrote: >>> If you have a compromised SL viewer you don't have to attack >>> anything. You already have the golden ring, you've won. > >> Actually I thought the goal was to protect the user's valuables, >> specifically L$, but also his in game assets. > > Which is what a compromised SL viewer gives you. The whole "oh no, it > can steal your password" schtick is a red herring. > >> Only if you care if your users get told that they may be running an >> unknown viewer. > > OK, let me get this straight. You don't have it straight. I suspect you're not making much effort to. > If my viewer is legitimate but I haven't got a certificate, the LL > server will send the viewer a message to tell the user that the viewer > may not be legitimate, which being legitimate, I'll pass on to them. Yes, and you presumedly won't care, because you didnt bother to take 5 minutes to sign your own "legit" viewer. > If my viewer is crocked, the LL server will still send the viewer a > message, but the crocked viewer will hide it, and thus it will appear > more legitimate than the legitimate viewer that hasn't jumped through > the certificate hoops. As has been said, there is more than one way besides the naive method. You could print a warning on the SL website, or put it in-world. While neither method is perfection-on-wheels, its better than nothing. >> If you care and have a large user base, you download GPG >> and create a key, then publish it -- that simple. > > That doesn't do anything more to help Linden Labs "track me down" unless > I need to do more than that. If the viewer on my website is crocked, > they've got me. If the viewer is crocked and signed by a private key, > and I've put the public key on my website, well... the only thing > they've got is what they started with... it was distributed from my > website. This would protect people from getting a package from Joe's BBS > that claimed to be from Linden Labs, sure, but we don't distribute > software that way on the Internet... you don't go to Joe's BBS to > download the SL client, you go to secondlife.com. The purpose isnt to verify the physical whereabouts of an individual in geographical space in the case of viewer corruption. The purpose is to your identity as a legitimate viewer maker. People who don't sign their viewer arent corrupt, but people who can have their identity vouched for, at least in the long term. Identity in the real world works the same. If I say my name is Ryan McDougall, and I am unknown to you, its meaningless to identify myself. But if I am a good person, and garner a reputation as such, in time, identifying myself as Ryan McDougall would eventually lead people to trust me on identity alone. >> All the linux distros' package security currently works like this. > > Ah, that's right, Linux does have half a dozen crack-brained packaging > schemes that involve trusting third-party repositories, harking back to > the days when Linus was using well-known FTP servers like BBSes instead > of running his own site, and because Linux doesn't actually have a core > OS... it's thousands of packages flying in close formation. That doesn't > apply here, because that's not how software gets distributed outside the > Linux world. > > Unless Linden Labs does the signing, this wouldn't provide any more > assurance for Joe's Viewer than the fact that it was downloaded from the > website where joe published his public key. I don't believe you are actually making the required attempt to understand the positions of the people you are talking at, so I dont believe it is productive to continue this conversation. From gigstaggart at gmail.com Tue Oct 2 20:57:31 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Oct 2 20:57:31 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: References: <4702C702.1030100@wsu.edu> Message-ID: <4703132B.3030006@gmail.com> Argent Stonecutter wrote: > OK, that conversation strikes at the very heart of the distinction > between "Open Source" and "Open Systems". Be patient. Projects like libsl and opensim will "keep LL honest". It's not unprecedented for an open standard to start out as de facto, in fact that's how most of them get going. It's not going to hurt anything in the near term to use source for documentation. Long term that needs to change of course, but really, don't sweat it for now. -Jason From secret.argent at gmail.com Tue Oct 2 21:01:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 21:01:45 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <47031029.4080301@ngigroup.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191295130.3045.54.camel@localhost.localdomain> <37941B29-FB20-43AF-90AA-BB0C663F11B2@gmail.com> <47031029.4080301@ngigroup.com> Message-ID: <692202DC-AD44-4A77-9346-3529A08FB291@gmail.com> On 02-Oct-2007, at 22:44, Ryan McDougall wrote: > First a word of advice: your style of communication is very flippant. It's supposed to be, the alternative for me is being so stuffy that you'll fall asleep halfway through the first sentence. I've put entire small villages to sleep by trying to be serious. >> This isn't like your wife's Chase bank account, because your wife >> isn't downloading a third party Chase Bank Account Viewer. > I don't know what youre talking about. My wife [works for a bank, > from home, etc...] Honest, mister, I didn't know your wife actually worked for a bank. My blushes etc... OK, it's not like your granny's Paypal account. When J Random Customer logs onto their household banking account on the web, or paypal, they do it using an account number and a password, and MAYBE an extra verification step if the bank's particularly on the ball. And they do it in a regular web browser, not a special Paypal Account Viewer. From zha.ewry at gmail.com Tue Oct 2 21:37:33 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Tue Oct 2 21:37:37 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4703132B.3030006@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> Message-ID: <920d7d850710022137t49e680ffi3144172ec7a9cd26@mail.gmail.com> Short term, sure, what Linden does, is largely what can be done. But. likewise don't mistake doing that for doing architecture. There is a huge leap from codifying current practices to actually designing an extensible architecture, of which the current system is but one exemplar. An open system, with flexibility, cannot be captured by just code, not even many, many examples. The contracts which define the system's behavior need to be articulated. The range of possible parameters, the acceptable sequences of calls, the possible responses all need to be enumerated. Further, it isn't just a matter of describing all the services, one after the other. It is necessary to describe the dependencies between them. "You must pass in a capability for this operation, one that is current, from the domain of the service being subordinately invoked, and you may receive either the result you expect or a capability to invoke which will perform the operation." for example,may be one part of such a description. I don't expect this to happen at once. In fact, that would likely be fatally wrong. There is however, a reasonable progression likely need be followed. For example, the c-http specification as described in the wiki gets closer to being real documentation. Similar pages, for all the proposed core underlying protocols, coupled with some rigorous definitions of terms, such as "capability" would help ground the exercise of describing all the interactions we expect to enumerate. Ideally, that, coupled with sample implementations and sample services, starting with a full "echo" and other trivial services, and building up to more complex examples would go a long way to help us both pin down the proposed building blocks, and define a level of documentation and design rigor which will lead to a genuine open architecture and design, not a mere capturing of what Linden is building. - Zha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/230d25a5/attachment.htm From secret.argent at gmail.com Tue Oct 2 22:07:06 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 22:06:59 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4703125A.6010105@ngigroup.com> References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191294300.3045.42.camel@localhost.localdomain> <4703125A.6010105@ngigroup.com> Message-ID: <9D5CFB37-BEAA-4981-9BAA-97B5A42F0C10@gmail.com> On 02-Oct-2007, at 22:54, Ryan McDougall wrote: > While neither method is perfection-on-wheels, its better than nothing. It's solving a problem that nobody has demonstrated actually needs solving, and that's a lot harder to solve than you seem to think. If demanding evidence that it's worthwhile trying (like, providing an example of a real situation where it would have prevented an exploit) is "not listening", then I guess I'm not listening. Sorry. From secret.argent at gmail.com Tue Oct 2 22:13:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 2 22:12:54 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4703132B.3030006@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> Message-ID: <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> On 02-Oct-2007, at 22:57, Jason Giglio wrote: > Argent Stonecutter wrote: >> OK, that conversation strikes at the very heart of the distinction >> between "Open Source" and "Open Systems". > Be patient. Projects like libsl and opensim will "keep LL honest". Like Samba does for Microsoft? Andrew's not forcing Microsoft to follow their specs, he's chasing their changes. > It's not unprecedented for an open standard to start out as de > facto, in fact that's how most of them get going. Some of them... don't forget, there's a lot of open source projects that are considered "standards" that are nothing like Open Systems. But what really bugs me is that when you see one moving from a documented protocol to an ad-hoc one, that's not a good sign. From hud at zurich.ibm.com Tue Oct 2 22:25:20 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 2 23:02:12 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: References: <46FF248E.10305@lindenlab.com> <46FFC6AA.2050004@dzonux.net> <934524C4-CD0A-4C55-BD5D-9D11C1572569@gmail.com> <46FFD4A9.7090503@dzonux.net> <23bbb49e0709301220mbc65dfdx36d038110a274067@mail.gmail.com> <23bbb49e0709301553y1bd6a5d1j164b9a0678d03cc3@mail.gmail.com> <47003AEB.6060601@dzonux.net> <5A97A8D8-0067-48FD-9D28-AC386C5E3523@gmail.com> <47005697.50502@dzonux.net> <1191230378.3023.29.camel@localhost.localdomain> <329F6BBA-2C4C-43C0-AC7B-316AB8AC4BD6@gmail.com> <1191287344.3045.12.camel@localhost.localdomain> <91C52677-A0A9-4EFC-83E7-68AE2DB78194@gmail.com> <1191294300.3045.42.camel@localhost.localdomain> Message-ID: <470327C0.1050108@zurich.ibm.com> Argent Stonecutter wrote: > On 01-Oct-2007, at 22:05, Ryan McDougall wrote: > [...] >> Only if you care if your users get told that they may be running an >> unknown viewer. > > OK, let me get this straight. > > If my viewer is legitimate but I haven't got a certificate, the LL > server will send the viewer a message to tell the user that the viewer > may not be legitimate, which being legitimate, I'll pass on to them. > > If my viewer is crocked, the LL server will still send the viewer a > message, but the crocked viewer will hide it, and thus it will appear > more legitimate than the legitimate viewer that hasn't jumped through > the certificate hoops. to be fair, LL could send that message via email; that is, out-of-band. how much good that would do is another issue... [...] >> All the linux distros' package security currently works like this. > > Ah, that's right, Linux does have half a dozen crack-brained packaging > schemes that involve trusting third-party repositories, harking back > to the days when Linus was using well-known FTP servers like BBSes > instead of running his own site, and because Linux doesn't actually > have a core OS... it's thousands of packages flying in close > formation. That doesn't apply here, because that's not how software > gets distributed outside the Linux world. > > Unless Linden Labs does the signing, this wouldn't provide any more > assurance for Joe's Viewer than the fact that it was downloaded from > the website where joe published his public key. again, to be fair: with well-known keys that does work. you are right that the mechanism alone is no guarantee at all --- also, with the linux distros the signature does not guarantee that the code is bona fide (i.e., not doing anything on the shady side of things), it just guarantees that the package has not been tampered with since it left the hands of the signer... it could carry the guarantee semantics but nobody in their right mind is going to do that... the real question is: does LL want to become involved in vetting viewer code? if i were LL i'd rather spend my resources on more promising and profitable things. code signing is nice to guarantee integrity, but that's about it, i'd claim. cheers dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Tue Oct 2 22:16:23 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 2 23:02:14 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <470257D6.1060101@blueflash.cc> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> <47024CE3.5020707@gmail.com> <470257D6.1060101@blueflash.cc> Message-ID: <470325A7.2090400@zurich.ibm.com> Nicholaz Beresford wrote: > > Tateru Nino wrote: >>> ----------------------------------------------------------------- >>> >>> Password manager for Nicholaz Beresford >>> >>> Forum Wiki Account inworld-restricted inworld-full >>> aaa111 [x] [x] [ ] [x] [ ] >>> q$44&9A [ ] [ ] [x] [ ] [x] >>> >>> [add Password] >>> >>> ----------------------------------------------------------------- >>> >> Personally, I'd like to get out-of-band confirmation for the exercise of >> capabilities. An email with a link, for example, before rezzing an >> object, or doing anything that debits my account, or much else other >> than walking and talking. So I can configure which ones are always on, >> never on, or that the system has to ask me out-of-band to grant for the >> rest of the session. hmm...getting an email for rezzing objects sounds to me a bit...well...clunky. and it certainly breaks any immersive experience. not sure we want that (well, i don't for one). > > Only if you can't use the password (the one which you gave the viewer) > to reconfigure these options. If 3rd party viewer security is the goal, > the only way to enforce that, is (like everything these days) server > side by not allowing the viewer to do specific things. in the end it comes down to trust: whose viewer do we trust? i'd trust a viewer that's available as open source and has been widely vetted and examined for security holes. i'd probably have my reservations about joe random's viewer-from-the-basement that's closed source and was just released yesterday...i might trust a viewer that i've written (then again, knowing me, i might not). cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From jhurliman at wsu.edu Tue Oct 2 23:59:18 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 2 23:59:07 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: <47033DC6.3070105@wsu.edu> John Hurliman wrote: > Community driven documentation is going to be more important then it > was previously due to the way the protocol is changing. Traditionally > we had everything going over UDP and the format of things was > documented by a file called message_template.msg. This allowed clients > to either build packets and verify them at runtime (such as the SL > viewer) or pre-generate code to represent packets in memory (such as > libsecondlife). With the new capabilities system we have no > message_template.msg, and there is no way to pre-generate code to > represent message structures or verify the correctness of code at > runtime. Right now you can't even query what capabilities are > available to clients although this may change in the future. For people following the libsl side of things, I just finished a method that uses some C# reflection magic to convert arbitrary LLSD to a Packet class, assuming that everything in the LLSD lines up with how it is in the message_template.msg file. So far I think this is the case, at least for the ones I've tested including the latest AgentGroupDataUpdate. Once capability messages with the same names as packets start deviating from the template we'll have to throw in custom handlers, but I think this should catch a lot of future server upgrades. The idea about using the OPTIONS method to document CAPS sounds perfect though, this would be a great feature in a long term architecture. John From seg at haxxed.com Wed Oct 3 00:20:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 00:20:20 2007 Subject: [sldev] Re: Packaging the viewer for Linux distributions In-Reply-To: <47013253.5000301@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> Message-ID: <1191396008.11151.58.camel@localhost> On Mon, 2007-10-01 at 10:45 -0700, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > > Which is why LL should focus on working with Linux distributions to get > > Second Life into the distributions themselves, rather than distributing > > binary blobs. > > We're happy to see people packaging the viewer for different Linux > distributions (for example, I'm watching the Fedora packaging tasks), > and willing to help out where we can. I've done quite a bit of work to > make it easier to build a standalone viewer, for example. Yes, you've been doing a wonderful job fixing my complaints. :) > If there are specific things you'd like to see done, file JIRA tasks, > and we'll plug away at them as the opportunity presents itself. If you > want to file an umbrella task and connect the subtasks to it so that > it's easier to see which ones are intended to ease distro integration, > all the better. Not a bad idea. > Obviously, there are enough distros out there that we can't devote > significant resources to each one individually, but that doesn't mean we > lack enthusiasm for the idea. Tell us how we can help you most > effectively, and we'll pitch in. Well, what we have here is more a matter of perception. I really hope its understandable what it looks like from our side when we're presented with a proposal that seems to boil down to "Linden Lab does not trust third party viewers and neither should anyone else". Even though I personally don't consider myself distributing a "third party" viewer. My own concern really is if Linden Labs agrees with my view. Fedora's policy is to avoid deviating from upstream and I attempt to follow this policy as much as possible. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/e6f313c6/attachment.pgp From mike at flat222.org Wed Oct 3 00:49:22 2007 From: mike at flat222.org (Mike Welch) Date: Wed Oct 3 00:49:25 2007 Subject: [sldev] [SVC] Webmap API changed? In-Reply-To: <73e978f20709300356n2ad70645u462d3e75e4cd0d12@mail.gmail.com> References: <73e978f20709300356n2ad70645u462d3e75e4cd0d12@mail.gmail.com> Message-ID: <73e978f20710030049kd00caa6y6d8c1ab6e9827927@mail.gmail.com> Hi, Does anyone know if there's been a change to the Webmap API? Suddenly all my maps have stopped working. I think it's related to the SLPoint method which now seems to be non-functional. Looking at SLUrl.com and the auctions it looks like LL have moved to the Google Maps API, but I've not seen an announcement about it and the rest of the existing API seems to still work, just not SLPoint(). Looking at those maps, they don't appear to use SLPoint, is there an alternative method for going from (region,localx,localy) to (globalx, globaly)? Anyone got any clues? Thanks Mike (Hinkley Baldwin) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/54b5d67b/attachment.htm From matthew.dowd at hotmail.co.uk Wed Oct 3 01:26:21 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Oct 3 01:26:23 2007 Subject: [sldev] OpenID & SSL certificates In-Reply-To: <4702EB1C.3040207@wsu.edu> References: <46FF248E.10305@lindenlab.com> <1191287868.3045.20.camel@localhost.localdomain> <47025E52.9090509@dzonux.net> <470282BD.5030508@dzonux.net> <1C6DDEF0-30A9-4DEA-8D6E-124B2EE33A61@gmail.com> <4702D7CE.401@dzonux.net> <53370780-B508-4DED-A59C-5BCC7FA045AA@gmail.com> <4702E569.6040200@dzonux.net> <4702EA61.7030102@lindenlab.com> <4702EB1C.3040207@wsu.edu> Message-ID: > I think it is still important to point out the gross miscommunication > that happened here. LL is working on something to reduce fraud by > consolidating their login services, someone misunderstood this to mean > they were trying to make the login process more secure, and about 100 > e-mails of argument were generated as a result. There are some > legitimate concerns (that could probably be addressed without scrapping > anything) buried deep deep deep inside the largest off-topic thread on > sldev yet. Security, Persistence and Flexibility were the three headings LL used in their original wiki page on the subject. Under security anti-fraud was mentioned but the only concrete example of how the new mechanism would actually help prevent/detect fraud was third party password capture. It was inevitable that after this was dismissed (if the web page is displayed via an embedded web client, then username/password can still be captured since the third party has access to the source code for the embedded web client; this isn't really the main security issue with third party or indeed LL clients), that discussion for other ways of improving security would be discussed. Reading the new CAPTCHA blog entry, I'm guessing that one thing LL may be thinking of is introducing CAPTCHAs into the client side login process *after* a failed logon attempt. This would add protection against automated dictionary attackes on usernames and passwords - although I would hope that LL already has mechanisms for detecting such activity. However, this is not the only way this could be achieved. One mechanism might be that after three failed logon attempts, the account is locked and generates a message "You account has been temporarily locked due to too many invalid logon attempts. To unlock your account, please logon to your account pages via the website" - the website login could have various additional checks (e.g. CAPTCHA's, confirmation of date of birth etc.) before the account is unlocked. Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/d84c5dd4/attachment.htm From nik at terminaldischarge.net Wed Oct 3 03:11:02 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Wed Oct 3 03:11:08 2007 Subject: [sldev] CAPTCHA to validate land sales. Message-ID: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> On the capthcha blog post, someone made a comment "Any plans to leverage that into using it inworld for land sales?" As in using captcha inworld to validate land sales. I think this was actually a great idea. How about you guys? From tshephard at gmail.com Wed Oct 3 04:50:09 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Oct 3 04:50:12 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> Message-ID: <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> I'm not sure it would change things much. I'm sure there are lot of people who are happy to type in the captcha as they like to verify the deal they're about to make. On 10/3/07, nik@terminaldischarge.net wrote: > On the capthcha blog post, someone made a comment > "Any plans to leverage that into using it inworld for land sales?" > > As in using captcha inworld to validate land sales. > > I think this was actually a great idea. > > How about you guys? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From corax at ravenscall.net Wed Oct 3 05:16:37 2007 From: corax at ravenscall.net (Corax) Date: Wed Oct 3 05:03:23 2007 Subject: [sldev] High-prim vehicles using phantom (Re: Havok4...) In-Reply-To: References: Message-ID: <47038825.8000003@ravenscall.net> Dale Mahalko wrote: > When such a linkset is set to be physical, we already know that > phantom objects can't be physical so those objects within the set can > simply be ignored for the mass / collision / center-of-gravity > calculations. Last time I checked phantom objects could also be physical. Set an object on the top floor of a multi-floor building, set it to phantom and physical, and watch it fall through every floor to the ground beneath the building! Corax From dimitrio at dimitriolewis.com Wed Oct 3 05:16:18 2007 From: dimitrio at dimitriolewis.com (Dimitrio Lewis) Date: Wed Oct 3 05:15:31 2007 Subject: [sldev] CAPTCHA to validate land sales. References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> Message-ID: <001601c805b7$350986f0$33a30650@INFOTECH> Personally I think that a captcha for land sales would be time consuming and might actually increase the chance of mistakes as people rush to fill in the sequence without taking the time to check the price they entered, or confusing them with too many dialog boxes on the screen. However, what if all your land sales were added to a queue and weren't activated until you reviewed the final list and confirmed that the prices you entered were correct? The list could even allow sorting by L$/sq.m and permit on-the-fly edits. Captcha for land purchase might defeat land bots, which many would consider a good move. ~ Dimi From dale at daleglass.net Wed Oct 3 05:32:14 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 05:32:20 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <470325A7.2090400@zurich.ibm.com> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> <47024CE3.5020707@gmail.com> <470257D6.1060101@blueflash.cc> <470325A7.2090400@zurich.ibm.com> Message-ID: <20071003123214.GB26201@bruno.sbruno> On Wed, Oct 03, 2007 at 07:16:23AM +0200, dirk husemann wrote: > >> Personally, I'd like to get out-of-band confirmation for the exercise of > >> capabilities. An email with a link, for example, before rezzing an > >> object, or doing anything that debits my account, or much else other > >> than walking and talking. So I can configure which ones are always on, > >> never on, or that the system has to ask me out-of-band to grant for the > >> rest of the session. > hmm...getting an email for rezzing objects sounds to me a > bit...well...clunky. and it certainly breaks any immersive experience. > not sure we want that (well, i don't for one). Doesn't have to be mail. A log visible on the website could be nice for example. > > > > Only if you can't use the password (the one which you gave the viewer) > > to reconfigure these options. If 3rd party viewer security is the goal, > > the only way to enforce that, is (like everything these days) server > > side by not allowing the viewer to do specific things. > in the end it comes down to trust: whose viewer do we trust? i'd trust a > viewer that's available as open source and has been widely vetted and > examined for security holes. i'd probably have my reservations about joe > random's viewer-from-the-basement that's closed source and was just > released yesterday...i might trust a viewer that i've written (then > again, knowing me, i might not). A bit pedantic: The source is under the GPL2, which means source MUST be released. LL could sue for copyright infringement anybody who refused to provide the source. Then of course I doubt it'll get to that, as since as per GPL2 the source must be open, anybody refusing to show the source is obviously hiding something. But, even if I'm trusted, I'd still like to have this mechanism. Maybe one day I'll screw up and accidentally release a viewer that does something nasty. Permissions and logs would be very helpful in this case. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/5abfc20a/attachment.pgp From dale at daleglass.net Wed Oct 3 05:38:43 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 05:38:47 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <001601c805b7$350986f0$33a30650@INFOTECH> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> Message-ID: <20071003123843.GC26201@bruno.sbruno> On Wed, Oct 03, 2007 at 01:16:18PM +0100, Dimitrio Lewis wrote: > Captcha for land purchase might defeat land bots, which many would consider > a good move. Why do they need to be defeated? Currently it's pretty much impossible to accidentally set land for sale. The seller has to go through multiple steps that are impossible to do accidentally. So by now all the land on sale must have been intentionally set for sale. If that's the case, does it matter who or what buys it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/420b43a8/attachment.pgp From elio at magetech.com Wed Oct 3 08:43:22 2007 From: elio at magetech.com (Elio Maggini) Date: Wed Oct 3 05:42:30 2007 Subject: : Re: [sldev] CAPTCHA to validate land sales. References: <20071003120326.F124E41B391@stupor.lindenlab.com> Message-ID: <00b101c805d4$22969a40$6401a8c0@ownerhiigdyfkh> IMHO, make something that is fool proof.....and only a fool will use it..... From nicholaz at blueflash.cc Wed Oct 3 06:09:33 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Oct 3 06:09:42 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003123843.GC26201@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> Message-ID: <4703948D.6090608@blueflash.cc> I think it will defeat the bots. The suggestion on the JIRA is for land purchases I think. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dale Glass wrote: > On Wed, Oct 03, 2007 at 01:16:18PM +0100, Dimitrio Lewis wrote: >> Captcha for land purchase might defeat land bots, which many would consider >> a good move. > > Why do they need to be defeated? > > Currently it's pretty much impossible to accidentally set land for sale. > The seller has to go through multiple steps that are impossible to do > accidentally. > > So by now all the land on sale must have been intentionally set for > sale. If that's the case, does it matter who or what buys it? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Wed Oct 3 06:36:56 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 06:37:01 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <4703948D.6090608@blueflash.cc> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> Message-ID: <20071003133656.GD26201@bruno.sbruno> On Wed, Oct 03, 2007 at 03:09:33PM +0200, Nicholaz Beresford wrote: > > I think it will defeat the bots. The suggestion on the > JIRA is for land purchases I think. I'm sure it will, what I'm asking here, do we really need to defeat them? Now that it's pretty much impossible to set land for sale accidentally, why do we need to stop bots from buying land? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/b89aeb1d/attachment.pgp From hud at zurich.ibm.com Wed Oct 3 06:40:33 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 3 06:40:40 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> Message-ID: <47039BD1.2050805@zurich.ibm.com> Argent Stonecutter wrote: > On 02-Oct-2007, at 22:57, Jason Giglio wrote: >> Argent Stonecutter wrote: >>> OK, that conversation strikes at the very heart of the distinction >>> between "Open Source" and "Open Systems". > >> Be patient. Projects like libsl and opensim will "keep LL honest". > > Like Samba does for Microsoft? Andrew's not forcing Microsoft to > follow their specs, he's chasing their changes. hmm...i think by opening up the discussion about the future architecture and by starting an architecture working group, LL is showing a substantial amount of openess --- and i trust them that they are dead serious about this. so, in the long run we will have public specs that were developed in the open. ...and the long run has just started. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From dimitrio at dimitriolewis.com Wed Oct 3 06:46:01 2007 From: dimitrio at dimitriolewis.com (Dimitrio Lewis) Date: Wed Oct 3 06:45:18 2007 Subject: [sldev] CAPTCHA to validate land sales. References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> Message-ID: <002501c805c3$bda13740$33a30650@INFOTECH> Unfortunately sale mistakes are quite common. I don't know the full psychology behind it, but I imagine the causes include confusion, language barrier, sleep deprivation, dyslexia (which we all have to some degree), and an automated mental state caused by the monotony of listing hundreds of parcels of land each week. It's deceptive. Some land bots profit a lot from mistakes, and the worst affected by it are usually newbies, the people who need our help the most. While some land bots are ethical, many are not. ~ Dimi From hud at zurich.ibm.com Wed Oct 3 06:46:07 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 3 06:46:43 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <20071003123214.GB26201@bruno.sbruno> References: <47016CFE.1060509@lindenlab.com> <4702394D.5040202@zurich.ibm.com> <47024C26.6050304@blueflash.cc> <47024CE3.5020707@gmail.com> <470257D6.1060101@blueflash.cc> <470325A7.2090400@zurich.ibm.com> <20071003123214.GB26201@bruno.sbruno> Message-ID: <47039D1F.2040907@zurich.ibm.com> Dale Glass wrote: > On Wed, Oct 03, 2007 at 07:16:23AM +0200, dirk husemann wrote: > >>>> Personally, I'd like to get out-of-band confirmation for the exercise of >>>> capabilities. An email with a link, for example, before rezzing an >>>> object, or doing anything that debits my account, or much else other >>>> than walking and talking. So I can configure which ones are always on, >>>> never on, or that the system has to ask me out-of-band to grant for the >>>> rest of the session. >>>> >> hmm...getting an email for rezzing objects sounds to me a >> bit...well...clunky. and it certainly breaks any immersive experience. >> not sure we want that (well, i don't for one). >> > Doesn't have to be mail. A log visible on the website could be nice for > example. > > >>> Only if you can't use the password (the one which you gave the viewer) >>> to reconfigure these options. If 3rd party viewer security is the goal, >>> the only way to enforce that, is (like everything these days) server >>> side by not allowing the viewer to do specific things. >>> >> in the end it comes down to trust: whose viewer do we trust? i'd trust a >> viewer that's available as open source and has been widely vetted and >> examined for security holes. i'd probably have my reservations about joe >> random's viewer-from-the-basement that's closed source and was just >> released yesterday...i might trust a viewer that i've written (then >> again, knowing me, i might not). >> > A bit pedantic: The source is under the GPL2, which means source MUST be > released. LL could sue for copyright infringement anybody who refused to > provide the source. > nah...just write your viewer using libsecondlife. > [...] > > But, even if I'm trusted, I'd still like to have this mechanism. Maybe > one day I'll screw up and accidentally release a viewer that does > something nasty. Permissions and logs would be very helpful in this > case. > true. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/53f7960a/attachment-0001.htm From secret.argent at gmail.com Wed Oct 3 07:16:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 07:16:07 2007 Subject: [sldev] High-prim vehicles using phantom (Re: Havok4...) In-Reply-To: <47038825.8000003@ravenscall.net> References: <47038825.8000003@ravenscall.net> Message-ID: <09D74E10-2D7B-4AC8-B58F-C35A799AD8A4@gmail.com> On 03-Oct-2007, at 07:16, Corax wrote: > Dale Mahalko wrote: >> When such a linkset is set to be physical, we already know that >> phantom objects can't be physical so those objects within the set can >> simply be ignored for the mass / collision / center-of-gravity >> calculations. > Last time I checked phantom objects could also be physical. Set an > object on the top floor of a multi-floor building, set it to > phantom and physical, and watch it fall through every floor to the > ground beneath the building! The important thing about phantom prims is that they DO fall through the floor. In some cases it's even been possible to make them fall through the ground. They're not involved in collision-detection calculations with other prims... and that's the expensive bit. From dale at daleglass.net Wed Oct 3 07:17:43 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 07:17:50 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <002501c805c3$bda13740$33a30650@INFOTECH> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <002501c805c3$bda13740$33a30650@INFOTECH> Message-ID: <20071003141743.GB29227@bruno.sbruno> On Wed, Oct 03, 2007 at 02:46:01PM +0100, Dimitrio Lewis wrote: > Unfortunately sale mistakes are quite common. I don't know the full > psychology behind it, but I imagine the causes include confusion, language > barrier, sleep deprivation, dyslexia (which we all have to some degree), > and an automated mental state caused by the monotony of listing hundreds of > parcels of land each week. It's deceptive. Some land bots profit a lot > from mistakes, and the worst affected by it are usually newbies, the people > who need our help the most. While some land bots are ethical, many are not. That won't fix it though. It'll just mean that the bot will have to get the owner to reply to the captcha. I could set up a bot that'd IM me about bargains in a day or so. In fact I stuffed one SL phisher's database with about 100 fake entries by doing precisely that: I wrote a script that generated random names and passwords by using a list of names, last names, and pwgen. It used a captcha, so the script displayed the image to me and I replied. Captchas make spamming impractical because a single message has very little value compared to the hassle of getting a human to reply to it. Land though, has very easily a benefit of more than $5 for each parcel, and a few seconds for that cash is not bad at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/226d2f2f/attachment.pgp From secret.argent at gmail.com Wed Oct 3 07:20:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 07:20:19 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003133656.GD26201@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> Message-ID: <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> On 03-Oct-2007, at 08:36, Dale Glass wrote: > Now that it's pretty much impossible to set land for sale > accidentally, > why do we need to stop bots from buying land? Because bots distort the land market, were largely responsible for starting the huge bubble in land prices last year, and put people who are not running bots (that is, almost everyone) at a huge disadvantage. Preventing bots from buying land would level the playing field. From nik at terminaldischarge.net Wed Oct 3 07:28:11 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Wed Oct 3 07:28:16 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> Message-ID: <51307.86.10.79.229.1191421691.squirrel@webmail.terminaldischarge.net> > On 03-Oct-2007, at 08:36, Dale Glass wrote: >> Now that it's pretty much impossible to set land for sale >> accidentally, >> why do we need to stop bots from buying land? > > Because bots distort the land market, were largely responsible for > starting the huge bubble in land prices last year, and put people who > are not running bots (that is, almost everyone) at a huge > disadvantage. Preventing bots from buying land would level the > playing field. Agreed. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cnd at knowprose.com Wed Oct 3 09:27:12 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Wed Oct 3 07:30:53 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003133656.GD26201@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> Message-ID: <4703C2E0.40101@knowprose.com> Dale Glass wrote: > > I'm sure it will, what I'm asking here, do we really need to defeat > them? > > Now that it's pretty much impossible to set land for sale accidentally, > why do we need to stop bots from buying land? > http://www.your2ndplace.com/node/578 http://www.your2ndplace.com/node/615 While those who have voice here probably do not see these matters as important, the user base does. Read some of the comments: http://www.petitiononline.com/mod_perl/signed.cgi?2ndlife&1 93 signatures in about a week. Bots really aren't the issue as much as bot owners who capitalize on mistakes/glitches (yes, glitches, I've seen them firsthand) and poor documentation regarding the interface. I even wrote an ebook about it. O.o On the way to Suriname. Later. -- Taran Rampersad Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com Looking for contracts/work! http://www.knowprose.com/node/9786 New!: http://www.OpenDepth.com http://www.knowprose.com http://www.digitaldivide.net/profile/Taran Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo From cnd at knowprose.com Wed Oct 3 09:27:34 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Wed Oct 3 07:31:17 2007 Subject: : Re: [sldev] CAPTCHA to validate land sales. In-Reply-To: <4703BD5A.9030500@knowprose.com> References: <20071003120326.F124E41B391@stupor.lindenlab.com> <00b101c805d4$22969a40$6401a8c0@ownerhiigdyfkh> <4703BD5A.9030500@knowprose.com> Message-ID: <4703C2F6.2000808@knowprose.com> Taran Rampersad wrote: > Elio Maggini wrote: >> IMHO, make something that is fool proof.....and only a fool will use >> it..... >> > IMHO, there are no fools but there are humans that make mistakes > because they do not operate like machines. The day we start penalizing > people for being human with our technology we start penalizing all of > us. Some say that this has already happened. > > Point is, if you're using a GUI... that is humanization of the > interface. Mouse? Same thing. Perhaps it is time to use that > technology on something which impacts people in other ways. > -- Taran Rampersad Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com Looking for contracts/work! http://www.knowprose.com/node/9786 New!: http://www.OpenDepth.com http://www.knowprose.com http://www.digitaldivide.net/profile/Taran Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo From robin.cornelius at gmail.com Wed Oct 3 07:35:49 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Oct 3 07:35:52 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <1190930527.26208.132.camel@localhost> References: <46F4D041.3060502@gmail.com> <46F4E1A2.4070701@gmail.com> <1190930527.26208.132.camel@localhost> Message-ID: On 9/27/07, Callum Lerwick wrote: > > I've checked the contents of h and m using the gdb console and with the > > (unsigned) cast you get a bogus memory location and with a (unsigned > > long) cast you get the intended memory location > > Fixed merged in OpenJPEG SVN revision 463. :) If people want to test, > rev 463 should be stable, and ABI compatible with 1.2. > Just to update you, svn 463 seems to be running pretty well out of the box now, i haven't had a crash due to openjpeg since switching over and it all seems to work pretty well for me now. Robin From dale at daleglass.net Wed Oct 3 07:39:15 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 07:39:21 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> Message-ID: <20071003143915.GC29227@bruno.sbruno> On Wed, Oct 03, 2007 at 09:20:24AM -0500, Argent Stonecutter wrote: > On 03-Oct-2007, at 08:36, Dale Glass wrote: > >Now that it's pretty much impossible to set land for sale > >accidentally, > >why do we need to stop bots from buying land? > > Because bots distort the land market, were largely responsible for > starting the huge bubble in land prices last year, and put people who > are not running bots (that is, almost everyone) at a huge > disadvantage. Preventing bots from buying land would level the > playing field. You will still have land bots. It's just that instead of an autonomous one, there will be a human filling out the captchas. Many people with nothing better to do could be available to fill them 12 hours a day, and the potential payout is more than worth ocasionally filling out a field. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/090e0163/attachment.pgp From odysseus654 at gmail.com Wed Oct 3 07:48:27 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Oct 3 07:48:31 2007 Subject: [sldev] [SVC] Webmap API changed? In-Reply-To: <73e978f20710030049kd00caa6y6d8c1ab6e9827927@mail.gmail.com> References: <73e978f20709300356n2ad70645u462d3e75e4cd0d12@mail.gmail.com> <73e978f20710030049kd00caa6y6d8c1ab6e9827927@mail.gmail.com> Message-ID: <1674f6c70710030748m169bf9c7xca7b35594d96a6a8@mail.gmail.com> Well, I know that you aren't the only one that has been having these problems. Here's someone that appears to have found a workaround for the information they needed at least (in the comments): http://blog.katharineberry.co.uk/2007/09/27/ll-killed-ajaxlife/ On 10/3/07, Mike Welch wrote: > > > Hi, > > Does anyone know if there's been a change to the Webmap API? > > Suddenly all my maps have stopped working. I think it's related to the > SLPoint method which now seems to be non-functional. > > Looking at SLUrl.com and the auctions it looks like LL have moved to the > Google Maps API, but I've not seen an announcement about it and the rest of > the existing API seems to still work, just not SLPoint(). > > Looking at those maps, they don't appear to use SLPoint, is there an > alternative method for going from (region,localx,localy) to (globalx, > globaly)? > > Anyone got any clues? > > Thanks > > Mike (Hinkley Baldwin) > > _______________________________________________ > 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/20071003/2e9e65b7/attachment-0001.htm From dimitrio at dimitriolewis.com Wed Oct 3 07:55:55 2007 From: dimitrio at dimitriolewis.com (Dimitrio Lewis) Date: Wed Oct 3 07:55:14 2007 Subject: [sldev] CAPTCHA to validate land sales. References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net><3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com><001601c805b7$350986f0$33a30650@INFOTECH><20071003123843.GC26201@bruno.sbruno><4703948D.6090608@blueflash.cc><20071003133656.GD26201@bruno.sbruno><62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> Message-ID: <00d301c805cd$831d9e10$33a30650@INFOTECH> > You will still have land bots. > > It's just that instead of an autonomous one, there will be a human > filling out the captchas. Many people with nothing better to do could be > available to fill them 12 hours a day, and the potential payout is more > than worth ocasionally filling out a field. True, although that would probably slow them down to some degree. However, somebody would probably create a bot which could parse the image through captcha busting software without any input required from the owner, which would give that person even more of a monopoly than they had before. I think the main focus should be on preventing mistakes as much as possible rather than dealing with the aftermath, and there's still work to be done in that regard. From q at lindenlab.com Wed Oct 3 08:06:23 2007 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Oct 3 08:08:03 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <00d301c805cd$831d9e10$33a30650@INFOTECH> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net><3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com><001601c805b7$350986f0$33a30650@INFOTECH><20071003123843.GC26201@bruno.sbruno><4703948D.6090608@blueflash.cc><20071003133656.GD26201@bruno.sbruno><62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> <00d301c805cd$831d9e10$33a30650@INFOTECH> Message-ID: <4703AFEF.4010409@lindenlab.com> Dimitrio Lewis wrote: >> You will still have land bots. >> >> It's just that instead of an autonomous one, there will be a human >> filling out the captchas. Many people with nothing better to do could be >> available to fill them 12 hours a day, and the potential payout is more >> than worth ocasionally filling out a field. > > True, although that would probably slow them down to some degree. > However, somebody would probably create a bot which could parse the > image through captcha busting software without any input required from > the owner, which would give that person even more of a monopoly than > they had before. I think the main focus should be on preventing > mistakes as much as possible rather than dealing with the aftermath, > and there's still work to be done in that regard. Automated trading is a reality in any electronic marketplace these days, from the stock market to eBay. Yes, bots sucked the fun out of eBay for me and a lot of other people, just as automated trading spelled the end the line for a lot of old-style stockbrokers. We can lament it but there isn't much point in trying to hold back the tide. The things to focus on are trying to keep things fair and helping people to avoid making mistakes. Q From secret.argent at gmail.com Wed Oct 3 08:08:39 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 08:08:30 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <47039BD1.2050805@zurich.ibm.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> Message-ID: <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> On 03-Oct-2007, at 08:40, dirk husemann wrote: > hmm...i think by opening up the discussion about the future > architecture > and by starting an architecture working group, LL is showing a > substantial amount of openess --- and i trust them that they are dead > serious about this. so, in the long run we will have public specs that > were developed in the open. My point is that these comments (below), if they've been accurately reported by John, indicate that LL doesn't have any intention of conforming to any public specs or notifying anyone of changes that effect the public specs. Now, I'm not saying that they have to... there is nothing that says an Open Source project actually has to produce an Open Systems product. I'm just pointing out that these two kinds of openness aren't the same, and it's important to be aware of the distinction between them. I'm not knocking Linden Labs here. Open Sourcing the client was an amazingly cool thing, it was really courageous of them to do that, and I'm not criticizing them where they haven't gone further by any means. I'm just trying to promote another kind of openness... one that's as old a part of the software industry as Open Source and just as important... and arguing that it needs some kind of commitment from LL that they don't seem to have made: * LL: we can't log every change, it would be cluttered and irrelevant * LL: the source code is very clear on how all of this works * LL: it [the code] is very clear documentation * LL: so this whole discussion about documenting the capability API is just so people can steal code? Again, I'm not saying they have to make that commitment, I'm just asking them to. To illustrate where I'm coming from, let me use an example that's been brought up many times from all sides... Microsoft isn't constrained to remain compatible with Samba. They are constrained to remain compatible with legacy installations, and to a lesser extent to remain compatible with the architecture that they have published for third parties to implement: IETF standard 19: RFC 1001 RFC 1002 IETF drafts: DRAFT-LEACH-CIFS-V1-SPEC-02 DRAFT-SMB-URL-05 Storage Networking Industry Association specs on www.snia.org. Related Microsoft standards such as MS-CHAP. These are not published as code, they're published as actual specs that Microsoft has promised to follow. In as far as they actually follow them, CIFS is an "open system". Now... they've extended the hell out of it in practice, used licensing tricks to target open Source implementations, and the actual implementation in Windows NT is a moving target that Andrew Tridgell has been chasing for years, but there are parts of it they hold to that provide a useful (if nopt complete) level of interoperability, and so a five year old copy of Samba can still be used to access files on Windows Vista if the right settings are made on the Windows side. There are also standards and specs that don't satisfy either Open Source or Open Systems requirements. For example, Microsoft's official page on CIFS at http://msdn2.microsoft.com/en-us/library/ aa302240.aspx - this documentation can't be used by Open Source implementations because the license restricts redistribution... in particular you can distribute source code based on this document but that right is not transferred to the recipient unless they sign a similar license. There are some additional Microsoft documents I can't read because they're wrapped up in an "EXE" file. :) And, finally, Microsoft has attempted to use the "code as spec" argument with CIFS, both in sample implementations with restrictive licenses and by arguing that they can't release the spec without revealing proprietary code. CIFS is a great example, because over the years it has spawned implementations that are both open and closed source, and it's a mix of open and proprietary standards... you can find examples of just about everything in its history. From secret.argent at gmail.com Wed Oct 3 08:17:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 08:17:09 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003143915.GC29227@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> Message-ID: <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> On 03-Oct-2007, at 09:39, Dale Glass wrote: > On Wed, Oct 03, 2007 at 09:20:24AM -0500, Argent Stonecutter wrote: >> On 03-Oct-2007, at 08:36, Dale Glass wrote: >>> Now that it's pretty much impossible to set land for sale >>> accidentally, >>> why do we need to stop bots from buying land? >> Because bots distort the land market, were largely responsible for >> starting the huge bubble in land prices last year, and put people who >> are not running bots (that is, almost everyone) at a huge >> disadvantage. Preventing bots from buying land would level the >> playing field. > You will still have land bots. Fair enough, yes, you can use human-assisted bots. But once you bring a human into the loop, you might as well let that human look at the land the bot is buying, and decide whether to actually buy it. Because putting the human in the loop at all makes it expensive enough that bots that just blindly buy based on area and price no longer have the same kind of advantage, and you won't get the constant push-up in the price of marginal plots that's keeping the price inflated at the low end. From roamingryozu at gmail.com Wed Oct 3 08:20:33 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Oct 3 08:20:35 2007 Subject: [sldev] High-prim vehicles using phantom (Re: Havok4...) In-Reply-To: <09D74E10-2D7B-4AC8-B58F-C35A799AD8A4@gmail.com> References: <47038825.8000003@ravenscall.net> <09D74E10-2D7B-4AC8-B58F-C35A799AD8A4@gmail.com> Message-ID: <5eff6d3b0710030820j403688fdr2d67b1f955610b55@mail.gmail.com> Unfortunately, according to Andrew and Sidewinder, the real issue with vehicles above the 31 prim limit isn't physics interactions. It's region hand-off. I'm not really sure exactly -what- the problem is, but the claim is that it's not physics interactions themselves that limit the prim count. On 10/3/07, Argent Stonecutter wrote: > On 03-Oct-2007, at 07:16, Corax wrote: > > Dale Mahalko wrote: > >> When such a linkset is set to be physical, we already know that > >> phantom objects can't be physical so those objects within the set can > >> simply be ignored for the mass / collision / center-of-gravity > >> calculations. > > > Last time I checked phantom objects could also be physical. Set an > > object on the top floor of a multi-floor building, set it to > > phantom and physical, and watch it fall through every floor to the > > ground beneath the building! > > The important thing about phantom prims is that they DO fall through > the floor. In some cases it's even been possible to make them fall > through the ground. They're not involved in collision-detection > calculations with other prims... and that's the expensive bit. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From labrat.hb at gmail.com Wed Oct 3 09:00:45 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Oct 3 09:00:52 2007 Subject: [sldev] [SVC] Webmap API changed? In-Reply-To: <1674f6c70710030748m169bf9c7xca7b35594d96a6a8@mail.gmail.com> References: <73e978f20709300356n2ad70645u462d3e75e4cd0d12@mail.gmail.com> <73e978f20710030049kd00caa6y6d8c1ab6e9827927@mail.gmail.com> <1674f6c70710030748m169bf9c7xca7b35594d96a6a8@mail.gmail.com> Message-ID: The below code (modified from that in the blog post) should be what you want. I did the something simliar when I was testing the new API, but I was doing it in PHP. function addRegionMarker (regionName, rx,ry, storeImage, popupCode) { var SLMap = this; // Add a dynamic script to get this region position, and then add a market and popup there var varName = "slRegionPos_result"; var scriptURL = "https://cap.secondlife.com/cap/0/d661249b-2b5a-4436-966a-3d3b8d7a574f?var=" + varName + "&sim_name=" + encodeURIComponent(regionName); // Once the script has loaded, we use the result to center the map on the position var onLoadHandler = function () { if (slRegionPos_result.error) { //alert("The region name '" + regionName + "' was not recognised."); } else { var x = slRegionPos_result.x + (rx/256.0); var y = slRegionPos_result.y + (ry/256.0); var pos = new XYPoint(x, y); yellow_dot_image = new Img(storeImage,60,45); yellow_icon = new Icon(yellow_dot_image); all_images = [yellow_icon, yellow_icon, yellow_icon, yellow_icon, yellow_icon, yellow_icon, yellow_icon, yellow_icon, yellow_icon]; marker = new Marker(all_images, pos); mapWindow = new MapWindow(popupCode); mapInstance.addMarker(marker,mapWindow); } }; slAddDynamicScript(scriptURL, onLoadHandler); } On 10/3/07, Erik Anderson wrote: > > Well, I know that you aren't the only one that has been having these > problems. Here's someone that appears to have found a workaround for the > information they needed at least (in the comments): > > http://blog.katharineberry.co.uk/2007/09/27/ll-killed-ajaxlife/ > > > On 10/3/07, Mike Welch wrote: > > > > > Hi, > > > > Does anyone know if there's been a change to the Webmap API? > > > > Suddenly all my maps have stopped working. I think it's related to the > > SLPoint method which now seems to be non-functional. > > > > Looking at SLUrl.com and the auctions it looks like LL have moved to the > > Google Maps API, but I've not seen an announcement about it and the rest of > > the existing API seems to still work, just not SLPoint(). > > > > Looking at those maps, they don't appear to use SLPoint, is there an > > alternative method for going from (region,localx,localy) to (globalx, > > globaly)? > > > > Anyone got any clues? > > > > Thanks > > > > Mike (Hinkley Baldwin) > > > > _______________________________________________ > > 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/20071003/294fc555/attachment-0001.htm From sl at phoca.com Wed Oct 3 09:08:37 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Wed Oct 3 09:09:01 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003143915.GC29227@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net><3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com><001601c805b7$350986f0$33a30650@INFOTECH><20071003123843.GC26201@bruno.sbruno><4703948D.6090608@blueflash.cc><20071003133656.GD26201@bruno.sbruno><62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> Message-ID: ----- Original Message ----- From: "Dale Glass" To: "Argent Stonecutter" Cc: "Second Life Developer Mailing List" Sent: Wednesday, October 03, 2007 7:39 AM Subject: Re: [sldev] CAPTCHA to validate land sales. You will still have land bots. It's just that instead of an autonomous one, there will be a human filling out the captchas. Many people with nothing better to do could be available to fill them 12 hours a day, and the potential payout is more than worth ocasionally filling out a field. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Well, that sounds pretty good to me! As long as there is a human in the mix, it at least gives users a /chance/ of competing with them for good land deals. Bot owners have to sleep some time. The idea that bot owners can automatically "rape" SL and normal SL users or money by a purely automated process and screw with the land market does not sit well with about 99% of the population, and THAT matters a lot. I think that as long as it really takes a human to intervene in an actual sale that was scoured by a bot that that would go a LONG way to making the playing field a lot more "fair" for the normal SL user looking to buy land. Farallon From dale at daleglass.net Wed Oct 3 09:15:02 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 09:15:17 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> Message-ID: <200710031815.12231.dale@daleglass.net> On Wednesday 03 October 2007 17:17:14 Argent Stonecutter wrote: > Fair enough, yes, you can use human-assisted bots. But once you bring > a human into the loop, you might as well let that human look at the > land the bot is buying, and decide whether to actually buy it. Why? The bots probably hunt for real bargains first of all. Getting a small amount like $5 out of a land sale is probably pretty hard. Now if somebody sells a 8192m parcel for L$10 for some reason, you're going to grab that without even looking, even if you could. > Because putting the human in the loop at all makes it expensive > enough that bots that just blindly buy based on area and price no > longer have the same kind of advantage, and you won't get the > constant push-up in the price of marginal plots that's keeping the > price inflated at the low end. I don't think it will. Bot or not the thing is: Can you resell the land later at a profit fast enough? Dealing with land underpriced by $1 got to be very impractical, even with a completely automated bot. Now, the thing with the captcha is that everybody is going to be slowed down accordingly. Both normal people and bot users will be slowed down by the same amount, and the bot's user still keeps the advantage of knowing much faster what bargains there are. Plus, with a bot you can still edge it out a lot in your favor. If I was running it, I'd display the located parcels in a grid, sorted by potential profit, with a very quick and convenient interface. Given enough time it's even possible to make a bot teleport to the area and render it. And after using this for a week I could probably reply to the captcha much faster than a normal resident. Now, short term, purchases by bots will decrease. But that won't last. First because the first person to run a bot that gives the owner the captcha will be at an advantage, so everybody will rush that. And although humans can't buy land 24/7 it'll only mean it'll open up room for more people running bots. I'm pretty sure that long term, it'll balance out to pretty much the same situation as right now, except everybody will lose maybe 30 seconds on each purchase for the captcha. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/8352b9bc/attachment.pgp From dale at daleglass.net Wed Oct 3 09:24:25 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 09:24:35 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> Message-ID: <200710031824.30186.dale@daleglass.net> On Wednesday 03 October 2007 18:08:37 SL - Farallon Greyskin wrote: > Well, that sounds pretty good to me! > > As long as there is a human in the mix, it at least gives users a > /chance/ of competing with them for good land deals. Bot owners have to > sleep some time. There's a lot of people using SL. While some sleep some others will be awake. You will simply give the chance to more people to enter the "land bot runner market". > I think that as long as it really takes a human to intervene in an > actual sale that was scoured by a bot that that would go a LONG way to > making the playing field a lot more "fair" for the normal SL user > looking to buy land. Ah, but I don't think it will. If I wanted to, I could very easily design an interface that's much more optimal for buying than you have access to. While you will demand, and get an interface designed to make land buying/selling safe, and thus slow, I would design one that makes it FAST. It's easy enough to design an interface where the only action required will be typing the captcha and pressing enter, and information on multiple parcels will be available at a glance. Given the limited amount of characters that appear on a captcha, I'm fairly sure I could design an interface for answering it that would be about as fast on a PDA with a pointer as for a normal resident with a keyboard. It also comes to mind that it's easy enough to try to do text recognition on the captcha and present the result in a way that makes it easy for a human to verify whether the guess is correct. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/1a9ec097/attachment.pgp From lenglish5 at cox.net Wed Oct 3 09:38:02 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 3 09:38:13 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> Message-ID: <4703C56A.5050208@cox.net> Argent Stonecutter wrote: > > > I'm not knocking Linden Labs here. Open Sourcing the client was an > amazingly cool thing, it was really courageous of them to do that, and > I'm not criticizing them where they haven't gone further by any means. > I'm just trying to promote another kind of openness... one that's as > old a part of the software industry as Open Source and just as > important... and arguing that it needs some kind of commitment from LL > that they don't seem to have made: > > * LL: we can't log every change, it would be cluttered and irrelevant > * LL: the source code is very clear on how all of this works > * LL: it [the code] is very clear documentation > * LL: so this whole discussion about documenting the capability API is > just so people can steal code? This was excerpted from a confused argument about open source, [open] source documentation, the need for clear architectural goals, etc., during Zero's office hours. The fact is, the Linden Labs programming style, at least in the client, doesn't appear to lend itself well to #'s 2 & 3, regardless of how committed they are to #1. And I put "open" inside brackets before documentation because it is very obvious, having dealt with parts of the GUI for the last few weeks, that the documentation of various parts of the code can't be made more "open" because it obviously doesn't exist in any coherent form. And without clear documentation, clear architectural goals are likely an iffy issue as well. This is a pervading corporate culture, not a conspiracy or even a conscious decision about open documentation/goals. L. From robla at lindenlab.com Wed Oct 3 09:48:16 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 3 09:48:29 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> Message-ID: <4703C7D0.3060901@lindenlab.com> Hi Argent, Comment below: On 10/3/07 8:08 AM, Argent Stonecutter wrote: > I'm not knocking Linden Labs here. Open Sourcing the client was an > amazingly cool thing, it was really courageous of them to do that, and > I'm not criticizing them where they haven't gone further by any means. > I'm just trying to promote another kind of openness... one that's as > old a part of the software industry as Open Source and just as > important... and arguing that it needs some kind of commitment from LL > that they don't seem to have made: > > * LL: we can't log every change, it would be cluttered and irrelevant > * LL: the source code is very clear on how all of this works > * LL: it [the code] is very clear documentation > * LL: so this whole discussion about documenting the capability API is > just so people can steal code? > > Again, I'm not saying they have to make that commitment, I'm just > asking them to. Part of working with a company that's trying to be open like we are is understanding that not every utterance by every person here is the formal written and undebatable policy of Linden Lab. "LL" above is some combination of Tess and I, speaking off-the-cuff at Zero's office hour. One of the biggest challenges we face by investing in documentation is that we're still experimenting and changing things. It's not clear what exactly we should lock down. Moreover, we're not feeling a lot of competitive pressure on this front relative to other really urgent things that we need to do. So, we're not investing heavily in protocol documentation right now. That almost certainly isn't a permanent situation, but it's where we are today. Most of the effort we do spend in formal protocol documentation is going to be under the auspices of the Architecture Working Group, since anything we do there needs to be detailed and formal in order to gain momentum and credibility. That's not terribly helpful in the near term, but I hope that provides assurance that we don't intend to let the status quo persist. In other areas, we'll have to be a little more clever in making sure things get documented correctly, and that's going to involve getting help from you all. We strongly encourage everyone who wants good protocol documentation to pitch in here: https://wiki.secondlife.com/wiki/Protocol I'll encourage everyone at Linden Lab to participate in building this out, but I'll have a much easier time of it if there's a lot of outside activity on those pages (thus being a very leveraged investment on our part). Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/9cefe1bf/signature.pgp From secret.argent at gmail.com Wed Oct 3 09:55:36 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 09:55:27 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710031815.12231.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> Message-ID: <46F3385C-D4D1-40FF-9A82-98A62825D808@gmail.com> On 03-Oct-2007, at 11:15, Dale Glass wrote: > Why? The bots probably hunt for real bargains first of all. The problem isn't the bots looking for real bargains. It's the bots looking for ANY land that's below a price per square meter that's "enough" below the market. It doesn't matter if they're going for land underpriced by 5% or 10% or 15%, that just changes where the tail gets cut off, and no matter what the market is automated buying based purely on price without taking the land into account cuts the tail off. > Plus, with a bot you can still edge it out a lot in your favor. If > I was > running it, I'd display the located parcels in a grid, sorted by > potential > profit, with a very quick and convenient interface. Given enough > time it's > even possible to make a bot teleport to the area and render it. And > after > using this for a week I could probably reply to the captcha much > faster > than a normal resident. That's fine. If you take the land into account, then the tail of less desirable plots remains. It doesn't matter how you do it... the point isn't (in my mind) to slow down the bots, its to keep it froim being so cheap to run them without a human in the loop that they can write off the less attractive plots and still make a profit. From dale at daleglass.net Wed Oct 3 10:28:38 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 10:28:48 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <46F3385C-D4D1-40FF-9A82-98A62825D808@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031815.12231.dale@daleglass.net> <46F3385C-D4D1-40FF-9A82-98A62825D808@gmail.com> Message-ID: <200710031928.43221.dale@daleglass.net> On Wednesday 03 October 2007 18:55:36 Argent Stonecutter wrote: > On 03-Oct-2007, at 11:15, Dale Glass wrote: > > Why? The bots probably hunt for real bargains first of all. > > The problem isn't the bots looking for real bargains. > > It's the bots looking for ANY land that's below a price per square > meter that's "enough" below the market. > > It doesn't matter if they're going for land underpriced by 5% or 10% > or 15%, that just changes where the tail gets cut off, and no matter > what the market is automated buying based purely on price without > taking the land into account cuts the tail off. But buying isn't the problem, selling is. A tier of 65536 meters costs $200 per month, which means you need to make at least that much from land sales. Current average price of land is about L$7 per square meter, which means a sim worth would be about USD $1700. 5% of that is $85, which means that you need to sell a sim-worth of land 3 times at 5% profit to earn about $55 on the tier. Assuming that land parcels have an average size of 512M (failed to find stats on this), that gives an average of 128 parcels per sim. To make the profit we have to go through a sim worth of land 3 times, so that'll be 384 parcels, or an average of 12 parcels per day. I'm pretty sure I can through the creation of a good interface, and practice fill a captcha in about 30 seconds. This gives a total time spent of about 6 minutes per day, to earn $55 per month. There are plenty places in the world where that'd be attractive enough. Coupled with a PDA, smartphone, etc with an internet connection, I could quite easily do this at pretty much any time I'm not sleeping. I am fairly sure that the first person to set this up will get quite a bit more than 5%, by grabbing really underpriced land. > That's fine. If you take the land into account, then the tail of less > desirable plots remains. It doesn't matter how you do it... the point > isn't (in my mind) to slow down the bots, its to keep it froim being > so cheap to run them without a human in the loop that they can write > off the less attractive plots and still make a profit. There's a limit to the cheapness even with a completely automatic bot. I'm pretty sure nobody would run a bot to earn $10 per month, as it's far too easy to end up losing money on it. There has to be a minimum acceptable profit to bother doing this, and I think it's high enough that requiring a human to enter a captcha won't change the overall result too much. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/45f56a10/attachment-0001.pgp From cnd at knowprose.com Wed Oct 3 12:34:51 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Wed Oct 3 10:38:47 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <00d301c805cd$831d9e10$33a30650@INFOTECH> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net><3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com><001601c805b7$350986f0$33a30650@INFOTECH><20071003123843.GC26201@bruno.sbruno><4703948D.6090608@blueflash.cc><20071003133656.GD26201@bruno.sbruno><62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> <00d301c805cd$831d9e10$33a30650@INFOTECH> Message-ID: <4703EEDB.7090804@knowprose.com> Dimitrio Lewis wrote: >> You will still have land bots. >> >> It's just that instead of an autonomous one, there will be a human >> filling out the captchas. Many people with nothing better to do could be >> available to fill them 12 hours a day, and the potential payout is more >> than worth ocasionally filling out a field. > > True, although that would probably slow them down to some degree. > However, somebody would probably create a bot which could parse the > image through captcha busting software without any input required from > the owner, which would give that person even more of a monopoly than > they had before. I think the main focus should be on preventing > mistakes as much as possible rather than dealing with the aftermath, > and there's still work to be done in that regard. You can't prevent mistakes. If mistakes were avoidable, they would not exist. If people wrote bug free code, most developers would be out of work. But if a grace period of 5 minutes were put in place prior to land being listed, there would probably be less problems. I have a strong feeling I've written that before. -- Taran Rampersad Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com Looking for contracts/work! http://www.knowprose.com/node/9786 New!: http://www.OpenDepth.com http://www.knowprose.com http://www.digitaldivide.net/profile/Taran Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo From zha.ewry at gmail.com Wed Oct 3 10:56:41 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Wed Oct 3 10:56:44 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <4703C7D0.3060901@lindenlab.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> <4703C7D0.3060901@lindenlab.com> Message-ID: <920d7d850710031056s79ea4423g343e3ce26b52e62b@mail.gmail.com> Rob, thanks for that very clear statement. Zero was very clear, and you were, during the kick off a few weeks back, that Linden Labs has to balance several things at once. Linden has to grow and evolve the existing code base, while working towards the new design. A lot of what people are going to want, in an open, extensible specification won't much help Linden with their short term goals. That's fine, and I, and hopefully other particpants here understand that having Linden blow up in the short term, in service of the long term is a bad thing By the same token, I think, and hope that Linden understands that longer term, they need to address these issues. Hopefully, most of us aren't asking Linden to do the impossible, all at once. But.. I think we are stating, very clearly, that for formal specifications, we need more than source code. As you've observed, the AWG is the place a lot of that is going to happen. That's entirely sane, to me. A clear statement of direction that says "We expect, as we migrate to the next generation architecture, that the wiki hosted specifications will become the default way of documenting and understanding the system at the protocol and component interaction level" or words to that effect, would be very nice ;-) I don't expect an endeavor of this sort to be easy, painless, or move in a straight line. I do hope, that over time, we'll all end up on the same page, as to what we, as various players in the process need to do collectively, to get to a point where we can say "Look, here's a fully openly developed specification. you can read it and implement it. Here's Linden Lab's implementation of the spec, and here's the OpenSim one, and look, they work together." - Zha On 10/3/07, Rob Lanphier wrote: > > Hi Argent, > > Comment below: > > On 10/3/07 8:08 AM, Argent Stonecutter wrote: > > I'm not knocking Linden Labs here. Open Sourcing the client was an > > amazingly cool thing, it was really courageous of them to do that, and > > I'm not criticizing them where they haven't gone further by any means. > > I'm just trying to promote another kind of openness... one that's as > > old a part of the software industry as Open Source and just as > > important... and arguing that it needs some kind of commitment from LL > > that they don't seem to have made: > > > > * LL: we can't log every change, it would be cluttered and irrelevant > > * LL: the source code is very clear on how all of this works > > * LL: it [the code] is very clear documentation > > * LL: so this whole discussion about documenting the capability API is > > just so people can steal code? > > > > Again, I'm not saying they have to make that commitment, I'm just > > asking them to. > > Part of working with a company that's trying to be open like we are is > understanding that not every utterance by every person here is the > formal written and undebatable policy of Linden Lab. "LL" above is some > combination of Tess and I, speaking off-the-cuff at Zero's office hour. > > One of the biggest challenges we face by investing in documentation is > that we're still experimenting and changing things. It's not clear what > exactly we should lock down. Moreover, we're not feeling a lot of > competitive pressure on this front relative to other really urgent > things that we need to do. So, we're not investing heavily in protocol > documentation right now. That almost certainly isn't a permanent > situation, but it's where we are today. > > Most of the effort we do spend in formal protocol documentation is going > to be under the auspices of the Architecture Working Group, since > anything we do there needs to be detailed and formal in order to gain > momentum and credibility. That's not terribly helpful in the near term, > but I hope that provides assurance that we don't intend to let the > status quo persist. > > In other areas, we'll have to be a little more clever in making sure > things get documented correctly, and that's going to involve getting > help from you all. We strongly encourage everyone who wants good > protocol documentation to pitch in here: > https://wiki.secondlife.com/wiki/Protocol > > I'll encourage everyone at Linden Lab to participate in building this > out, but I'll have a much easier time of it if there's a lot of outside > activity on those pages (thus being a very leveraged investment on our > part). > > Rob > > > _______________________________________________ > 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/20071003/c3e7bde7/attachment.htm From secret.argent at gmail.com Wed Oct 3 10:59:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 10:59:42 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710031928.43221.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031815.12231.dale@daleglass.net> <46F3385C-D4D1-40FF-9A82-98A62825D808@gmail.com> <200710031928.43221.dale@daleglass.net> Message-ID: <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> On 03-Oct-2007, at 12:28, Dale Glass wrote: > There's a limit to the cheapness even with a completely automatic > bot. I'm > pretty sure nobody would run a bot to earn $10 per month, as it's > far too > easy to end up losing money on it. There has to be a minimum > acceptable > profit to bother doing this, and I think it's high enough that > requiring a > human to enter a captcha won't change the overall result too much. You're still not looking at what I'm talking about. Right now, the bot operates with no human in the loop. So it's not cost-effective to do anything that might require a human. If everyone has to have a human in the loop, then it becomes cost- effective to do more things to make smarter buying decisions. So land that a bot would have bought for L$4/sm will be left, if it's low value land that's obviously not going to sell to any humans at a price that will make a profit. So smarter human-assisted bots get more profitable than the current dumb bots, and the tail opens up again. From sean at dague.net Wed Oct 3 11:11:30 2007 From: sean at dague.net (Sean Dague) Date: Wed Oct 3 11:10:11 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <4702C702.1030100@wsu.edu> References: <4702C702.1030100@wsu.edu> Message-ID: <20071003181130.GQ617@dague.net> On Tue, Oct 02, 2007 at 03:32:34PM -0700, John Hurliman wrote: > LL: the source code is very clear on how all of this works > Others: the viewer isn't documentation, it's GPL licensed source code > that is neither a preferred medium for documenting a protocol nor a > license-compatible method of providing docs > LL: it is very clear documentation > Me: so we can look through the SL viewer source code to learn how things > work and reimplement it in BSD licensed libsecondlife correct? > [13:31] Rob Linden: Eddy, as long as you don't steal code, yes > LL: so this whole discussion about documenting the capability API is > just so people can steal code? > Others: no, we don't want your source code. please keep it > Me: we would like documentation to write independent implementations though > Others: independent implementations... part of that whole architecture > working group thing There is a crux in here about the fact that code as documentation is made less desirable when being under a non permissive license. The OpenSim team policy has been for no developers to look at the client source code to ensure there isn't even the smallest hint of license violation. If LL wants some portion of the client code base to function as documentation, it would be really nice to actually relicense those portions under a permissive license so there wouldn't be any concern in looking at them. That being said, John's write up is a very good start. Thanks for all the hard work! :) -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/20071003/7ae7bc33/attachment.pgp From dale at daleglass.net Wed Oct 3 11:32:05 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 11:32:15 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031928.43221.dale@daleglass.net> <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> Message-ID: <200710032032.10720.dale@daleglass.net> On Wednesday 03 October 2007 19:59:52 Argent Stonecutter wrote: > You're still not looking at what I'm talking about. > > Right now, the bot operates with no human in the loop. So it's not > cost-effective to do anything that might require a human. Not in the US maybe. There are countries with internet access where $100 can be a monthly wage. > If everyone has to have a human in the loop, then it becomes cost- > effective to do more things to make smarter buying decisions. So land > that a bot would have bought for L$4/sm will be left, if it's low > value land that's obviously not going to sell to any humans at a > price that will make a profit. L$4/sm is low enough compared to L$7/sm to make a very good profit on it. If you mean that land sold at that price in some awfully lagged sim full of the ugliest builds ever conceived all around it wouldn't have been bought by a human even for that price, then I suppose I could agree with that. But in that case I don't see the point, because if a human who looks at it won't buy, but a bot who can't evaluate those characteristics will, why would you want to keep the bot from buying it? After all, you get to get rid of land in an awful location and selling it for more money than anything with a brain would have paid for it :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/5948deb5/attachment.pgp From zha.ewry at gmail.com Wed Oct 3 11:42:43 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Wed Oct 3 11:42:47 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <20071003181130.GQ617@dague.net> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> Message-ID: <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> This was the point I was on at office hours yesterday. For better, or worse, GPL is an impediment. It is fine for people to say "GPL doesn't stop you from looking at the code." On a personal level, I tend to understand, and maybe even agree with that premise. On a pragmatic level, and having dealt with IP lawyers, on a regular basis for a long time, the actual. real world, non idealistic effect of the GPL has been exactly as Sean describes. Lawyers raise red flags. People ask the question "Where is the line between what is safe to look at and what is not safe to look at." Pretty soon, the answer is "Just don't look." I won't argue about whether that position is legally necessary, or sane, or useful. But, I will observe, it is the position a *LOT* of people take. I will further observe that in most code which implements a protocol, there tends to be a good and pretty strong boundary between code which parses and manages the protocol and code which does the actual heavy lifting behind the scenes. When this is the case, one very easy way for an institution to mark the line between what they view as the protocol, which they want to share, and the internals, which they want to keep protected, is to mark them as such. Of course, the way we mark our intent, in these spaces, is through things like licenses, copyright, trademark and patents. If a hypothetical organization wanted to make very clear, that "these bits we are happy with your using freely" and "these bits we think are our core, proprietary material, and we don't want them stolen for commercial use." one very clear mechanism would be to license the public bits in a nice permissive, unambiguous fashion, and the proprietary bits in a more restrictive fashion. Just an observation. There are ways around these impediments.distilled extracts based on the source code, in non programatic form is one of them. (Such as John';s writeup) But.. in the annoying, pragmatic real world, where some of us actually have to log on, from time to time, the impediments are real, and do clog up the works. - Zha On 10/3/07, Sean Dague wrote: > > On Tue, Oct 02, 2007 at 03:32:34PM -0700, John Hurliman wrote: > > > LL: the source code is very clear on how all of this works > > Others: the viewer isn't documentation, it's GPL licensed source code > > that is neither a preferred medium for documenting a protocol nor a > > license-compatible method of providing docs > > LL: it is very clear documentation > > Me: so we can look through the SL viewer source code to learn how things > > work and reimplement it in BSD licensed libsecondlife correct? > > [13:31] Rob Linden: Eddy, as long as you don't steal code, yes > > LL: so this whole discussion about documenting the capability API is > > just so people can steal code? > > Others: no, we don't want your source code. please keep it > > Me: we would like documentation to write independent implementations > though > > Others: independent implementations... part of that whole architecture > > working group thing > > There is a crux in here about the fact that code as documentation is > made less desirable when being under a non permissive license. > > The OpenSim team policy has been for no developers to look at the client > source code to ensure there isn't even the smallest hint of license > violation. > > If LL wants some portion of the client code base to function as > documentation, it would be really nice to actually relicense those > portions under a permissive license so there wouldn't be any concern in > looking at them. > > That being said, John's write up is a very good start. Thanks for all > the hard work! :) > > -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. > __________________________________________________________________ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHA9tSSamXem9TdyYRAphVAJ4pYotlTtjCElRn879xjedMPvuNrACeL1Wi > TxMgvyjlUIyXLQSMMZTdHxQ= > =eV0T > -----END PGP SIGNATURE----- > > _______________________________________________ > 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/20071003/66127253/attachment-0001.htm From seg at haxxed.com Wed Oct 3 12:17:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 12:17:32 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710031815.12231.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> Message-ID: <1191439036.11151.67.camel@localhost> Remember kids, Fantasy Real Estate Mogul is Serious Business. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/f32a14f8/attachment.pgp From secret.argent at gmail.com Wed Oct 3 12:53:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 12:53:22 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710032032.10720.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031928.43221.dale@daleglass.net> <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> <200710032032.10720.dale@daleglass.net> Message-ID: <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> On 03-Oct-2007, at 13:32, Dale Glass wrote: > On Wednesday 03 October 2007 19:59:52 Argent Stonecutter wrote: >> You're still not looking at what I'm talking about. >> >> Right now, the bot operates with no human in the loop. So it's not >> cost-effective to do anything that might require a human. > Not in the US maybe. There are countries with internet access where > $100 > can be a monthly wage. The absolute cost of doing this doesn't matter. It's the relative cost of doing it with a bot (using, say, a cheap virtual host somewhere) versus doing it with a human (including the cost of managing the human). If the human costs $400 a month (4 people in shifts) then that's at least 10 times the cost of using bots. Look, if it was cost effective then people would be doing it, and out- competing the people running dumb bots. >> If everyone has to have a human in the loop, then it becomes cost- >> effective to do more things to make smarter buying decisions. So land >> that a bot would have bought for L$4/sm will be left, if it's low >> value land that's obviously not going to sell to any humans at a >> price that will make a profit. > L$4/sm is low enough compared to L$7/sm to make a very good profit > on it. Only if it sells. L$4/sm might be a fair price for the parcel. The only reason it's going to get pushed up to L$6 is because it gets bought by a bot that resells to another bot... and then sits there until it gets abandoned because it's not worth the tier for whatever bot on the tail of the chain ended up with it. Which means that the people just looking for land to mess around on who don't care about the giant toilet are competing with the people looking for a nice spot, and pushing up prices at the low end. This keeps the equilibrium price higher than it would otherwise be. > But in that case I don't see the point, because if a human who > looks at it > won't buy, but a bot who can't evaluate those characteristics will, > why > would you want to keep the bot from buying it? Because it drives up the price of the tail of the market, which drives up the market as a whole. > After all, you get to get > rid of land in an awful location and selling it for more money than > anything with a brain would have paid for it :-) For the market as a whole that is not a good thing, because it removes that kind of land from the market... and there would otherwise be a market for that kind of land. From labrat.hb at gmail.com Wed Oct 3 13:08:01 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Oct 3 13:08:04 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031928.43221.dale@daleglass.net> <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> Message-ID: This discussion seems to have moved from the "Bots are bad because people make mistakes" to the "Bots are bad because they drive prices up" A captcha isn't going to change things other then to alter the speed at which they occur. The only real solution for the origional issue would be to have a 24-48 hour escrow system where the seller can reject a land sale. And that itself isn't compleatly fair to a buyer as you could have someone with a "plum" lot that keeps rejecting the sale, but ties up the funds of the people who made a purchase in good faith. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/645e8e23/attachment.htm From nicholaz at blueflash.cc Wed Oct 3 13:20:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Oct 3 13:21:40 2007 Subject: [sldev] Re: [VWR] 1.18.3RC Crash Reports In-Reply-To: <46FCF671.1000100@blueflash.cc> References: <46FCF671.1000100@blueflash.cc> Message-ID: <4703F99D.20900@blueflash.cc> > This is on 1.18.3 build 5. I only churned as many as I could run > overnight, so it's not a statistically significant set yet. I'll give > it the full wiki treatment after I've got a weekend's worth of > processing: Any updates on that yet? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dale at daleglass.net Wed Oct 3 13:22:14 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 13:22:25 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> Message-ID: <200710032222.19372.dale@daleglass.net> On Wednesday 03 October 2007 21:53:30 Argent Stonecutter wrote: > The absolute cost of doing this doesn't matter. It's the relative > cost of doing it with a bot (using, say, a cheap virtual host > somewhere) versus doing it with a human (including the cost of > managing the human). If the human costs $400 a month (4 people in > shifts) then that's at least 10 times the cost of using bots. Now you're having in mind something quite different from what I do. You seem to be thinking of this gold mining MMORPG business I've heard about (haven't seen it personally as I don't play them) What I'm thinking about is a teenager with no income, who has little to do besides maybe school, and who may be carrying around a PDA to ocasionally type a few numbers on it. He's not being paid by anybody to do it, so all he earns is his to keep. > Because it drives up the price of the tail of the market, which > drives up the market as a whole. Drives up? Why? We have here a bot buying something no sane human would for that price. So now the bot's owner paid more than the land is worth, and is definitely not going to sell that a profit. But that land takes tier, so it must be resold (at a lower price than he bought it for), or abandoned. In either case, the land returns to the market for less than it was bought for, while the bot's owner takes a loss for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/023c6b7e/attachment.pgp From matthew.dowd at hotmail.co.uk Wed Oct 3 13:30:32 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Oct 3 13:30:59 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710032222.19372.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> Message-ID: Whatever you may personally feel about landbots - their use is not illegal in SL nor against the TOS. Unless that policy is changed there is little point debated ways of preventing their use. By all means campaign to ban landbots, but this isn't really the list to do that. My personal opinion is that we need to allow human users a little breathing space *after* they have set the land for sale to check things, have second thoughts etc. allow the person standing next to them who they intended to sell the land to, to purchase etc. (but not add yet more dialog boxes checking that they want to proceed), so my solution would be that for the initial five (10?) minutes after the land has been set for sale, it can only be purchased by those present in the sim at the time the land was set for sale, but not buyable by any new people/bots teleporting in. After five minutes anyone can buy. Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/965736b0/attachment.htm From cnd at knowprose.com Wed Oct 3 15:40:54 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Wed Oct 3 13:44:41 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> Message-ID: <47041A76.4000106@knowprose.com> Zha Ewry wrote: > This was the point I was on at office hours yesterday. For better, or > worse, GPL is an impediment. It is fine for people to say "GPL doesn't > stop you from looking at the code." On a personal level, I tend to > understand, and maybe even agree with that premise. On a pragmatic > level, and having dealt with IP lawyers, on a regular basis for a long > time, the actual. real world, non idealistic effect of the GPL has > been exactly as Sean describes. Lawyers raise red flags. People ask > the question "Where is the line between what is safe to look at and > what is not safe to look at." Pretty soon, the answer is "Just don't > look." I won't argue about whether that position is legally necessary, > or sane, or useful. But, I will observe, it is the position a *LOT* of > people take. Completely ducking the implicit Holy War, I will say this: Looking at GPL'd code doesn't really mean anything *unless* you copy the code or you try to patent a process which the code works with. The GPL is not an impediment in any other way; Copyright is fuzzy in areas of code but it is safe to say that there is more than one way to skin a cat. It didn't work very well for SCO, which seems to be the boilerplate of this discussion. Seeing how a GPL piece of code works and replicating it on one's own is not likely to be a copyright violation, or abuse of the GPL itself. The trouble is with demonstrating to LAWYERS and COURTS that you didn't steal the code, and really every possible software license has the same problem. It isn't about the software license in this regard, it *is* about how IP is handled. Of course, I'm not a lawyer. Software developers shouldn't need to be. If the GPL is to be damned in this instance, then put Copyright Law on trial. You'll be in good company. -- Taran Rampersad Presently in: Piarco International Airport, Trinidad and Tobago cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From cnd at knowprose.com Wed Oct 3 15:43:03 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Wed Oct 3 13:46:45 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> Message-ID: <47041AF7.1020109@knowprose.com> Matthew Dowd wrote: > Whatever you may personally feel about landbots - their use is not > illegal in SL nor against the TOS. Lets quit mixing 'legality' and ToS. ToS is a contract, subject to contract law. It is not *THE* Law. > > My personal opinion is that we need to allow human users a little > breathing space *after* they have set the land for sale to check > things, have second thoughts etc. allow the person standing next to > them who they intended to sell the land to, to purchase etc. (but not > add yet more dialog boxes checking that they want to proceed), so my > solution would be that for the initial five (10?) minutes after the > land has been set for sale, it can only be purchased by those present > in the sim at the time the land was set for sale, but not buyable by > any new people/bots teleporting in. After five minutes anyone can buy. There, someone else said it. :-) -- Taran Rampersad Presently in: Piarco International Airport, Trinidad and Tobago cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From adam at gwala.net Wed Oct 3 13:53:15 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Oct 3 13:54:03 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47041A76.4000106@knowprose.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> Message-ID: <4704013B.4020808@gwala.net> Well, a more liberal license isnt a problem there since it doesnt matter if you use the copyright elsewhere or not. Adam Taran Rampersad wrote: > Zha Ewry wrote: > >> This was the point I was on at office hours yesterday. For better, or >> worse, GPL is an impediment. It is fine for people to say "GPL doesn't >> stop you from looking at the code." On a personal level, I tend to >> understand, and maybe even agree with that premise. On a pragmatic >> level, and having dealt with IP lawyers, on a regular basis for a long >> time, the actual. real world, non idealistic effect of the GPL has >> been exactly as Sean describes. Lawyers raise red flags. People ask >> the question "Where is the line between what is safe to look at and >> what is not safe to look at." Pretty soon, the answer is "Just don't >> look." I won't argue about whether that position is legally necessary, >> or sane, or useful. But, I will observe, it is the position a *LOT* of >> people take. > > Completely ducking the implicit Holy War, I will say this: Looking at > GPL'd code doesn't really mean anything *unless* you copy the code or > you try to patent a process which the code works with. The GPL is not an > impediment in any other way; Copyright is fuzzy in areas of code but it > is safe to say that there is more than one way to skin a cat. It didn't > work very well for SCO, which seems to be the boilerplate of this > discussion. > > Seeing how a GPL piece of code works and replicating it on one's own is > not likely to be a copyright violation, or abuse of the GPL itself. The > trouble is with demonstrating to LAWYERS and COURTS that you didn't > steal the code, and really every possible software license has the same > problem. It isn't about the software license in this regard, it *is* > about how IP is handled. > > Of course, I'm not a lawyer. Software developers shouldn't need to be. > If the GPL is to be damned in this instance, then put Copyright Law on > trial. You'll be in good company. > From labrat.hb at gmail.com Wed Oct 3 13:57:23 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Oct 3 13:57:28 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <47041AF7.1020109@knowprose.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> Message-ID: > > > allow the person standing next to > > them who they intended to sell the land to, to purchase etc. (but not > > add yet more dialog boxes checking that they want to proceed), so my The current land sale system already has a method to specify WHO you want to be able to buy a parcel of land. If you are not using it it is not LL's fault. There is also a final screen that comes up to allow you to verify the sale settings BEFORE you click "APPLY" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/fe2b69b9/attachment.htm From robla at lindenlab.com Wed Oct 3 13:57:47 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 3 13:58:01 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <920d7d850710031056s79ea4423g343e3ce26b52e62b@mail.gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> <4703C7D0.3060901@lindenlab.com> <920d7d850710031056s79ea4423g343e3ce26b52e62b@mail.gmail.com> Message-ID: <4704024B.7020409@lindenlab.com> Hi Zha, I'll actually go further: we expect, as we migrate to the next generation architecture, that the wiki hosted specifications will become the default way of documenting and understanding the system at the protocol and component interaction level. As subsystems and protocols stabilize, that documentation will likely transition toward an architecture document with a LOT of references to standards published by internationally recognized standards bodies, because one of three things happens: 1) We've transitioned key architectural components toward using existing (or "to be existing" standards) 2) We've actually submitted material from the wiki to an existing standards body for refinement and standardization 3) We've helped form a new standards body to submit material to, we've submitted material developed on the wiki, and as a result of our collaboration with others, that standards body gains enough gravity, momentum, and credibility to be internationally recognized as a rightful publisher of standards. We're not at all sure #3 above is necessary, but I put that in there for the sake of completeness, because we haven't ruled it out. Since there's no guarantee that our current paying customers are going to have the patience to stick with us while we work on ornate, detailed specifications of our system as it exists today, we're going to have to figure out how to do all of this as a by-product of getting our respective day jobs done. So, that's why your help (where "you" is "you, dear reader of sldev") is greatly appreciated. Thanks Rob On 10/3/07 10:56 AM, Zha Ewry wrote: > Rob, thanks for that very clear statement. Zero was very clear, and > you were, during the kick off a few weeks back, that Linden Labs has > to balance several things at once. Linden has to grow and evolve the > existing code base, while working towards the new design. A lot of > what people are going to want, in an open, extensible specification > won't much help Linden with their short term goals. That's fine, and > I, and hopefully other particpants here understand that having Linden > blow up in the short term, in service of the long term is a bad thing > By the same token, I think, and hope that Linden understands that > longer term, they need to address these issues. > > Hopefully, most of us aren't asking Linden to do the impossible, all > at once. But.. I think we are stating, very clearly, that for formal > specifications, we need more than source code. As you've observed, the > AWG is the place a lot of that is going to happen. That's entirely > sane, to me. > > A clear statement of direction that says "We expect, as we migrate to > the next generation architecture, that the wiki hosted specifications > will become the default way of documenting and understanding the > system at the protocol and component interaction level" or words to > that effect, would be very nice ;-) > > I don't expect an endeavor of this sort to be easy, painless, or move > in a straight line. I do hope, that over time, we'll all end up on the > same page, as to what we, as various players in the process need to do > collectively, to get to a point where we can say "Look, here's a fully > openly developed specification. > you can read it and implement it. Here's Linden Lab's implementation > of the spec, and here's the OpenSim one, and look, they work together." > > - Zha > > > On 10/3/07, *Rob Lanphier* > wrote: > > Hi Argent, > > Comment below: > > On 10/3/07 8:08 AM, Argent Stonecutter wrote: > > I'm not knocking Linden Labs here. Open Sourcing the client was an > > amazingly cool thing, it was really courageous of them to do > that, and > > I'm not criticizing them where they haven't gone further by any > means. > > I'm just trying to promote another kind of openness... one that's as > > old a part of the software industry as Open Source and just as > > important... and arguing that it needs some kind of commitment > from LL > > that they don't seem to have made: > > > > * LL: we can't log every change, it would be cluttered and > irrelevant > > * LL: the source code is very clear on how all of this works > > * LL: it [the code] is very clear documentation > > * LL: so this whole discussion about documenting the capability > API is > > just so people can steal code? > > > > Again, I'm not saying they have to make that commitment, I'm just > > asking them to. > > Part of working with a company that's trying to be open like we are is > understanding that not every utterance by every person here is the > formal written and undebatable policy of Linden Lab. "LL" above > is some > combination of Tess and I, speaking off-the-cuff at Zero's office > hour. > > One of the biggest challenges we face by investing in documentation is > that we're still experimenting and changing things. It's not > clear what > exactly we should lock down. Moreover, we're not feeling a lot of > competitive pressure on this front relative to other really urgent > things that we need to do. So, we're not investing heavily in > protocol > documentation right now. That almost certainly isn't a permanent > situation, but it's where we are today. > > Most of the effort we do spend in formal protocol documentation is > going > to be under the auspices of the Architecture Working Group, since > anything we do there needs to be detailed and formal in order to gain > momentum and credibility. That's not terribly helpful in the near > term, > but I hope that provides assurance that we don't intend to let the > status quo persist. > > In other areas, we'll have to be a little more clever in making sure > things get documented correctly, and that's going to involve getting > help from you all. We strongly encourage everyone who wants good > protocol documentation to pitch in here: > https://wiki.secondlife.com/wiki/Protocol > > I'll encourage everyone at Linden Lab to participate in building this > out, but I'll have a much easier time of it if there's a lot of > outside > activity on those pages (thus being a very leveraged investment on our > part). > > Rob > > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/61ea9185/signature.pgp From dale at daleglass.net Wed Oct 3 13:59:19 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 3 13:59:35 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <4704013B.4020808@gwala.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> Message-ID: <200710032259.29237.dale@daleglass.net> On Wednesday 03 October 2007 22:53:15 Adam Frisby wrote: > Well, a more liberal license isnt a problem there since it doesnt matter > if you use the copyright elsewhere or not. The BSD people disagree. See the recent flamewar between the Linux and OpenBSD people. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/77642b09/attachment.pgp From secret.argent at gmail.com Wed Oct 3 14:26:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 14:26:32 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <200710032222.19372.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> Message-ID: On 03-Oct-2007, at 15:22, Dale Glass wrote: >> Because it drives up the price of the tail of the market, which >> drives up the market as a whole. > Drives up? Why? We have here a bot buying something no sane human > would for > that price. Um, no, that's not what I said. I didn't say that the land was overpriced when the bot bought it, I said that the land was less valuable than the average. The price might have been reasonable at L$3-4/sm, the bot buys it and sets it for sale at the target "market price". If that's low enough, another bot buys it. It then sits on the market for a tier cycle or two and then gets knocked down or abandoned. If it's abandoned it stays off the market for months. If it's knocked down another bot picks it up and the cycle starts again. It never stays on the market at a price that it would actually sell for, because it's not cost effective for someone buying and selling through bots to actually go out and do anything with it. In fact a lot of times you have a bot buying at 3, selling at 4, another bot buys it and sells it at 5, until it reaches the point where the bots won't touch it any more. So, it drives up the price of the tail of the market, which drives up the market as a whole. From matthew.dowd at hotmail.co.uk Wed Oct 3 14:38:52 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Oct 3 14:39:11 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> Message-ID: >> Whatever you may personally feel about landbots - their use is not >> illegal in SL nor against the TOS.>Lets quit mixing 'legality' and ToS. ToS is a contract, subject to >contract law. It is not *THE* Law. I never said it was *THE* law - the word "illegal" can be quite legitimately used as a synonym for banned, prohibited etc. without it necessarily being anything to do the the Law of the land. > The current land sale system already has a method to specify WHO you want to be able to buy a parcel of land. If you are not using it it is not LL's fault. A good UI system provides some allowance for human fallability. > There is also a final screen that comes up to allow you to verify the sale settings BEFORE you click "APPLY" And I was quite clear in my e-mail that dialogs *BEFORE* you click apply weren't the answer, but breathing space *AFTER* you click apply. The newbie selling to a buyer standing next to them in an empty sim unaware of landbots will think it safe to set the land for sale to anyone for the other person to buy it. When they get a dialog saying "Are you sure?" they will think, yes "I'm sure - ther person buying is standing next to me - there's no-one else around - I'll click OK". And in any case the warning/alert dialog is so overused and we get so many annoying popups in browsers, software etc. that clicking through such things without thinking is almost a reflex action - can you honestly say you've never clicked on a popup almost in reaction and immediately thought "damn, I didn't mean to click that"? Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/c6496e26/attachment-0001.htm From secret.argent at gmail.com Wed Oct 3 14:42:06 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 14:41:57 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47041A76.4000106@knowprose.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> Message-ID: <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> On 03-Oct-2007, at 17:40, Taran Rampersad wrote: > Seeing how a GPL piece of code works and replicating it on one's > own is not likely to be a copyright violation, or abuse of the GPL > itself. The trouble is with demonstrating to LAWYERS and COURTS > that you didn't steal the code, and really every possible software > license has the same problem. It's only a problem if there is the appearance that you violated the license when you allegedly copied it. If the software is BSD or MIT licensed, copying the code and incorporating it into your product does not violate the license, unless you remove the copyright notices... and that has been an issue on occasion for some bizarre reason... but conforming to the license is trivial, therefore these licenses don't cause a problem. If the software is LGPL, then using it in your product does not violate the license as long as you conform to the LGPL for that component. It doesn't restrict how the rest of the product is licensed. The Microsoft Permissive License is somewhere in the middle between the LGPL and the BSDL... it applies to the specific source files, not the work as a whole. There are commercial licenses that specifically exclude code derived from the API (say, code created by examining include files). These can also be used as a documentation format without opening up the possibility of this situation. So if the code was released under one of these licenses it would not create a situation where someone using the code as documentation would automatically be at risk of being placed in a position where they had to defend their work. The original voice API license, Microsoft's license on some of their documentation, all have similar issues. That is, there are licenses that create a problem for open systems use, and ones that don't. The GPL happens to be one that does. From lenglish5 at cox.net Wed Oct 3 14:45:30 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 3 14:46:08 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <200710032259.29237.dale@daleglass.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> Message-ID: <47040D7A.3030001@cox.net> Dale Glass wrote: > On Wednesday 03 October 2007 22:53:15 Adam Frisby wrote: > >> Well, a more liberal license isnt a problem there since it doesnt matter >> if you use the copyright elsewhere or not. >> > > The BSD people disagree. > > See the recent flamewar between the Linux and OpenBSD people. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > I think its more a flamewar by the GPL people against the FreeBSD people BECAUSE the FreeBSD people want to do something against the spirit of the GPL. First came an intent counter to the spirit of the GPL and then a license to allow that intent to legally manifest in source. I'm still not sure why the GPL itself would require "clean room" practices to copy *functionality*, even into a proprietary bit of code. I guess to avoid the taint of potential contamination by copying text verbatim rather than merely grabbing ideas...? As long as you don't do huge amounts of cutting and pasting, and stick to your own variable and function [re]naming scheme, when you do cut and paste, I can't see how legal issues would apply unless you were really careless when renaming or really liberal in how much cutting and pasting you actually did. Lawson From adam at gwala.net Wed Oct 3 14:52:55 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Oct 3 14:53:41 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47040D7A.3030001@cox.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> Message-ID: <47040F37.20000@gwala.net> Still technically copying something - so copyright law applies and your bound by the licensing terms. Sucks, but that's the way it is. Adam Lawson English wrote: > Dale Glass wrote: > >> On Wednesday 03 October 2007 22:53:15 Adam Frisby wrote: >> >> >>> Well, a more liberal license isnt a problem there since it doesnt matter >>> if you use the copyright elsewhere or not. >>> >> >> >> The BSD people disagree. >> >> See the recent flamewar between the Linux and OpenBSD people. >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > I think its more a flamewar by the GPL people against the FreeBSD people > BECAUSE the FreeBSD people want to do something against the spirit of > the GPL. > > First came an intent counter to the spirit of the GPL and then a license > to allow that intent to legally manifest in source. > > > I'm still not sure why the GPL itself would require "clean room" > practices to copy *functionality*, even into a proprietary bit of code. > I guess to avoid the taint of potential contamination by copying text > verbatim rather than merely grabbing ideas...? As long as you don't do > huge amounts of cutting and pasting, and stick to your own variable and > function [re]naming scheme, when you do cut and paste, I can't see how > legal issues would apply unless you were really careless when renaming > or really liberal in how much cutting and pasting you actually did. > > > Lawson > > > > _______________________________________________ > 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 Oct 3 14:54:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 14:54:22 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <200710032259.29237.dale@daleglass.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> Message-ID: <88F8F171-2D9C-4B6B-98F4-6F5E7962A25E@gmail.com> On 03-Oct-2007, at 15:59, Dale Glass wrote: > On Wednesday 03 October 2007 22:53:15 Adam Frisby wrote: >> Well, a more liberal license isnt a problem there since it doesnt >> matter >> if you use the copyright elsewhere or not. > The BSD people disagree. I suspect Adam meant "if you use the copyrighted code elsewhere or not". The latest flame war is because some people have trouble with "you can do whatever you want, just keep this copyright notice intact". I have no idea why people have trouble with this, after the FSF talked CSRG into watering down the original requirement so the FSF would say that the new BSDL was GPL-compatible... and so there should no longer be any incentive to remove the BSDL from the code. From secret.argent at gmail.com Wed Oct 3 15:08:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 15:08:15 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> Message-ID: <86CBDA83-B92F-4BD4-A8DF-FA35135F3801@gmail.com> On 03-Oct-2007, at 16:38, Matthew Dowd wrote: > And in any case the warning/alert dialog is so overused and we get > so many annoying popups in browsers, software etc. that clicking > through such things without thinking is almost a reflex action - > can you honestly say you've never clicked on a popup almost in > reaction and immediately thought "damn, I didn't mean to click that"? Of course. Which is why it doesn't depend on that dialog. You *have to* actively choose whether to sell to anyone or to a specific person. If you don't choose it doesn't give you a dialog and let you go, it doesn't let you complete the transaction at all. I'm a big opponent of stupid approval dialogs, but this isn't a case where they're depending on a stupid approval dialog. They're requiring a positive action from the user. From secret.argent at gmail.com Wed Oct 3 15:18:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 15:18:36 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47040D7A.3030001@cox.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> Message-ID: <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> On 03-Oct-2007, at 16:45, Lawson English wrote: > I think its more a flamewar by the GPL people against the FreeBSD > people BECAUSE the FreeBSD people want to do something against the > spirit of the GPL. Um, what are you talking about? This was OpenBSD, not FreeBSD, and neither OpenBSD nor FreeBSD have been using a license that is GPL-incompatible this century. > I'm still not sure why the GPL itself would require "clean room" > practices to copy *functionality*, even into a proprietary bit of > code. There have been specific cases where independently developed components that implemented the same API as a GPLed program have been hit with legal action by the FSF, on the grounds that by interoperating with an API that was part of a GPLed program they were derived works and are thus covered by the GPL... even if there was no GPLed code in them. There was no "huge amount of cutting and pasting" involved... according to the FSF simply using an API documented in a GPLed source makes your code covered by the GPL. There's nothing hypothetical about this. It's really happened. In one they ended up creating a complete implementation of the libmp library from scratch so that the API was no longer "a GPLed API" because there was a non-GPLed implementation to work from. After a few cases like this, is it any wonder that people want to create a "clean room" environment around GPLed code? From nicholaz at blueflash.cc Wed Oct 3 15:39:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Oct 3 15:40:10 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> Message-ID: <47041A20.8020905@blueflash.cc> Argent Stonecutter wrote: > ... according > to the FSF simply using an API documented in a GPLed source makes your > code covered by the GPL. > > There's nothing hypothetical about this. It's really happened. LOL, and I thought Microsoft was bad. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From robla at lindenlab.com Wed Oct 3 15:48:52 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 3 15:49:06 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> Message-ID: <47041C54.6090709@lindenlab.com> On 10/3/07 3:18 PM, Argent Stonecutter wrote: > There have been specific cases where independently developed > components that implemented the same API as a GPLed program have been > hit with legal action by the FSF, on the grounds that by > interoperating with an API that was part of a GPLed program they were > derived works and are thus covered by the GPL... even if there was no > GPLed code in them. There was no "huge amount of cutting and pasting" > involved... according to the FSF simply using an API documented in a > GPLed source makes your code covered by the GPL. Can you actually document this? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/9b404b76/signature-0001.pgp From adam at gwala.net Wed Oct 3 16:31:47 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Oct 3 16:32:34 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <47041C54.6090709@lindenlab.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> Message-ID: <47042663.7020909@gwala.net> This might tickle some people the wrong way, but I just spotted something interesting. MS have a Shared Source license called the "Reference License" which is explicitly for this kind of thing. Maybe Dual license GPL+RL? Details: http://www.microsoft.com/resources/sharedsource/licensingbasics/referencelicense.mspx Adam Rob Lanphier wrote: > On 10/3/07 3:18 PM, Argent Stonecutter wrote: > >>There have been specific cases where independently developed >>components that implemented the same API as a GPLed program have been >>hit with legal action by the FSF, on the grounds that by >>interoperating with an API that was part of a GPLed program they were >>derived works and are thus covered by the GPL... even if there was no >>GPLed code in them. There was no "huge amount of cutting and pasting" >>involved... according to the FSF simply using an API documented in a >>GPLed source makes your code covered by the GPL. > > > Can you actually document this? > > Rob > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 3 16:48:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 16:47:56 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <47041C54.6090709@lindenlab.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> Message-ID: On 03-Oct-2007, at 17:48, Rob Lanphier wrote: > On 10/3/07 3:18 PM, Argent Stonecutter wrote: >> There have been specific cases where independently developed >> components that implemented the same API as a GPLed program have been >> hit with legal action by the FSF, on the grounds that by >> interoperating with an API that was part of a GPLed program they were >> derived works and are thus covered by the GPL... even if there was no >> GPLed code in them. There was no "huge amount of cutting and pasting" >> involved... according to the FSF simply using an API documented in a >> GPLed source makes your code covered by the GPL. > Can you actually document this? The best known case is libmp. I can't find the original discussion on this one but here's a reference fairly close in time... "http://lists.debian.org/debian-devel/1997/06/msg00088.html" > The issue in the libmp was a package containing a midified RSAREF that > could be linked to libmp. Libmp is aparantly faster than the standard > multiprecision library available. Libmp also has a slightly different > interface, so it isn't a simple drop-in replacement for the standard > library (as glibc or libc5 (theoretically) is). The FSF contended > that > the resulting modified package (which was not distributed with > binaries > or source for libmp) must be GPLed, since the -product-, namely the > executable binaries, must contain GPLed code (the libmp library), so > must be GPLed. The source is merely the preferred distribution method > for the product. In this case, the product was being distributed in > two pieces. The justification for this position was that libmp had a > unique interface. Any program written to use that interface had no > choice but to use libmp, and thus the resulting binary was derived > from > libmp. In this particular case, the program was thus subjected to > both > the GPL -and- the license on RSAREF, which are incompatable licenses. > The FSF objected to the distribution of the modified package -at all-, > since it would be impossible to fulfill the requirements of both > licenses. > > That particular package is now distributed with a simple > libmp-compatable non-GPLed multiprecision integer package (thus > avoiding the unique interface issue, since now there are two libraries > with the same documented interface), and instructions to link it with > the FSF libmp, because it is a much better library. RMS agreed that > this would solve the problem. The basic principle, that using the API of a GPLed component required that your code be GPLed if it was distributed, has not been changed... what changed is that creating a second implementation that provided the same API meant that t he API wasn't *just* an API for a GPLed application any more. This incident also led to some concern about Linux and proprietary drivers, because loadable drivers that run in the Linux kernel would also be derived works under the same interpretation. Linus ended up carving out an ad-hoc exception that allowed closed-source drivers. I don't know whether LL can do the same thing, or even if they need to, but the point is that it's not unreasonable for people to be worried about it. There's also the open question as to whether providing or using a "standard API" is a general escape, or whether RMS was just carving out an exemption for libmp... because U/WIN and Interix had similar issues because the FSF said that *on Windows* the UNIX API wasn't the native OS API distributed by Microsoft and thus it didn't serve as a wall between GPL and non-GPL software as it does in Linux. Interix was bought by Microsoft, so that made it a standard OS API on Windows. The thread starts here... http://gcc.gnu.org/ml/gcc/2001-01/msg00415.html The logic seems a bit twisty on both sides to me. From secret.argent at gmail.com Wed Oct 3 16:51:51 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 16:51:41 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <47042663.7020909@gwala.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47042663.7020909@gwala.net> Message-ID: The MS reference license does not grant the right to create derivative works. Which is the issue here. From adam at gwala.net Wed Oct 3 17:03:17 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Oct 3 17:04:04 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47042663.7020909@gwala.net> Message-ID: <47042DC5.6010007@gwala.net> No, but it does allow studying the code for reference which helps the code-as-documentation problem. Argent Stonecutter wrote: > The MS reference license does not grant the right to create derivative > works. Which is the issue here. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Wed Oct 3 17:12:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Oct 3 17:12:57 2007 Subject: [sldev] Re: Viewer Auth Feedback In-Reply-To: <4702C1ED.2010506@blueflash.cc> References: <47016CFE.1060509@lindenlab.com> <4702C1ED.2010506@blueflash.cc> Message-ID: <47042FE8.6010104@blueflash.cc> Now in an environment like this, I can see more sense in creating that detour-login (to that enviroment, not for a standalone.exe ... and not that it will keep that website from getting your Lindens once you're in, not without a limited-session-rights password). http://nwn.blogs.com/nwn/2007/10/second-move-jap.html#more Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From lenglish5 at cox.net Wed Oct 3 17:24:00 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 3 17:26:21 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> Message-ID: <470432A0.9010903@cox.net> Argent Stonecutter wrote: > > On 03-Oct-2007, at 16:45, Lawson English wrote: >> I think its more a flamewar by the GPL people against the FreeBSD >> people BECAUSE the FreeBSD people want to do something against the >> spirit of the GPL. > > Um, what are you talking about? > > This was OpenBSD, not FreeBSD, and neither OpenBSD nor FreeBSD have > been using a license that is GPL-incompatible this century. > >> I'm still not sure why the GPL itself would require "clean room" >> practices to copy *functionality*, even into a proprietary bit of code. > > There have been specific cases where independently developed > components that implemented the same API as a GPLed program have been > hit with legal action by the FSF, on the grounds that by > interoperating with an API that was part of a GPLed program they were > derived works and are thus covered by the GPL... even if there was no > GPLed code in them. There was no "huge amount of cutting and pasting" > involved... according to the FSF simply using an API documented in a > GPLed source makes your code covered by the GPL. > > There's nothing hypothetical about this. It's really happened. In one > they ended up creating a complete implementation of the libmp library > from scratch so that the API was no longer "a GPLed API" because there > was a non-GPLed implementation to work from. > > After a few cases like this, is it any wonder that people want to > create a "clean room" environment around GPLed code? Sicne GnuStep uses the NeXtStep, now, Cocoa API, does this mean that Cocoa is now illegal? Sounds like some lawyers and judges exercsied a bit of legal fiction in a vacuuum of non-understanding the real world. But, in the legal world, unles you have bette3r lawyers, the incredibly stupid precedence stands. Lawson From seg at haxxed.com Wed Oct 3 14:53:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 17:51:43 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> Message-ID: <1191448391.11151.82.camel@localhost> On Wed, 2007-10-03 at 16:42 -0500, Argent Stonecutter wrote: > That is, there are licenses that create a problem for open > systems use, and ones that don't. The GPL happens to be one that does. Can you point to a concrete example of the GPL causing such a problem? Though as part of the new architecture work, I really would like to see the low level protocol stuff abstracted into its own library. And that library could be MIT licensed for all I care. Would that make everyone happy? (Yeah yeah, libsecondlife is already there... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/6098d914/attachment.pgp From seg at haxxed.com Wed Oct 3 17:51:26 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 17:51:46 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> Message-ID: <1191459086.11151.129.camel@localhost> On Wed, 2007-10-03 at 18:48 -0500, Argent Stonecutter wrote: > > On 10/3/07 3:18 PM, Argent Stonecutter wrote: > >> There have been specific cases where independently developed > >> components that implemented the same API as a GPLed program have been > >> hit with legal action by the FSF, on the grounds that by > >> interoperating with an API that was part of a GPLed program they were > >> derived works and are thus covered by the GPL... even if there was no > >> GPLed code in them. There was no "huge amount of cutting and pasting" > >> involved... according to the FSF simply using an API documented in a > >> GPLed source makes your code covered by the GPL. No, you're wrong. Allow you to correct yourself: > The basic principle, that using the API of a GPLed component required > that your code be GPLed if it was distributed, has not been > changed... what changed is that creating a second implementation that > provided the same API meant that t he API wasn't *just* an API for a > GPLed application any more. This is not even directly addressing the issue of looking at GPL code to duplicate its API. But given that this issue was *resolved* by cloning the API of a GPL library, this to me strongly implies that duplicating an API implemented in GPL code is an okay thing to do. (Not that that's really even the issue. We're talking about looking at GPL code that *utilizes* an RPC mechanism implemented elsewhere. And as I fully expect the libsecondlife guys to remain on top of things, well there's your secondary, BSD licensed implementation. :) So there's no problem here. Can we stop wasting our time spreading anti-GPL FUD now? If you want to argue about the GPL go do it on Groklaw. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/990b6350/attachment.pgp From dzonatas at dzonux.net Wed Oct 3 18:06:16 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Oct 3 18:04:09 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> Message-ID: <47043C88.7060205@dzonux.net> Argent Stonecutter wrote: > On 03-Oct-2007, at 17:48, Rob Lanphier wrote: >> On 10/3/07 3:18 PM, Argent Stonecutter wrote: >>> There have been specific cases where independently developed >>> components that implemented the same API as a GPLed program have been >>> hit with legal action by the FSF, on the grounds that by ... >> Can you actually document this? > > The best known case is libmp. I can't find the original discussion on > this one but here's a reference fairly close in time... > > "http://lists.debian.org/debian-devel/1997/06/msg00088.html" > I started to read this and realized this is actually the more famous gray area that causes license disputes to be handled on a case by case basis. The effect of that case above does not bind every other case like it to have the same outcome. It is a logical fallacy: dicto simpliciter. I've been pretty content with the legality that GPL has held no solid authority over API-links. There is, instead, a legal position held about content. The mere act to link with an API does hold any legal restriction until content is actually being swapped or shared. The court has to deal with these on a case by case issue due to the need to study the actual content being used and how it is used in the API (and related program). How the study of that content will be handled in court is one of those things you'll have to ask your lawyers advice. The mere act to document the API itself under GPL (or GFDL or Creative Comments Attribution-ShareAlike 2.5) and even copyright it still does not automatically blend (or patent) functionality and content from use of such API. =p -- Power to Change the Void From seg at haxxed.com Wed Oct 3 18:29:15 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 18:29:25 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <47043C88.7060205@dzonux.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47043C88.7060205@dzonux.net> Message-ID: <1191461355.11151.144.camel@localhost> On Wed, 2007-10-03 at 18:06 -0700, Dzonatas wrote: > How the study of that content will be handled in court is one of those > things you'll have to ask your lawyers advice. The mere act to document > the API itself under GPL (or GFDL or Creative Comments > Attribution-ShareAlike 2.5) and even copyright it still does not > automatically blend (or patent) functionality and content from use of > such API. Not to mention, that the copyright owners, that is, Linden Lab would actually have to press charges for you to actually get in legal trouble. And given statements that the code shall serve as documentation, and given what I understand to be explicit consent for libsecondlife to re-implement the protocol, I think they'd have a hard time turning around and arguing that re-implementing the protocol based on looking at the source is acting against their wishes. IANAL. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/80cd14fe/attachment.pgp From secret.argent at gmail.com Wed Oct 3 18:33:29 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 18:33:37 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <47042DC5.6010007@gwala.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47042663.7020909@gwala.net> <47042DC5.6010007@gwala.net> Message-ID: On 03-Oct-2007, at 19:03, Adam Frisby wrote: > Argent Stonecutter wrote: >> The MS reference license does not grant the right to create >> derivative works. Which is the issue here. > No, but it does allow studying the code for reference which helps > the code-as-documentation problem. Not unless you're allowed to use the documentation to create derivative works. Seriously. From adam at gwala.net Wed Oct 3 18:37:17 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Oct 3 18:38:03 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <1191461355.11151.144.camel@localhost> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47043C88.7060205@dzonux.net> <1191461355.11151.144.camel@localhost> Message-ID: <470443CD.7070902@gwala.net> This is something to be really really really careful of. Today, I'd have no problems whatsoever trusting Linden Lab's behaviour - but remember companies can be sold, or have their assets sold through bankruptcy, and the new owner may not be quite so generous. It is under all circumstances best to make sure one is on decent legal footing at all times. Adam Callum Lerwick wrote: > On Wed, 2007-10-03 at 18:06 -0700, Dzonatas wrote: > >>How the study of that content will be handled in court is one of those >>things you'll have to ask your lawyers advice. The mere act to document >>the API itself under GPL (or GFDL or Creative Comments >>Attribution-ShareAlike 2.5) and even copyright it still does not >>automatically blend (or patent) functionality and content from use of >>such API. > > > Not to mention, that the copyright owners, that is, Linden Lab would > actually have to press charges for you to actually get in legal trouble. > And given statements that the code shall serve as documentation, and > given what I understand to be explicit consent for libsecondlife to > re-implement the protocol, I think they'd have a hard time turning > around and arguing that re-implementing the protocol based on looking at > the source is acting against their wishes. > > IANAL. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 3 18:38:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 18:38:46 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <1191459086.11151.129.camel@localhost> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <1191459086.11151.129.camel@localhost> Message-ID: <989FEB3F-9084-4711-848B-9BB159B2088A@gmail.com> *sigh* [Callum Lerwick accusing me of spreading FUD] Look, you're missing a couple of HUGE bloody points here. First, I ALSO said that it was up to Linden Labs to say what was OK or not, not the FSF. I'm just explaining WHY people are leary of the GPL. Because this kind of stuff KEEPS happening. The FSF are the GPL's worst enemies some times. Second, the libsecondlife guys are the people who brought up the issue of the code being GPLed in the first place. They're the ones who are using the clean-room approach to make SURE that that they have a BSD licensed implementation. From gigstaggart at gmail.com Wed Oct 3 18:45:08 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Oct 3 18:45:07 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <1191448391.11151.82.camel@localhost> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> Message-ID: <470445A4.4040301@gmail.com> Callum Lerwick wrote: > On Wed, 2007-10-03 at 16:42 -0500, Argent Stonecutter wrote: >> That is, there are licenses that create a problem for open >> systems use, and ones that don't. The GPL happens to be one that does. > > Can you point to a concrete example of the GPL causing such a problem? Callum, the GPL is constantly causing problems for people that want to take GPL code, modify it, and keep the modifications secret, while still distributing the modified work. In other words, the GPL doing what it's supposed to do. Some people have a problem with this concept, and they'll bring up any ridiculous argument they can to avoid coming out and saying their real problem with the GPL is that it prevents them from closing the code. -Jason From dzonatas at dzonux.net Wed Oct 3 18:51:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Oct 3 18:49:29 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <470443CD.7070902@gwala.net> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <47043C88.7060205@dzonux.net> <1191461355.11151.144.camel@localhost> <470443CD.7070902@gwala.net> Message-ID: <47044715.5020603@dzonux.net> Adam Frisby wrote: > This is something to be really really really careful of. Today, I'd > have no problems whatsoever trusting Linden Lab's behaviour - but > remember companies can be sold, or have their assets sold through > bankruptcy, and the new owner may not be quite so generous. > > It is under all circumstances best to make sure one is on decent legal > footing at all times. > > Adam > I completely agree! Due to work I have done prior to even LL ever being publicly open, I know it is best for both parties (and others) if I don't sign the Public Contribution Agreement. That doesn't mean I'm against that particular agreement, and it doesn't mean I don't trust LL. -- Power to Change the Void From secret.argent at gmail.com Wed Oct 3 18:54:36 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 3 18:54:29 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <470445A4.4040301@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> <470445A4.4040301@gmail.com> Message-ID: On 03-Oct-2007, at 20:45, Jason Giglio wrote: > Callum, the GPL is constantly causing problems for people that want > to take GPL code, modify it, and keep the modifications secret, > while still distributing the modified work. I routinely release my OWN code under a license that gives me LESS ability to control it than the GPL does, and I've been doing that longer than the GPL has been in existence, and you're accusing ME of being some kind of code miser. You've got a lot of bloody nerve, mate, that's all I can say. From 1337mail at gmail.com Wed Oct 3 18:58:30 2007 From: 1337mail at gmail.com (Michael Miller) Date: Wed Oct 3 18:58:33 2007 Subject: [sldev] Why won't isAvatar() work? Message-ID: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> At the end of the processObjectUpdate method(in llviewerobjectlist.cpp), I check to see if the object is an avatar(after everything in the "stock" source is done). The check looks like this: if(objectp && objectp->isAvatar()){ // Do stuff here } The problem lies in the objectp->isAvatar(). I've run this through gdb(I'm on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps throwing EXEC_BAD_ACCESS exceptions whenever the method is run(when calling isAvatar()). Is this because the objectp variable is "destroyed" or otherwise made inaccessible? How might I remedy this problem? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071003/06534d5b/attachment.htm From seg at haxxed.com Wed Oct 3 19:15:57 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 19:16:08 2007 Subject: [sldev] High-prim vehicles using phantom (Re: Havok4...) In-Reply-To: <5eff6d3b0710030820j403688fdr2d67b1f955610b55@mail.gmail.com> References: <47038825.8000003@ravenscall.net> <09D74E10-2D7B-4AC8-B58F-C35A799AD8A4@gmail.com> <5eff6d3b0710030820j403688fdr2d67b1f955610b55@mail.gmail.com> Message-ID: <1191464157.11151.158.camel@localhost> On Wed, 2007-10-03 at 11:20 -0400, Andre Roche wrote: > Unfortunately, according to Andrew and Sidewinder, the real issue with > vehicles above the 31 prim limit isn't physics interactions. It's > region hand-off. I'm not really sure exactly -what- the problem is, > but the claim is that it's not physics interactions themselves that > limit the prim count. This could be managed by giving priority to handing off only the 31 non-phantom prims from sim to sim. Handing off the rest can happen at a lower priority. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/0d9c41ef/attachment-0001.pgp From gigstaggart at gmail.com Wed Oct 3 19:51:54 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Oct 3 19:51:53 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> Message-ID: <4704554A.8000204@gmail.com> Michael Miller wrote: > if(objectp && objectp->isAvatar()){ > // Do stuff here > } > > The problem lies in the objectp->isAvatar(). I've run this through > gdb(I'm on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps > throwing EXEC_BAD_ACCESS exceptions whenever the method is run(when > calling isAvatar()). Is this because the objectp variable is "destroyed" > or otherwise made inaccessible? How might I remedy this problem? You are checking to see if it's NULL, so it's not... Looks like it's a dangling pointer. You somehow what objectp points to without nulling the pointer. Hint: Use a smart pointer (LLPointer) class and this won't happen nearly as much. -Jason From seg at haxxed.com Wed Oct 3 19:58:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 3 19:59:22 2007 Subject: [sldev] [META] GPL'd APIs (Re: Protocol Documentation) In-Reply-To: <989FEB3F-9084-4711-848B-9BB159B2088A@gmail.com> References: <4702C702.1030100@wsu.edu> <47041A76.4000106@knowprose.com> <4704013B.4020808@gwala.net> <200710032259.29237.dale@daleglass.net> <47040D7A.3030001@cox.net> <11DDB0AE-0443-4B71-AD7C-88B9BC1CD270@gmail.com> <47041C54.6090709@lindenlab.com> <1191459086.11151.129.camel@localhost> <989FEB3F-9084-4711-848B-9BB159B2088A@gmail.com> Message-ID: <1191466696.11151.159.camel@localhost> On Wed, 2007-10-03 at 20:38 -0500, Argent Stonecutter wrote: > First, I ALSO said that it was up to Linden Labs to say what was OK > or not, not the FSF. I'm just explaining WHY people are leary of the > GPL. Because this kind of stuff KEEPS happening. The FSF are the > GPL's worst enemies some times. You're only confusing the issue and adding to the FUD. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071003/ac599217/attachment.pgp From jhurliman at wsu.edu Wed Oct 3 20:10:59 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Oct 3 20:10:47 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <1191439036.11151.67.camel@localhost> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> <1191439036.11151.67.camel@localhost> Message-ID: <470459C3.8060505@wsu.edu> Callum Lerwick wrote: > Remember kids, Fantasy Real Estate Mogul is Serious Business. > > Don't shoot down everyone's fantasy now, for a moment I thought I was reading the VERN mailing list (http://virtual-economy.org/) but all of the actual economists went on vacation. John Hurliman From gigstaggart at gmail.com Wed Oct 3 21:10:35 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Oct 3 21:10:34 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> <470445A4.4040301@gmail.com> Message-ID: <470467BB.8040702@gmail.com> Argent Stonecutter wrote: > I routinely release my OWN code under a license that gives me LESS > ability to control it than the GPL does, and I've been doing that longer > than the GPL has been in existence, and you're accusing ME of being some > kind of code miser. You've got a lot of bloody nerve, mate, that's all I > can say. Hmm, I worded it badly. I should say there's two classes of people, those who want to do things the GPL doesn't allow them to do (which is a large group), and those who think everyone should have the right to do what the GPL doesn't allow them to do. You obviously are in the latter group. My point still remains, finding legal nitpicks and snafus that happen in the GPL world to pick on, when your real problem with the license is on a fundamental and philosophical level, that's kinda iffy in my book. -Jason From 1337mail at gmail.com Wed Oct 3 21:12:56 2007 From: 1337mail at gmail.com (Michael Miller) Date: Wed Oct 3 21:13:00 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <4704554A.8000204@gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <4704554A.8000204@gmail.com> Message-ID: <2c99c46e0710032112pa076752l1cbb51601454dd3e@mail.gmail.com> Jason,My apologies, but I am unable to understand fully what you mean. I understand that a pointer may be pointing to nothing(but even if(&objectp && objectp->isAvatar()) doesn't work). How would I make use of an LLPointer? Would this really help? Thanks, Mike On 10/3/07, Jason Giglio wrote: > > Michael Miller wrote: > > if(objectp && objectp->isAvatar()){ > > // Do stuff here > > } > > > > The problem lies in the objectp->isAvatar(). I've run this through > > gdb(I'm on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps > > throwing EXEC_BAD_ACCESS exceptions whenever the method is run(when > > calling isAvatar()). Is this because the objectp variable is "destroyed" > > or otherwise made inaccessible? How might I remedy this problem? > > You are checking to see if it's NULL, so it's not... Looks like it's a > dangling pointer. You somehow what objectp points to without nulling > the pointer. > > Hint: Use a smart pointer (LLPointer) class and this won't happen > nearly as much. > > -Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/c9e22a8f/attachment.htm From tateru.nino at gmail.com Wed Oct 3 21:35:57 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Oct 3 21:36:01 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <470467BB.8040702@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> <470445A4.4040301@gmail.com> <470467BB.8040702@gmail.com> Message-ID: <47046DAD.5060400@gmail.com> Jason Giglio wrote: > Argent Stonecutter wrote: >> I routinely release my OWN code under a license that gives me LESS >> ability to control it than the GPL does, and I've been doing that >> longer than the GPL has been in existence, and you're accusing ME of >> being some kind of code miser. You've got a lot of bloody nerve, >> mate, that's all I can say. > > Hmm, I worded it badly. I should say there's two classes of people, > those who want to do things the GPL doesn't allow them to do (which is > a large group), and those who think everyone should have the right to > do what the GPL doesn't allow them to do. > > You obviously are in the latter group. My point still remains, > finding legal nitpicks and snafus that happen in the GPL world to pick > on, when your real problem with the license is on a fundamental and > philosophical level, that's kinda iffy in my book. If you boys did this inworld, I could totally sell tickets. :) -- Tateru Nino http://dwellonit.blogspot.com/ From soft at lindenlab.com Thu Oct 4 03:37:06 2007 From: soft at lindenlab.com (Soft) Date: Thu Oct 4 03:37:08 2007 Subject: [sldev] Re: [VWR] 1.18.3RC Crash Reports In-Reply-To: <4703F99D.20900@blueflash.cc> References: <46FCF671.1000100@blueflash.cc> <4703F99D.20900@blueflash.cc> Message-ID: On 10/3/07, Nicholaz Beresford wrote: > > > This is on 1.18.3 build 5. I only churned as many as I could run > > overnight, so it's not a statistically significant set yet. I'll give > > it the full wiki treatment after I've got a weekend's worth of > > processing: > > Any updates on that yet? The crash reporter was re-broken by some python changes happening in our tree and has been doing nothing for a few days. I've rolled back to a working version and will drop more results after this processes another day or two. From dale at daleglass.net Thu Oct 4 03:48:13 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Oct 4 03:48:19 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710032112pa076752l1cbb51601454dd3e@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <4704554A.8000204@gmail.com> <2c99c46e0710032112pa076752l1cbb51601454dd3e@mail.gmail.com> Message-ID: <20071004104813.GA30283@bruno.sbruno> On Thu, Oct 04, 2007 at 12:12:56AM -0400, Michael Miller wrote: > Jason,My apologies, but I am unable to understand fully what you mean. I > understand that a pointer may be pointing to nothing(but even if(&objectp && > objectp->isAvatar()) doesn't work). How would I make use of an LLPointer? > Would this really help? The problem with manual memory management is that there can be confusion regarding what is freed when. For example, the viewer internally keeps tracks of objects which get constantly created and destroyed. It's possible to get a pointer to an object which isn't there anymore because it's been free'd. At that point you have a pointer pointing to something that used to be a object, but no longer is. Its memory may have well been overwritten by something completely unrelated. To prevent that, you can use a smart pointer, which automatically deletes an object when nothing is pointing at it anymore. This both prevents leaking memory (not in all cases) and freeing it prematurely. You declare it as LLPointer ptr = new LLViewerObject(); then you can copy ptr around, and when all copies disappear, the object will be freed. Note that for this to work the LLPointer needs to be created during the object's creation and be the one way to get a pointer to it. You can't just create a LLPointer from some normal pointer passed to you and have that work right. By that I mean that if you write a function like: void doStuff( LLViewerObject *vo ) { LLPointer ptr = vo; if ( ptr->isAvatar() ) { llinfos << "is an avatar" << llendl; } } Then that'll result in the object getting freed when the function returns, and that would be a very bad thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/30add375/attachment.pgp From nicholaz at blueflash.cc Thu Oct 4 04:10:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Oct 4 04:10:49 2007 Subject: [sldev] Re: [VWR] 1.18.3RC Crash Reports In-Reply-To: References: <46FCF671.1000100@blueflash.cc> <4703F99D.20900@blueflash.cc> Message-ID: <4704CA32.8010908@blueflash.cc> Soft wrote: > On 10/3/07, Nicholaz Beresford wrote: >> > This is on 1.18.3 build 5. I only churned as many as I could run >> > overnight, so it's not a statistically significant set yet. I'll give >> > it the full wiki treatment after I've got a weekend's worth of >> > processing: >> >> Any updates on that yet? > > The crash reporter was re-broken by some python changes happening in > our tree and has been doing nothing for a few days. I've rolled back > to a working version and will drop more results after this processes > another day or two. Thanks! Nick From 1337mail at gmail.com Thu Oct 4 04:21:57 2007 From: 1337mail at gmail.com (Michael Miller) Date: Thu Oct 4 04:22:01 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <20071004104813.GA30283@bruno.sbruno> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <4704554A.8000204@gmail.com> <2c99c46e0710032112pa076752l1cbb51601454dd3e@mail.gmail.com> <20071004104813.GA30283@bruno.sbruno> Message-ID: <2c99c46e0710040421s2a2e22aaucdbee51e49f27546@mail.gmail.com> Dale, That idea seems good, but a hack nonetheless(since it needs to be made at object creation). I want to modify the core SL code as little as possible. I remember in 1.18.1.2, the isAvatar() method worked at the end of the processObjectUpdate method. Has anything (significant) changed in this method since then? Are there no such smart pointers already in the code in the processObjectUpdate method? I'd rather (if at all possible) avoid using any code except at the end of the method after all the "original" SL code has been executed. -- MIke On 10/4/07, Dale Glass wrote: > > On Thu, Oct 04, 2007 at 12:12:56AM -0400, Michael Miller wrote: > > Jason,My apologies, but I am unable to understand fully what you mean. I > > understand that a pointer may be pointing to nothing(but even > if(&objectp && > > objectp->isAvatar()) doesn't work). How would I make use of an > LLPointer? > > Would this really help? > > The problem with manual memory management is that there can be confusion > regarding what is freed when. > > For example, the viewer internally keeps tracks of objects which get > constantly created and destroyed. It's possible to get a pointer to an > object which isn't there anymore because it's been free'd. At that > point you have a pointer pointing to something that used to be a > object, but no longer is. Its memory may have well been overwritten > by something completely unrelated. > > To prevent that, you can use a smart pointer, which automatically > deletes an object when nothing is pointing at it anymore. This both > prevents leaking memory (not in all cases) and freeing it prematurely. > > You declare it as LLPointer ptr = new LLViewerObject(); > > then you can copy ptr around, and when all copies disappear, the object > will be freed. > > Note that for this to work the LLPointer needs to be created during the > object's creation and be the one way to get a pointer to it. You can't > just create a LLPointer from some normal pointer passed to you and have > that work right. > > By that I mean that if you write a function like: > > void doStuff( LLViewerObject *vo ) > { > LLPointer ptr = vo; > if ( ptr->isAvatar() ) > { > llinfos << "is an avatar" << llendl; > } > } > > Then that'll result in the object getting freed when the function > returns, and that would be a very bad thing. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/456e41f3/attachment-0001.htm From dale at daleglass.net Thu Oct 4 04:42:00 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Oct 4 04:42:06 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710040421s2a2e22aaucdbee51e49f27546@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <4704554A.8000204@gmail.com> <2c99c46e0710032112pa076752l1cbb51601454dd3e@mail.gmail.com> <20071004104813.GA30283@bruno.sbruno> <2c99c46e0710040421s2a2e22aaucdbee51e49f27546@mail.gmail.com> Message-ID: <20071004114200.GB30283@bruno.sbruno> On Thu, Oct 04, 2007 at 07:21:57AM -0400, Michael Miller wrote: > Dale, > That idea seems good, but a hack nonetheless(since it needs to be made at > object creation). Well, it's what's available :-) > I want to modify the core SL code as little as possible. I > remember in 1.18.1.2, the isAvatar() method worked at the end of the > processObjectUpdate method. Has anything (significant) changed in this > method since then? Are there no such smart pointers already in the code in > the processObjectUpdate method? I'd rather (if at all possible) avoid using > any code except at the end of the method after all the "original" SL code > has been executed. Yes, it's probably very impractical to rewrite it to use a LLPointer. You may be running into an issue with the lifetime of objects. For example, if you get a pointer to an object, then store it for the duration of several frames, it may well disappear meanwhile if the user for example teleported. I'm not familiar with that bit yet, but you have to check the main loop for the general order in which things are done. If you're getting a pointer to something before the cleanup process, and try to use it after the cleanup, the object may have been deleted during cleanup. For things like that, it's a bad idea to keep pointers to them around. For example, don't keep a pointer to LLViewerObject* across frames. If you need to track an object over a long timeframe, keep its LLUUID, and gObjectList.findObject(uid) when you need a pointer. findObject will then return NULL if it's not there anymore. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/e214f446/attachment.pgp From nicholaz at blueflash.cc Thu Oct 4 04:52:17 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Oct 4 04:52:22 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> Message-ID: <4704D3F1.2090204@blueflash.cc> It depends on where you made your addition exactly. There are various paths which could lead to bad objectp pointers (especially outside the loop, since you say "at the end"). You will probably want to hook yourself into places where they do the processUpdateCore() where it should be clear that the pointer is valid because the source uses it. Nick Michael Miller wrote: > At the end of the processObjectUpdate method(in llviewerobjectlist.cpp), > I check to see if the object is an avatar(after everything in the > "stock" source is done). The check looks like this: > > if(objectp && objectp->isAvatar()){ > // Do stuff here > } > > The problem lies in the objectp->isAvatar(). I've run this through > gdb(I'm on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps > throwing EXEC_BAD_ACCESS exceptions whenever the method is run(when > calling isAvatar()). Is this because the objectp variable is "destroyed" > or otherwise made inaccessible? How might I remedy this problem? > > Thanks, > Mike > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Thu Oct 4 05:22:20 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Oct 4 05:22:31 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> Message-ID: <20071004122220.GA9396@bruno.sbruno> On Wed, Oct 03, 2007 at 09:58:30PM -0400, Michael Miller wrote: > At the end of the processObjectUpdate method(in llviewerobjectlist.cpp), I > check to see if the object is an avatar(after everything in the "stock" > source is done). The check looks like this: > > if(objectp && objectp->isAvatar()){ > // Do stuff here > } > > The problem lies in the objectp->isAvatar(). I've run this through gdb(I'm > on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps throwing > EXEC_BAD_ACCESS exceptions whenever the method is run(when calling > isAvatar()). Is this because the objectp variable is "destroyed" or > otherwise made inaccessible? How might I remedy this problem? > > Thanks, > Mike I looked a bit at the code. Do you do it at the end of the function, before the last line? Note how the function declares: LLViewerObject *objectp; Which isn't initialized. objectp remains uninitialized until: objectp = findObject(fullid); If for some reason the update affects 0 objects (don't know if that may ever happen), then objectp may remain uninitialized at the end of the function. But you should be adding your code somewhere inside the loop anyway, after objectp gets initialized. Change the declaration to: LLViewerObject *objectp = NULL; Crashes on NULL pointers are much easier to debug. > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/c435eb2b/attachment.pgp From 1337mail at gmail.com Thu Oct 4 05:41:32 2007 From: 1337mail at gmail.com (Michael Miller) Date: Thu Oct 4 05:41:34 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <20071004122220.GA9396@bruno.sbruno> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <20071004122220.GA9396@bruno.sbruno> Message-ID: <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> On 10/4/07, Dale Glass wrote: > > On Wed, Oct 03, 2007 at 09:58:30PM -0400, Michael Miller wrote: > > At the end of the processObjectUpdate method(in llviewerobjectlist.cpp), > I > > check to see if the object is an avatar(after everything in the "stock" > > source is done). The check looks like this: > > > > if(objectp && objectp->isAvatar()){ > > // Do stuff here > > } > > > > The problem lies in the objectp->isAvatar(). I've run this through > gdb(I'm > > on Mac OSX "non-10.4 platform"), and the isAvatar() method keeps > throwing > > EXEC_BAD_ACCESS exceptions whenever the method is run(when calling > > isAvatar()). Is this because the objectp variable is "destroyed" or > > otherwise made inaccessible? How might I remedy this problem? > > > > Thanks, > > Mike > > I looked a bit at the code. Do you do it at the end of the function, > before the last line? Yes, I do it right before the closing brace of the method(after every last bit of SL code has been executed). Note how the function declares: > LLViewerObject *objectp; > > Which isn't initialized. > > objectp remains uninitialized until: > objectp = findObject(fullid); > > > If for some reason the update affects 0 objects (don't know if that may > ever happen), then objectp may remain uninitialized at the end of the > function. But you should be adding your code somewhere inside the loop > anyway, after objectp gets initialized. > > > Change the declaration to: > LLViewerObject *objectp = NULL; > > Crashes on NULL pointers are much easier to debug. I'll give it a shot. Should(will) this declaration be edited in the main SL codebase (assuming it works)? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/fe635bda/attachment.htm From dale at daleglass.net Thu Oct 4 05:54:00 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Oct 4 05:54:06 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <20071004122220.GA9396@bruno.sbruno> <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> Message-ID: <20071004125400.GB17807@bruno.sbruno> On Thu, Oct 04, 2007 at 08:41:32AM -0400, Michael Miller wrote: > > > Yes, I do it right before the closing brace of the method(after every last > bit of SL code has been executed). Then that may be wrong, as there can be multiple objects, and you'll be only processing the last one if you do that. > I'll give it a shot. Should(will) this declaration be edited in the main SL > codebase (assuming it works)? I think it should. It's good practice to initialize all pointers to NULL. Then when it gets accessed before it's initialized it always crashes right there, and you don't have to wonder where all those bizarre values came from when looking at the object in the debugger. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/712879bd/attachment.pgp From nicholaz at blueflash.cc Thu Oct 4 05:59:08 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Oct 4 05:59:13 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <20071004122220.GA9396@bruno.sbruno> <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> Message-ID: <4704E39C.2090102@blueflash.cc> Michael Miller wrote: > I looked a bit at the code. Do you do it at the end of the function, > before the last line? > > Yes, I do it right before the closing brace of the method(after every > last bit of SL code has been executed). Try putting it inside the for loop (second closing curly brace from bottom). Otherwise you may miss object updates anyway (the function can handle more objects and outside the loop you'll only get one (if any at all). > Change the declaration to: > LLViewerObject *objectp = NULL; > > Crashes on NULL pointers are much easier to debug. > > I'll give it a shot. Should(will) this declaration be edited in the main > SL codebase (assuming it works)? I doubt there'll be a reason to merge this with the official viewer because it's not a bug and if something is required for your extensions, you'll need to to do it yourself. But putting your code inside the loop where it most likely belongs to anyway, will solve this problem. Nick From dale at daleglass.net Thu Oct 4 06:01:35 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Oct 4 06:01:48 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <4704E39C.2090102@blueflash.cc> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <20071004122220.GA9396@bruno.sbruno> <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> <4704E39C.2090102@blueflash.cc> Message-ID: <20071004130135.GC17807@bruno.sbruno> On Thu, Oct 04, 2007 at 02:59:08PM +0200, Nicholaz Beresford wrote: > I doubt there'll be a reason to merge this with the official viewer > because it's not a bug and if something is required for your extensions, > you'll need to to do it yourself. Well, it's good coding practice. I'd submit that one change as a cleanup patch. If they accept it, good, if not then it'll work fine as it was anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/98a3acc8/attachment.pgp From cnd at knowprose.com Thu Oct 4 09:48:56 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Thu Oct 4 07:52:37 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> Message-ID: <47051978.70703@knowprose.com> Harold Brown wrote: > > > allow the person standing next to > > them who they intended to sell the land to, to purchase etc. > (but not > > add yet more dialog boxes checking that they want to proceed), so my > > The current land sale system already has a method to specify WHO you > want to be able to buy a parcel of land. If you are not using it it is > not LL's fault. > There is also a final screen that comes up to allow you to verify the > sale settings BEFORE you click "APPLY" When people are consistently having issues with an interface, maybe the interface is at fault. The evidence of people having problems with the interface can be dismissed easily, every time, by saying that the users are at fault. Microsoft does it, now Linden Lab does it... but blaming the users is a pretty lame way to do design. The interface could be done better. If the interface were done better and a method of protecting people from their mistakes and software issues were in place, imagine how much time we would save by not having this conversation repeatedly. -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From cnd at knowprose.com Thu Oct 4 09:58:49 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Thu Oct 4 08:02:39 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> Message-ID: <47051BC9.5050706@knowprose.com> Matthew Dowd wrote: > > >> Whatever you may personally feel about landbots - their use is not > >> illegal in SL nor against the TOS. > >Lets quit mixing 'legality' and ToS. ToS is a contract, subject to > >contract law. It is not *THE* Law. > > I never said it was *THE* law - the word "illegal" can be quite > legitimately used as a synonym for banned, prohibited etc. without it > necessarily being anything to do the the Law of the land. No. The word 'illegal' has very different connotations. It quite literally means, "against the law". Against ToS? Against Community Standards? Legitimate. Saying something is illegal is a very different thing. The ToS and Community Standards have been in court at least once, and were modified due partly to the legality of the ToS itself. I fully expect 'fictional currency' to be the next sticking point. -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From cnd at knowprose.com Thu Oct 4 10:03:49 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Thu Oct 4 08:07:27 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> Message-ID: <47051CF5.2060404@knowprose.com> Argent Stonecutter wrote: > So if the code was released under one of these licenses it would not > create a situation where someone using the code as documentation would > automatically be at risk of being placed in a position where they had > to defend their work. The original voice API license, Microsoft's > license on some of their documentation, all have similar issues. That > is, there are licenses that create a problem for open systems use, and > ones that don't. The GPL happens to be one that does. So if we boil down every license and stick arrows tips in the resulting gunk, can we shoot lawyers with them? I have yet to see an actual case where the GPL creates a problem for open systems use. This is a Holy War, and I don't see the point of continuing this discussion when it is largely due to opinions. Plenty of code out there, plenty of licenses. Lots of lawyers. The only people who make money off of license wars are lawyers. -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From labrat.hb at gmail.com Thu Oct 4 08:52:34 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Oct 4 08:52:42 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <47051BC9.5050706@knowprose.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: The current Land Sale interface is the way it currently is... because that's what people wanted. They told LL's "You do this and it will solve all our land sale problems" They did it... and people are still bitching about it.. but not because of land swoopers (the generation before bots) but because of bots. The complaints are generated mostly by other "Land Barons" who don't have bots and can't compete at the more lucrative low price land flip. A CAPTCHA on PURCHASE will not prevent people from screwing up and putting their land up for sale too cheap. A delay on showing in the listings will not prevent people from putting their land up for sale too cheap. So what complaint do we really have? 1. The interface is so confusing it causes people to make mistakes in selling land 2. Land Bots can find and buy land faster then a human If your complaint is #1, design a UI layout / flow that can prevent mistakes, but don't keep dragging up how landbots can find cheap land If your complaint is #2, design something you feel will improve the situation. But remember that there is always going to be someone who will be able to automate most processes and will still be faster. On 10/4/07, Taran Rampersad wrote: > > Matthew Dowd wrote: > > > > >> Whatever you may personally feel about landbots - their use is not > > >> illegal in SL nor against the TOS. > > >Lets quit mixing 'legality' and ToS. ToS is a contract, subject to > > >contract law. It is not *THE* Law. > > > > I never said it was *THE* law - the word "illegal" can be quite > > legitimately used as a synonym for banned, prohibited etc. without it > > necessarily being anything to do the the Law of the land. > No. The word 'illegal' has very different connotations. It quite > literally means, "against the law". > > Against ToS? Against Community Standards? Legitimate. Saying something > is illegal is a very different thing. The ToS and Community Standards > have been in court at least once, and were modified due partly to the > legality of the ToS itself. > > I fully expect 'fictional currency' to be the next sticking point. > > -- > Taran Rampersad > Presently in: Paramaribo, Suriname > cnd@knowprose.com > > http://www.knowprose.com > http://www.your2ndplace.com > > Pictures: http://www.flickr.com/photos/knowprose/ > > "Criticize by creating." ? Michelangelo > "The present is theirs; the future, for which I really worked, is mine." - > Nikola Tesla > > _______________________________________________ > 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/20071004/baeeb944/attachment.htm From seg at haxxed.com Thu Oct 4 10:23:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Oct 4 10:24:07 2007 Subject: [sldev] [VWR] VBO is broken Message-ID: <1191518629.11151.208.camel@localhost> So, it seems I can't be a luddite and log in with 1.18.0.6 anymore. Unfortunately, I haven't had a chance to complete a differential profile between 1.18.0.6 and a current viewer to figure out what's going so horribly wrong. 1.18.3.5 is still unusable on x86_64. I am not crazy: http://jira.secondlife.com/browse/VWR-2303 http://jira.secondlife.com/browse/VWR-2477 http://jira.secondlife.com/browse/VWR-2518 http://jira.secondlife.com/browse/VWR-2565 It is now clear that VBO is where the rapid, unbounded memory leak on x86_64 lies. Turning off VBO makes it at least somewhat usable. I'm not sure why the memory leak doesn't seem to happen on i386. Its still much slower, and RAM usage is still much higher, than 1.18.0.6, and that seems to be true on i386 as well. And I don't think the lack of VBO entirely accounts for it. The VBO leak doesn't seem to be the only problem, which is why I'm hesitant to dupe all those bugs together. So much for message liberation. I asked previously about disabling the optional update check. It seems now I need to disable the required update as well: --- linden.orig/indra/newview/llstartup.cpp 2007-10-04 10:09:56.000000000 -0500 +++ linden.patched/indra/newview/llstartup.cpp 2007-10-04 09:43:55.000000000 -0500 @@ -201,7 +201,6 @@ LLPointer gStartImageGL; static LLHost gAgentSimHost; -static BOOL gSkipOptionalUpdate = FALSE; bool gUseQuickTime = true; bool gQuickTimeInitialized = false; @@ -339,12 +338,7 @@ gViewerWindow->handlePerFrameHover(); LLMortician::updateClass(); - if (gNoRender) - { - // HACK, skip optional updates if you're running drones - gSkipOptionalUpdate = TRUE; - } - else + if (!gNoRender) { // Update images? gImageList.updateImages(0.01f); @@ -960,7 +954,7 @@ lastname.c_str(), password.c_str(), start.str().c_str(), - gSkipOptionalUpdate, + TRUE, gAcceptTOS, gAcceptCriticalMessage, gViewerDigest, @@ -1122,7 +1116,7 @@ // Clear the password password = ""; } - if(reason_response && (0 == strcmp(reason_response, "update"))) + if(FALSE && reason_response && (0 == strcmp(reason_response, "update"))) { auth_message = gUserAuthp->getResponse("message"); if (show_connect_box) @@ -1144,7 +1138,6 @@ { update_app(FALSE, auth_message); gStartupState = STATE_UPDATE_CHECK; - gSkipOptionalUpdate = TRUE; return FALSE; } } diff -urN -x '*.orig' -x '*.rej' -x '*~' -x '.*' -x '*-linux-client-release' linden.orig/indra/newview/lluserauth.cpp linden.patched/indra/newview/lluserauth.cpp --- linden.orig/indra/newview/lluserauth.cpp 2007-07-11 17:17:02.000000000 -0500 +++ linden.patched/indra/newview/lluserauth.cpp 2007-10-04 10:19:01.000000000 -0500 @@ -121,9 +121,7 @@ XMLRPC_VectorAppendString(params, "start", start, 0); char buffer[MAX_STRING]; /* Flawfinder: ignore */ // the version is treated as a single string - snprintf(buffer, MAX_STRING, "%d.%d.%d.%d", - LL_VERSION_MAJOR, LL_VERSION_MINOR, LL_VERSION_PATCH, LL_VIEWER_BUILD); /* Flawfinder: ignore */ - XMLRPC_VectorAppendString(params, "version", buffer, 0); + XMLRPC_VectorAppendString(params, "version", "1.18.99.99", 0); XMLRPC_VectorAppendString(params, "channel", gChannelName.c_str(), 0); XMLRPC_VectorAppendString(params, "platform", PLATFORM_STRING, 0); XMLRPC_VectorAppendString(params, "mac", hashed_mac.c_str(), 0); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/e4fbec99/attachment.pgp From secret.argent at gmail.com Thu Oct 4 10:33:05 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 4 10:33:14 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: <6C345974-A4DE-49CD-9FCD-EA8FF1500D0E@gmail.com> On 04-Oct-2007, at 10:52, Harold Brown wrote: > 1. The interface is so confusing it causes people to make mistakes > in selling land > 2. Land Bots can find and buy land faster then a human 3. Land It's got nothing to do with speed or mistakes, it has to do with taking the human out of the loop. That's always been the problem with bots, they change the market and make it less effective. In the name of efficiency, they keep the most efficient tool for managing resources from working effectively by making the market reflect the behavior of software rather than people. This is a problem, whether it's in SL land sales or the stock market. Last year around this time we were watching it happen completely out of control, as bots bought land and resold it to other bots in a feedback loop that LL finally broke by flooding the market with land. That doesn't solve the problem, it reduces margins and makes it harder for the resellers... whether they're using bots or not.... but the tail of the market remains suppressed and prices remain higher than they would in an equilibrium without the bots. From dzonatas at dzonux.net Thu Oct 4 10:56:05 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Oct 4 10:53:57 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <6C345974-A4DE-49CD-9FCD-EA8FF1500D0E@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> <6C345974-A4DE-49CD-9FCD-EA8FF1500D0E@gmail.com> Message-ID: <47052935.3030601@dzonux.net> Argent Stonecutter wrote: > On 04-Oct-2007, at 10:52, Harold Brown wrote: >> 1. The interface is so confusing it causes people to make mistakes in >> selling land >> 2. Land Bots can find and buy land faster then a human > > 3. Land It's got nothing to do with speed or mistakes, it has to do > with taking the human out of the loop. > Taking the human out of the loop is a good thing in the real estate business. (course, with common sense) -- Power to Change the Void From robla at lindenlab.com Thu Oct 4 11:51:58 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Oct 4 11:52:08 2007 Subject: [sldev] [VWR] Update channel (Re: VBO is broken) In-Reply-To: <1191518629.11151.208.camel@localhost> References: <1191518629.11151.208.camel@localhost> Message-ID: <4705364E.4080205@lindenlab.com> You should be able to create a separate update channel to get out of the update, rather than faking version numbers. If you aren't able to, that's a bug. Rob On 10/4/07 10:23 AM, Callum Lerwick wrote: > So, it seems I can't be a luddite and log in with 1.18.0.6 anymore. > Unfortunately, I haven't had a chance to complete a differential profile > between 1.18.0.6 and a current viewer to figure out what's going so > horribly wrong. 1.18.3.5 is still unusable on x86_64. > > I am not crazy: > > http://jira.secondlife.com/browse/VWR-2303 > http://jira.secondlife.com/browse/VWR-2477 > http://jira.secondlife.com/browse/VWR-2518 > http://jira.secondlife.com/browse/VWR-2565 > > It is now clear that VBO is where the rapid, unbounded memory leak on > x86_64 lies. Turning off VBO makes it at least somewhat usable. I'm not > sure why the memory leak doesn't seem to happen on i386. Its still much > slower, and RAM usage is still much higher, than 1.18.0.6, and that > seems to be true on i386 as well. And I don't think the lack of VBO > entirely accounts for it. The VBO leak doesn't seem to be the only > problem, which is why I'm hesitant to dupe all those bugs together. > > So much for message liberation. I asked previously about disabling the > optional update check. It seems now I need to disable the required > update as well: > > --- linden.orig/indra/newview/llstartup.cpp 2007-10-04 10:09:56.000000000 -0500 > +++ linden.patched/indra/newview/llstartup.cpp 2007-10-04 09:43:55.000000000 -0500 > @@ -201,7 +201,6 @@ > LLPointer gStartImageGL; > > static LLHost gAgentSimHost; > -static BOOL gSkipOptionalUpdate = FALSE; > > bool gUseQuickTime = true; > bool gQuickTimeInitialized = false; > @@ -339,12 +338,7 @@ > gViewerWindow->handlePerFrameHover(); > LLMortician::updateClass(); > > - if (gNoRender) > - { > - // HACK, skip optional updates if you're running drones > - gSkipOptionalUpdate = TRUE; > - } > - else > + if (!gNoRender) > { > // Update images? > gImageList.updateImages(0.01f); > @@ -960,7 +954,7 @@ > lastname.c_str(), > password.c_str(), > start.str().c_str(), > - gSkipOptionalUpdate, > + TRUE, > gAcceptTOS, > gAcceptCriticalMessage, > gViewerDigest, > @@ -1122,7 +1116,7 @@ > // Clear the password > password = ""; > } > - if(reason_response && (0 == strcmp(reason_response, "update"))) > + if(FALSE && reason_response && (0 == strcmp(reason_response, "update"))) > { > auth_message = gUserAuthp->getResponse("message"); > if (show_connect_box) > @@ -1144,7 +1138,6 @@ > { > update_app(FALSE, auth_message); > gStartupState = STATE_UPDATE_CHECK; > - gSkipOptionalUpdate = TRUE; > return FALSE; > } > } > diff -urN -x '*.orig' -x '*.rej' -x '*~' -x '.*' -x '*-linux-client-release' linden.orig/indra/newview/lluserauth.cpp linden.patched/indra/newview/lluserauth.cpp > --- linden.orig/indra/newview/lluserauth.cpp 2007-07-11 17:17:02.000000000 -0500 > +++ linden.patched/indra/newview/lluserauth.cpp 2007-10-04 10:19:01.000000000 -0500 > @@ -121,9 +121,7 @@ > XMLRPC_VectorAppendString(params, "start", start, 0); > char buffer[MAX_STRING]; /* Flawfinder: ignore */ > // the version is treated as a single string > - snprintf(buffer, MAX_STRING, "%d.%d.%d.%d", > - LL_VERSION_MAJOR, LL_VERSION_MINOR, LL_VERSION_PATCH, LL_VIEWER_BUILD); /* Flawfinder: ignore */ > - XMLRPC_VectorAppendString(params, "version", buffer, 0); > + XMLRPC_VectorAppendString(params, "version", "1.18.99.99", 0); > XMLRPC_VectorAppendString(params, "channel", gChannelName.c_str(), 0); > XMLRPC_VectorAppendString(params, "platform", PLATFORM_STRING, 0); > XMLRPC_VectorAppendString(params, "mac", hashed_mac.c_str(), 0); > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/ce63dbd6/signature.pgp From matthew.dowd at hotmail.co.uk Thu Oct 4 12:15:44 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Oct 4 12:15:46 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: Well, my suggestion (and others have made it too) would be a five minute moratorium after land is set for sale during which time *only* those present on the sim when the land was set for sale can buy. It provides a breathing space for second thoughts, mistake correction, correction of mispriced land due to software glitches/lag etc. before a bot can run in and purchase the land. It supports the typical scenario of "buyer was present and no-one else was so I thought it was safe to set to sale to anyone and that setting for sale to a specific person was just an additional sequence of unnecessary steps..." It *is* theoretically possible that someone could get around this by running enough bots - either as many bots as mainland sims, or at least a large enough number that there is a good statistical probability of being in a sim when land is set for sale... Matthew So what complaint do we really have? 1. The interface is so confusing it causes people to make mistakes in selling land 2. Land Bots can find and buy land faster then a human _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/c168e6b8/attachment.htm From rdw at lindenlab.com Thu Oct 4 12:15:50 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Thu Oct 4 12:16:13 2007 Subject: [sldev] [VWR] Update channel (Re: VBO is broken) In-Reply-To: <4705364E.4080205@lindenlab.com> References: <1191518629.11151.208.camel@localhost> <4705364E.4080205@lindenlab.com> Message-ID: <47053BE6.70004@lindenlab.com> I.e. pass --channel "My Fake Channel" on the command line. -RYaN Rob Lanphier wrote: > You should be able to create a separate update channel to get out of the > update, rather than faking version numbers. If you aren't able to, > that's a bug. > > Rob > > On 10/4/07 10:23 AM, Callum Lerwick wrote: > >> So, it seems I can't be a luddite and log in with 1.18.0.6 anymore. >> Unfortunately, I haven't had a chance to complete a differential profile >> between 1.18.0.6 and a current viewer to figure out what's going so >> horribly wrong. 1.18.3.5 is still unusable on x86_64. >> >> I am not crazy: >> >> http://jira.secondlife.com/browse/VWR-2303 >> http://jira.secondlife.com/browse/VWR-2477 >> http://jira.secondlife.com/browse/VWR-2518 >> http://jira.secondlife.com/browse/VWR-2565 >> >> It is now clear that VBO is where the rapid, unbounded memory leak on >> x86_64 lies. Turning off VBO makes it at least somewhat usable. I'm not >> sure why the memory leak doesn't seem to happen on i386. Its still much >> slower, and RAM usage is still much higher, than 1.18.0.6, and that >> seems to be true on i386 as well. And I don't think the lack of VBO >> entirely accounts for it. The VBO leak doesn't seem to be the only >> problem, which is why I'm hesitant to dupe all those bugs together. >> >> So much for message liberation. I asked previously about disabling the >> optional update check. It seems now I need to disable the required >> update as well: >> >> --- linden.orig/indra/newview/llstartup.cpp 2007-10-04 10:09:56.000000000 -0500 >> +++ linden.patched/indra/newview/llstartup.cpp 2007-10-04 09:43:55.000000000 -0500 >> @@ -201,7 +201,6 @@ >> LLPointer gStartImageGL; >> >> static LLHost gAgentSimHost; >> -static BOOL gSkipOptionalUpdate = FALSE; >> >> bool gUseQuickTime = true; >> bool gQuickTimeInitialized = false; >> @@ -339,12 +338,7 @@ >> gViewerWindow->handlePerFrameHover(); >> LLMortician::updateClass(); >> >> - if (gNoRender) >> - { >> - // HACK, skip optional updates if you're running drones >> - gSkipOptionalUpdate = TRUE; >> - } >> - else >> + if (!gNoRender) >> { >> // Update images? >> gImageList.updateImages(0.01f); >> @@ -960,7 +954,7 @@ >> lastname.c_str(), >> password.c_str(), >> start.str().c_str(), >> - gSkipOptionalUpdate, >> + TRUE, >> gAcceptTOS, >> gAcceptCriticalMessage, >> gViewerDigest, >> @@ -1122,7 +1116,7 @@ >> // Clear the password >> password = ""; >> } >> - if(reason_response && (0 == strcmp(reason_response, "update"))) >> + if(FALSE && reason_response && (0 == strcmp(reason_response, "update"))) >> { >> auth_message = gUserAuthp->getResponse("message"); >> if (show_connect_box) >> @@ -1144,7 +1138,6 @@ >> { >> update_app(FALSE, auth_message); >> gStartupState = STATE_UPDATE_CHECK; >> - gSkipOptionalUpdate = TRUE; >> return FALSE; >> } >> } >> diff -urN -x '*.orig' -x '*.rej' -x '*~' -x '.*' -x '*-linux-client-release' linden.orig/indra/newview/lluserauth.cpp linden.patched/indra/newview/lluserauth.cpp >> --- linden.orig/indra/newview/lluserauth.cpp 2007-07-11 17:17:02.000000000 -0500 >> +++ linden.patched/indra/newview/lluserauth.cpp 2007-10-04 10:19:01.000000000 -0500 >> @@ -121,9 +121,7 @@ >> XMLRPC_VectorAppendString(params, "start", start, 0); >> char buffer[MAX_STRING]; /* Flawfinder: ignore */ >> // the version is treated as a single string >> - snprintf(buffer, MAX_STRING, "%d.%d.%d.%d", >> - LL_VERSION_MAJOR, LL_VERSION_MINOR, LL_VERSION_PATCH, LL_VIEWER_BUILD); /* Flawfinder: ignore */ >> - XMLRPC_VectorAppendString(params, "version", buffer, 0); >> + XMLRPC_VectorAppendString(params, "version", "1.18.99.99", 0); >> XMLRPC_VectorAppendString(params, "channel", gChannelName.c_str(), 0); >> XMLRPC_VectorAppendString(params, "platform", PLATFORM_STRING, 0); >> XMLRPC_VectorAppendString(params, "mac", hashed_mac.c_str(), 0); >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 nicholaz at blueflash.cc Thu Oct 4 12:21:07 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Oct 4 12:21:19 2007 Subject: [sldev] [VWR] VBO is broken In-Reply-To: <1191518629.11151.208.camel@localhost> References: <1191518629.11151.208.camel@localhost> Message-ID: <47053D23.3030008@blueflash.cc> Try the one attached. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- --- linden-orig/indra/llcharacter/llmotion.cpp 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llmotion.cpp 2007-09-14 13:44:39.200250000 +0200 @@ -126,11 +126,6 @@ mDeactivateCallbackUserData = userdata; } -BOOL LLMotion::isBlending() -{ - return mPose.getWeight() < 1.f; -} - //----------------------------------------------------------------------------- // activate() //----------------------------------------------------------------------------- @@ -147,16 +142,10 @@ void LLMotion::deactivate() { mActive = FALSE; - mPose.setWeight(0.f); if (mDeactivateCallback) (*mDeactivateCallback)(mDeactivateCallbackUserData); onDeactivate(); } -BOOL LLMotion::canDeprecate() -{ - return TRUE; -} - // End --- linden-orig/indra/llcharacter/llmotion.h 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llmotion.h 2007-09-14 13:44:40.794000000 +0200 @@ -99,14 +99,13 @@ void setStopped(BOOL stopped) { mStopped = stopped; } - BOOL isBlending(); - void activate(); void deactivate(); BOOL isActive() { return mActive; } + public: //------------------------------------------------------------------------- // animation callbacks to be implemented by subclasses @@ -146,11 +145,6 @@ // called when a motion is deactivated virtual void onDeactivate() = 0; - // can we crossfade this motion with a new instance when restarted? - // should ultimately always be TRUE, but lack of emote blending, etc - // requires this - virtual BOOL canDeprecate(); - // optional callback routine called when animation deactivated. void setDeactivateCallback( void (*cb)(void *), void* userdata ); --- linden-orig/indra/llcharacter/llmotioncontroller.cpp 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.cpp 2007-09-14 13:44:42.122125000 +0200 @@ -194,44 +194,34 @@ //----------------------------------------------------------------------------- void LLMotionController::addLoadedMotion(LLMotion* motionp) { - std::set motions_to_kill; - - // gather all inactive, loaded motions if (mLoadedMotions.size() > MAX_MOTION_INSTANCES) { // too many motions active this frame, kill all blenders mPoseBlender.clearBlenders(); - for (motion_list_t::iterator loaded_motion_it = mLoadedMotions.begin(); - loaded_motion_it != mLoadedMotions.end(); - ++loaded_motion_it) + for (U32 i = 0; i < mLoadedMotions.size(); i++) { - LLMotion* cur_motionp = *loaded_motion_it; + LLMotion* cur_motionp = mLoadedMotions.front(); + mLoadedMotions.pop_front(); // motion isn't playing, delete it if (!isMotionActive(cur_motionp)) { - motions_to_kill.insert(cur_motionp->getID()); + mCharacter->requestStopMotion(cur_motionp); + mAllMotions.erase(cur_motionp->getID()); + delete cur_motionp; + if (mLoadedMotions.size() <= MAX_MOTION_INSTANCES) + { + break; + } + } + else + { + // put active motion on back + mLoadedMotions.push_back(cur_motionp); } } } - - // clean up all inactive, loaded motions - for (std::set::iterator motion_it = motions_to_kill.begin(); - motion_it != motions_to_kill.end(); - ++motion_it) - { - // look up the motion again by ID to get canonical instance - // and kill it only if that one is inactive - LLUUID motion_id = *motion_it; - LLMotion* motionp = findMotion(motion_id); - if (motionp && !isMotionActive(motionp)) - { - removeMotion(motion_id); - } - } - - // add new motion to loaded list mLoadedMotions.push_back(motionp); } @@ -290,24 +280,14 @@ void LLMotionController::removeMotion( const LLUUID& id) { LLMotion* motionp = findMotion(id); - - removeMotionInstance(motionp); - - mAllMotions.erase(id); -} - -// removes instance of a motion from all runtime structures, but does -// not erase entry by ID, as this could be a duplicate instance -// use removeMotion(id) to remove all references to a given motion by id. -void LLMotionController::removeMotionInstance(LLMotion* motionp) -{ if (motionp) { - stopMotionInstance(motionp, TRUE); + stopMotionLocally(id, TRUE); mLoadingMotions.erase(motionp); mLoadedMotions.remove(motionp); mActiveMotions.remove(motionp); + mAllMotions.erase(id); delete motionp; } } @@ -368,39 +348,28 @@ //----------------------------------------------------------------------------- BOOL LLMotionController::startMotion(const LLUUID &id, F32 start_offset) { - // do we have an instance of this motion for this character? - LLMotion *motion = findMotion(id); - - // motion that is stopping will be allowed to stop but - // replaced by a new instance of that motion - if (motion - && motion->canDeprecate() - && motion->getFadeWeight() > 0.01f // not LOD-ed out - && (motion->isBlending() || motion->getStopTime() != 0.f)) - { - deprecateMotionInstance(motion); - // force creation of new instance - motion = NULL; - } - - // create new motion instance - if (!motion) - { - motion = createMotion(id); - } + // look for motion in our list of created motions + LLMotion *motion = createMotion(id); if (!motion) { return FALSE; } - //if the motion is already active and allows deprecation, then let it keep playing - else if (motion->canDeprecate() && isMotionActive(motion)) + //if the motion is already active, then we're done + else if (isMotionActive(motion)) // motion is playing and... { - return TRUE; + if (motion->isStopped()) // motion has been stopped + { + deactivateMotion(motion, false); + } + else if (mTime < motion->mSendStopTimestamp) // motion is still active + { + return TRUE; + } } // llinfos << "Starting motion " << name << llendl; - return activateMotionInstance(motion, mTime - start_offset); + return activateMotion(motion, mTime - start_offset); } @@ -411,12 +380,6 @@ { // if already inactive, return false LLMotion *motion = findMotion(id); - - return stopMotionInstance(motion, stop_immediate); -} - -BOOL LLMotionController::stopMotionInstance(LLMotion* motion, BOOL stop_immediate) -{ if (!motion) { return FALSE; @@ -433,7 +396,7 @@ if (stop_immediate) { - deactivateMotionInstance(motion); + deactivateMotion(motion, false); } return TRUE; } @@ -529,7 +492,7 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - deactivateMotionInstance(motionp); + deactivateMotion(motionp, false); } else if (motionp->isStopped() && mTime > motionp->getStopTime()) { @@ -547,7 +510,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionInstance(motionp, FALSE); + stopMotionLocally(motionp->getID(), FALSE); } } else if (mTime >= motionp->mActivationTimestamp) @@ -575,7 +538,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionInstance(motionp, FALSE); + stopMotionLocally(motionp->getID(), FALSE); } } @@ -583,8 +546,7 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - posep->setWeight(0.f); - deactivateMotionInstance(motionp); + deactivateMotion(motionp, true); } continue; } @@ -610,8 +572,7 @@ } else { - posep->setWeight(0.f); - deactivateMotionInstance(motionp); + deactivateMotion(motionp, true); continue; } } @@ -656,7 +617,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionInstance(motionp, FALSE); + stopMotionLocally(motionp->getID(), FALSE); } } @@ -700,7 +661,7 @@ // propagate this to the network // as not all viewers are guaranteed to have access to the same logic mCharacter->requestStopMotion( motionp ); - stopMotionInstance(motionp, FALSE); + stopMotionLocally(motionp->getID(), FALSE); } } @@ -772,7 +733,7 @@ // this motion should be playing if (!motionp->isStopped()) { - activateMotionInstance(motionp, mTime); + activateMotion(motionp, mTime); } } else if (status == LLMotion::STATUS_FAILURE) @@ -780,7 +741,6 @@ llinfos << "Motion " << motionp->getID() << " init failed." << llendl; sRegistry.markBad(motionp->getID()); mLoadingMotions.erase(curiter); - mAllMotions.erase(motionp->getID()); delete motionp; } @@ -813,9 +773,9 @@ //----------------------------------------------------------------------------- -// activateMotionInstance() +// activateMotion() //----------------------------------------------------------------------------- -BOOL LLMotionController::activateMotionInstance(LLMotion *motion, F32 time) +BOOL LLMotionController::activateMotion(LLMotion *motion, F32 time) { if (mLoadingMotions.find(motion) != mLoadingMotions.end()) { @@ -858,38 +818,23 @@ } //----------------------------------------------------------------------------- -// deactivateMotionInstance() +// deactivateMotion() //----------------------------------------------------------------------------- -BOOL LLMotionController::deactivateMotionInstance(LLMotion *motion) +BOOL LLMotionController::deactivateMotion(LLMotion *motion, bool remove_weight) { - motion->deactivate(); - - motion_set_t::iterator found_it = mDeprecatedMotions.find(motion); - if (found_it != mDeprecatedMotions.end()) - { - // deprecated motions need to be completely excised - removeMotionInstance(motion); - mDeprecatedMotions.erase(found_it); - } - else + if( remove_weight ) { - // for motions that we are keeping, simply remove from active queue - mActiveMotions.remove(motion); + // immediately remove pose weighting instead of letting it time out + LLPose *posep = motion->getPose(); + posep->setWeight(0.f); } + + motion->deactivate(); + mActiveMotions.remove(motion); return TRUE; } -void LLMotionController::deprecateMotionInstance(LLMotion* motion) -{ - mDeprecatedMotions.insert(motion); - - //fade out deprecated motion - stopMotionInstance(motion, FALSE); - //no longer canonical - mAllMotions.erase(motion->getID()); -} - //----------------------------------------------------------------------------- // isMotionActive() //----------------------------------------------------------------------------- @@ -912,7 +857,7 @@ //----------------------------------------------------------------------------- LLMotion *LLMotionController::findMotion(const LLUUID& id) { - return get_if_there(mAllMotions, id, NULL); + return mAllMotions[id]; } //----------------------------------------------------------------------------- --- linden-orig/indra/llcharacter/llmotioncontroller.h 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.h 2007-09-14 13:44:42.840875000 +0200 @@ -179,21 +179,16 @@ LLMotion *findMotion( const LLUUID& id ); protected: - // internal operations act on motion instances directly - // as there can be duplicate motions per id during blending overlap void deleteAllMotions(); void addLoadedMotion(LLMotion *motion); - BOOL activateMotionInstance(LLMotion *motion, F32 time); - BOOL deactivateMotionInstance(LLMotion *motion); - void deprecateMotionInstance(LLMotion* motion); - BOOL stopMotionInstance(LLMotion *motion, BOOL stop_imemdiate); - void removeMotionInstance(LLMotion* motion); + BOOL activateMotion(LLMotion *motion, F32 time); + BOOL deactivateMotion(LLMotion *motion, bool remove_weight); void updateRegularMotions(); void updateAdditiveMotions(); void resetJointSignatures(); void updateMotionsByType(LLMotion::LLMotionBlendType motion_type); - protected: + F32 mTimeFactor; static LLMotionRegistry sRegistry; LLPoseBlender mPoseBlender; @@ -208,13 +203,11 @@ // Once an animations is loaded, it will be initialized and put on the mLoadedMotions deque. // Any animation that is currently playing also sits in the mActiveMotions list. - typedef std::map motion_map_t; - motion_map_t mAllMotions; + std::map mAllMotions; motion_set_t mLoadingMotions; motion_list_t mLoadedMotions; motion_list_t mActiveMotions; - motion_set_t mDeprecatedMotions; LLFrameTimer mTimer; F32 mTime; --- linden-orig/indra/llcharacter/llpose.cpp 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llpose.cpp 2007-09-14 13:44:44.153375000 +0200 @@ -275,9 +275,9 @@ joint_state_index < JSB_NUM_JOINT_STATES && mJointStates[joint_state_index] != NULL; joint_state_index++) { + U32 current_usage = mJointStates[joint_state_index]->getUsage(); + F32 current_weight = mJointStates[joint_state_index]->getWeight(); LLJointState* jsp = mJointStates[joint_state_index]; - U32 current_usage = jsp->getUsage(); - F32 current_weight = jsp->getWeight(); if (current_weight == 0.f) { @@ -292,14 +292,17 @@ // add in pos for this jointstate modulated by weight added_pos += jsp->getPosition() * (new_weight_sum - sum_weights[POS_WEIGHT]); + //sum_weights[POS_WEIGHT] = new_weight_sum; } + // now do scale if(current_usage & LLJointState::SCALE) { F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // add in scale for this jointstate modulated by weight added_scale += jsp->getScale() * (new_weight_sum - sum_weights[SCALE_WEIGHT]); + //sum_weights[SCALE_WEIGHT] = new_weight_sum; } if (current_usage & LLJointState::ROT) @@ -308,6 +311,7 @@ // add in rotation for this jointstate modulated by weight added_rot = nlerp((new_weight_sum - sum_weights[ROT_WEIGHT]), added_rot, jsp->getRotation()) * added_rot; + //sum_weights[ROT_WEIGHT] = new_weight_sum; } } else @@ -322,13 +326,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[POS_WEIGHT]); // blend positions from both - blended_pos = lerp(jsp->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); + blended_pos = lerp(mJointStates[joint_state_index]->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); sum_weights[POS_WEIGHT] = new_weight_sum; } else { // copy position from current - blended_pos = jsp->getPosition(); + blended_pos = mJointStates[joint_state_index]->getPosition(); sum_weights[POS_WEIGHT] = current_weight; } } @@ -341,13 +345,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // blend scales from both - blended_scale = lerp(jsp->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); + blended_scale = lerp(mJointStates[joint_state_index]->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); sum_weights[SCALE_WEIGHT] = new_weight_sum; } else { // copy scale from current - blended_scale = jsp->getScale(); + blended_scale = mJointStates[joint_state_index]->getScale(); sum_weights[SCALE_WEIGHT] = current_weight; } } @@ -360,13 +364,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[ROT_WEIGHT]); // blend rotations from both - blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, jsp->getRotation(), blended_rot); + blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, mJointStates[joint_state_index]->getRotation(), blended_rot); sum_weights[ROT_WEIGHT] = new_weight_sum; } else { // copy rotation from current - blended_rot = jsp->getRotation(); + blended_rot = mJointStates[joint_state_index]->getRotation(); sum_weights[ROT_WEIGHT] = current_weight; } } --- linden-orig/indra/llcharacter/llpose.h 2007-09-13 15:35:18.000000000 +0200 +++ linden/indra/llcharacter/llpose.h 2007-09-14 13:44:44.856500000 +0200 @@ -81,7 +81,7 @@ S32 getNumJointStates() const; }; -const S32 JSB_NUM_JOINT_STATES = 6; +const S32 JSB_NUM_JOINT_STATES = 4; class LLJointStateBlender { From seg at haxxed.com Thu Oct 4 12:22:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Oct 4 12:22:36 2007 Subject: [sldev] Re: [VWR] Update channel (Re: VBO is broken) In-Reply-To: <4705364E.4080205@lindenlab.com> References: <1191518629.11151.208.camel@localhost> <4705364E.4080205@lindenlab.com> Message-ID: <1191525742.11151.214.camel@localhost> On Thu, 2007-10-04 at 11:51 -0700, Rob Lanphier wrote: > You should be able to create a separate update channel to get out of the > update, rather than faking version numbers. If you aren't able to, > that's a bug. Which is apparently documented here: http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements Which I just found via google, and doesn't seem to be linked anywhere, so I don't know how anyone's supposed to find it without a hint of what to google for. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/eab515ac/attachment.pgp From labrat.hb at gmail.com Thu Oct 4 12:25:15 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Oct 4 12:25:19 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: The interface already has a "think about what you are doing screen" The interface already has a "You must select to sell to anyone or a specific AV" The Land Search already has a throttle on the amount of data you can get in a period of time. (Do a land search and try rapidly changing pages back and forth) There is already a delay before the land set for sale is visible on the "For Sale" list (I've helped people verify their land settings before and it took a couple minutes for the plot to show up to verify on the land sale screen) Most everything you want is already there... people just do not use them. On 10/4/07, Matthew Dowd wrote: > > Well, my suggestion (and others have made it too) would be a five minute > moratorium after land is set for sale during which time *only* those present > on the sim when the land was set for sale can buy. > > It provides a breathing space for second thoughts, mistake correction, > correction of mispriced land due to software glitches/lag etc. before a bot > can run in and purchase the land. > > It supports the typical scenario of "buyer was present and no-one else was > so I thought it was safe to set to sale to anyone and that setting for sale > to a specific person was just an additional sequence of unnecessary > steps..." > > It *is* theoretically possible that someone could get around this by > running enough bots - either as many bots as mainland sims, or at least a > large enough number that there is a good statistical probability of being in > a sim when land is set for sale... > > Matthew > > > ------------------------------ > So what complaint do we really have? > > 1. The interface is so confusing it causes people to make mistakes in > selling land > 2. Land Bots can find and buy land faster then a human > > > > ------------------------------ > Play Movie Mash-up and win BIG prizes! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/52f86bdb/attachment.htm From 1337mail at gmail.com Thu Oct 4 12:34:06 2007 From: 1337mail at gmail.com (Michael Miller) Date: Thu Oct 4 12:34:09 2007 Subject: [sldev] Why won't isAvatar() work? In-Reply-To: <20071004130135.GC17807@bruno.sbruno> References: <2c99c46e0710031858h36993e30l8207d518caf58d1f@mail.gmail.com> <20071004122220.GA9396@bruno.sbruno> <2c99c46e0710040541s25356fceg8a4eedfc2a8f6b5b@mail.gmail.com> <4704E39C.2090102@blueflash.cc> <20071004130135.GC17807@bruno.sbruno> Message-ID: <2c99c46e0710041234n2d0bf098n67164ca0b6edaaef@mail.gmail.com> Just so everyone knows, the problem was indeed that the code wasn't inside the loop. Sorry for the trouble, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/4935807f/attachment.htm From seg at haxxed.com Thu Oct 4 12:47:14 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Oct 4 12:47:21 2007 Subject: [sldev] Re: [VWR] Update channel (Re: VBO is broken) In-Reply-To: <1191525742.11151.214.camel@localhost> References: <1191518629.11151.208.camel@localhost> <4705364E.4080205@lindenlab.com> <1191525742.11151.214.camel@localhost> Message-ID: <1191527234.11151.220.camel@localhost> On Thu, 2007-10-04 at 14:22 -0500, Callum Lerwick wrote: > On Thu, 2007-10-04 at 11:51 -0700, Rob Lanphier wrote: > > You should be able to create a separate update channel to get out of the > > update, rather than faking version numbers. If you aren't able to, > > that's a bug. > > Which is apparently documented here: > > http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements llversionviewer.h does not exist in 1.18.0.6 and there's no LL_CHANNEL anywhere in the source. This seems to do it though: --- linden.orig/indra/newview/viewer.cpp 2007-10-04 10:09:56.000000000 -0500 +++ linden.patched/indra/newview/viewer.cpp 2007-10-04 14:18:05.000000000 -0500 @@ -539,7 +539,7 @@ BOOL gAcceptTOS = FALSE; BOOL gAcceptCriticalMessage = FALSE; // this is the channel the viewer uses to check for updates/login -std::string gChannelName = "Second Life Release"; +std::string gChannelName = "Second Life Open Source [Fedora]"; LLUUID gInventoryLibraryOwner; LLUUID gInventoryLibraryRoot; Huzzah! Is there any security holes in 1.18.0.6 I should know about? AFAIK Linux is safe from the recently discovered issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/9f0f8cae/attachment.pgp From adaradius at gmail.com Thu Oct 4 12:58:50 2007 From: adaradius at gmail.com (Ada Radius) Date: Thu Oct 4 12:58:54 2007 Subject: [sldev] CAPTCHA to validate land sales. Message-ID: In a RL economy, the land bots could be considered a benefit - increasing liquidity in the land market. I don't use them, but if I want to get rid of land in a hurry, I'm glad they're there. Since LL controls both currency and land supply, and they're a for-profit entity (and no better or worse at economics than governments), liquidity in both land and L$ can be puzzling. I do think that there should be more security in the way that money is handled in-game (getting rid of L$ would be a good thing). Along with more straightforward ways of describing "land" and "land sales" - we're leasing CPU usage, after all, and paying for sets of locations. It's not RL land, and shouldn't be handled as though it were. CAPTCHA is one way to go for that security - my RL bank has other ways - those are the folks we should be looking at for precedent and experience on money transactions, I think. Ada Radius Message: 1 > Date: Thu, 04 Oct 2007 10:58:49 -0600 > From: Taran Rampersad > Subject: Re: [sldev] CAPTCHA to validate land sales. > To: Matthew Dowd > Cc: sldev@lists.secondlife.com > Message-ID: <47051BC9.5050706@knowprose.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Matthew Dowd wrote: > > > > >> Whatever you may personally feel about landbots - their use is not > > >> illegal in SL nor against the TOS. > > >Lets quit mixing 'legality' and ToS. ToS is a contract, subject to > > >contract law. It is not *THE* Law. > > > > I never said it was *THE* law - the word "illegal" can be quite > > legitimately used as a synonym for banned, prohibited etc. without it > > necessarily being anything to do the the Law of the land. > No. The word 'illegal' has very different connotations. It quite > literally means, "against the law". > > Against ToS? Against Community Standards? Legitimate. Saying something > is illegal is a very different thing. The ToS and Community Standards > have been in court at least once, and were modified due partly to the > legality of the ToS itself. > > I fully expect 'fictional currency' to be the next sticking point. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/fda60ca0/attachment.htm From matthew.dowd at hotmail.co.uk Thu Oct 4 13:02:38 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Oct 4 13:02:40 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: > The interface already has a "think about what you are doing screen" Which doesn't work - because people don't read popup boxes. They are more likely to click OK - THEN go "whoops didn't mean to do that, how do I undo". Basically, having the ability to undo something (at least for a short while) is a much more human friendly UI than any amount of "do you wish to do this" popups, which are just a bad (and lazy) UI design. > The interface already has a "You must select to sell to anyone or a specific AV" Which the new user, on an empty sim transfering ownership from a group to themselves, or selling to a person present on an empty sim, thinks (at least the first time) is an unnecessary set of extra steps safe to shortcut since the sim is "empty" > The Land Search already has a throttle on the amount of data you can get in a period of time. (Do a land search and try rapidly changing pages back and forth) Which affects humans far more than bots - a bot is only interested in the cheapest prices plots so doesn't need to step through more than the first few pages. After it has some choice spots it will tp and try to grab them, by which time it is safe to do another search - and in any case run enough simultaneous bots and you can get around this. On the other hand, try searching for the cheapest peice of estate land not priced at L$1 (something a bot would never do) - the only way is to scroll through page after page of listings and the throttle makes it extremely difficult > There is already a delay before the land set for sale is visible on the "For Sale" list (I've helped people verify their land settings before and it took a couple minutes for the plot to show up to verify on the land sale screen) On the other hand, I've had land sale appear almost instantly. If there is any delay, I suspect that it is only caused by the backend database running slowly rather than an intended delay. If there really is a delay could someone update (and indeed close) this jira entry - http://jira.secondlife.com/browse/SVC-376 ? > Most everything you want is already there... people just do not use them. And shouldn't the fact that people don't use them indicate to you that perhaps there is something wrong with the implementation? There comes a point where you have to stop blaming the user and perhaps consider the UI is to blame! Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071004/f16c4767/attachment-0001.htm From cnd at knowprose.com Thu Oct 4 19:48:57 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Thu Oct 4 17:52:44 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: <4705A619.8040200@knowprose.com> Harold Brown wrote: > The current Land Sale interface is the way it currently is... because > that's what people wanted. They told LL's "You do this and it will > solve all our land sale problems" They did it... and people are still > bitching about it.. but not because of land swoopers (the generation > before bots) but because of bots. > > The complaints are generated mostly by other "Land Barons" who don't > have bots and can't compete at the more lucrative low price land flip. (1) If people are happy, we won't be having this conversation. We are having this conversation. (2) The complaints are generated mostly by people who lost large sums of money and who are NOT land barons. Stop defending the indefensible. -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From jhurliman at wsu.edu Thu Oct 4 18:57:35 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Oct 4 18:57:26 2007 Subject: [sldev] [VIEWER] Message-ID: <47059A0F.8000103@wsu.edu> I just found the force_export_copy function in the SL viewer code, is the "" format a real format that could/should be adopted, or just an arbitrary format for testing purposes? Personally I would lean towards something built on top of LLSD, but I don't know if this is already an established thing I've been unaware of. John Hurliman From ts_ryuzo at hotmail.com Thu Oct 4 19:13:45 2007 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Thu Oct 4 19:13:48 2007 Subject: [sldev] Culling and Occlusion Message-ID: Hi, I am currently researching on the rendering part of the second life. I would like to know how Second Life detect culling, occlusion and determine which surface to render first. I would also like to know where is the location of these codes. Thanks and regards, Zeph From andrew at lindenlab.com Thu Oct 4 21:40:54 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Thu Oct 4 21:41:25 2007 Subject: [sldev] [VIEWER] In-Reply-To: <47059A0F.8000103@wsu.edu> References: <47059A0F.8000103@wsu.edu> Message-ID: <4705C056.4050206@lindenlab.com> John Hurliman wrote: > I just found the force_export_copy function in the SL viewer code, is > the "" format a real format that could/should be > adopted, or just an arbitrary format for testing purposes? Personally I > would lean towards something built on top of LLSD, but I don't know if > this is already an established thing I've been unaware of. From the look of things that code appears to be cruft. It dates from 2005 or earlier and to my knowledge we have never used it for any real puprpose internally. I think it was an experiment that was never cleaned up. 'svn annnotate' shows that it hasn't been maintained since it was first added. - Andrew From seg at haxxed.com Thu Oct 4 21:44:04 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Oct 4 21:44:19 2007 Subject: [sldev] [VIEWER] In-Reply-To: <47059A0F.8000103@wsu.edu> References: <47059A0F.8000103@wsu.edu> Message-ID: <1191559444.26663.11.camel@localhost> On Thu, 2007-10-04 at 18:57 -0700, John Hurliman wrote: > I just found the force_export_copy function in the SL viewer code, is > the "" format a real format that could/should be > adopted, or just an arbitrary format for testing purposes? Personally I > would lean towards something built on top of LLSD, but I don't know if > this is already an established thing I've been unaware of. Seems to me the "standards body SL" is going to need to nail this stuff down eventually, and as its a relatively straightforward thing to do it might as well be started now. Someone needs to come up with a formal XML DTD for serialization of Second Life objects. I don't know crap about writing DTDs so don't look at me. :) I would suggest looking at SVG as a guide. Its designed to be reasonably compact, despite being XML. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/7956e146/attachment.pgp From gigstaggart at gmail.com Thu Oct 4 22:42:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Oct 4 22:42:56 2007 Subject: [sldev] Various questions on the viewer. Message-ID: <4705CEE1.1050802@gmail.com> 1. Why does zoom transform into FOV zoom when you are closer than the (fairly large) MIN_ZOOM threshold? That makes working on small prims a real bitch. Can we lower MIN_ZOOM safely? 2. Why are all the Observer patterns used in the client so simplistic? Is this a design decision? It seems they all only get a bitmask parameter on the changed() event. Why can't we pass them more complex data structures so that things like the entire UI could be turned into Observer patterns? 3. What are the proper ways to use the XUI? Why do some floaters use hidden "text" types for things that are really just misc strings? Why not use the much easier getUIString? I see a whole lot of inconsistancy in the way the XUI is used. What is the right way? Where are we going with this? From robla at lindenlab.com Thu Oct 4 23:04:43 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Oct 4 23:05:06 2007 Subject: [sldev] Re: [VWR] Update channel (Re: VBO is broken) In-Reply-To: <1191525742.11151.214.camel@localhost> References: <1191518629.11151.208.camel@localhost> <4705364E.4080205@lindenlab.com> <1191525742.11151.214.camel@localhost> Message-ID: <4705D3FB.2010406@lindenlab.com> On 10/4/07 12:22 PM, Callum Lerwick wrote: > On Thu, 2007-10-04 at 11:51 -0700, Rob Lanphier wrote: > >> You should be able to create a separate update channel to get out of the >> update, rather than faking version numbers. If you aren't able to, >> that's a bug. >> > > Which is apparently documented here: > > http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements > > Which I just found via google, and doesn't seem to be linked anywhere, > so I don't know how anyone's supposed to find it without a hint of what > to google for. :) > It was added fairly recently. I made some edits to make this a little more discoverable, though: http://wiki.secondlife.com/wiki/Protocol#Channels_and_Versions Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071004/989a8123/signature.pgp From hud at zurich.ibm.com Thu Oct 4 22:25:13 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:07:15 2007 Subject: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.) In-Reply-To: <200710031815.12231.dale@daleglass.net> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> Message-ID: <4705CAB9.4080401@zurich.ibm.com> how about introducing a "bots.txt" file? currently we have no way of telling a bot whether he is allow on a property (or what he is allowed to do). this is not going to deter "ill-behaving" bots from just ignoring whatever "bots.txt" tells them to do (or not do) --- but at least a parcel owner can cleary express her wishes & rules. this could go into the parcel properties stuff and consist of a couple of rules: * bots (not) allowed on this parcel o bots (not) allowed above XXXm o bots (not) allowed below XXXm * bots (not) allowed to collect information o items for sale o texture information o prim information o avatars present well-behaving bots (e.g., bots owned by well-known companies) would honor those settings. cheers, dirk aka dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071005/de902265/attachment-0001.htm From hud at zurich.ibm.com Thu Oct 4 22:13:58 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:07:17 2007 Subject: [sldev] [PROTOCOL] Protocol Documentation In-Reply-To: <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> References: <4702C702.1030100@wsu.edu> <4703132B.3030006@gmail.com> <102ED0B6-9256-41C6-9405-08377E8C526B@gmail.com> <47039BD1.2050805@zurich.ibm.com> <66C93611-82D7-4E86-9A3E-FCA16D5C020D@gmail.com> Message-ID: <4705C816.2030705@zurich.ibm.com> Argent Stonecutter wrote: > On 03-Oct-2007, at 08:40, dirk husemann wrote: >> hmm...i think by opening up the discussion about the future architecture >> and by starting an architecture working group, LL is showing a >> substantial amount of openess --- and i trust them that they are dead >> serious about this. so, in the long run we will have public specs that >> were developed in the open. > > My point is that these comments (below), if they've been accurately > reported by John, indicate that LL doesn't have any intention of > conforming to any public specs or notifying anyone of changes that > effect the public specs. Now, I'm not saying that they have to... > there is nothing that says an Open Source project actually has to > produce an Open Systems product. I'm just pointing out that these two > kinds of openness aren't the same, and it's important to be aware of > the distinction between them. quite right. > > I'm not knocking Linden Labs here. Open Sourcing the client was an > amazingly cool thing, it was really courageous of them to do that, and > I'm not criticizing them where they haven't gone further by any means. > I'm just trying to promote another kind of openness... one that's as > old a part of the software industry as Open Source and just as > important... and arguing that it needs some kind of commitment from LL > that they don't seem to have made: > > * LL: we can't log every change, it would be cluttered and irrelevant > * LL: the source code is very clear on how all of this works > * LL: it [the code] is very clear documentation > * LL: so this whole discussion about documenting the capability API is > just so people can steal code? > > Again, I'm not saying they have to make that commitment, I'm just > asking them to. i'm assuming that LL is not always speaking with one voice (i'm not always speaking with one voice :-( --- you are quite right that we need specs (if along with open source code, the better). let's make sure we get those right with the new architecture stuff. for the time being i'm giving them the benefit of the doubt and take zero and rob by their word(s). cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Thu Oct 4 22:06:42 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:07:20 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <20071003143915.GC29227@bruno.sbruno> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <3b19a500710030450r3ce38e27k12b21223523b15df@mail.gmail.com> <001601c805b7$350986f0$33a30650@INFOTECH> <20071003123843.GC26201@bruno.sbruno> <4703948D.6090608@blueflash.cc> <20071003133656.GD26201@bruno.sbruno> <62444EB1-7ED5-4094-8358-583E4C38A44C@gmail.com> <20071003143915.GC29227@bruno.sbruno> Message-ID: <4705C662.1080406@zurich.ibm.com> Dale Glass wrote: > On Wed, Oct 03, 2007 at 09:20:24AM -0500, Argent Stonecutter wrote: > >> On 03-Oct-2007, at 08:36, Dale Glass wrote: >> >>> Now that it's pretty much impossible to set land for sale >>> accidentally, >>> why do we need to stop bots from buying land? >>> >> Because bots distort the land market, were largely responsible for >> starting the huge bubble in land prices last year, and put people who >> are not running bots (that is, almost everyone) at a huge >> disadvantage. Preventing bots from buying land would level the >> playing field. >> > > You will still have land bots. > > It's just that instead of an autonomous one, there will be a human > filling out the captchas. Many people with nothing better to do could be > available to fill them 12 hours a day, and the potential payout is more > than worth ocasionally filling out a field. > besides there are algorithms to parse captchas and it turns out it's rather tough to create a good captcha. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071005/780aae3a/attachment.htm From hud at zurich.ibm.com Thu Oct 4 23:36:17 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:36:21 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031928.43221.dale@daleglass.net> <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> Message-ID: <4705DB61.2060402@zurich.ibm.com> Argent Stonecutter wrote: > On 03-Oct-2007, at 13:32, Dale Glass wrote: >> On Wednesday 03 October 2007 19:59:52 Argent Stonecutter wrote: >>> You're still not looking at what I'm talking about. >>> >>> Right now, the bot operates with no human in the loop. So it's not >>> cost-effective to do anything that might require a human. > >> Not in the US maybe. There are countries with internet access where $100 >> can be a monthly wage. > > The absolute cost of doing this doesn't matter. It's the relative cost > of doing it with a bot (using, say, a cheap virtual host somewhere) > versus doing it with a human (including the cost of managing the > human). If the human costs $400 a month (4 people in shifts) then > that's at least 10 times the cost of using bots. > > Look, if it was cost effective then people would be doing it, and > out-competing the people running dumb bots. hmm...considering that we don't have the captcha stuff yet, it's a bit difficult to claim that people are not doing it, thus, it's not cost effective :-) the relative costs don't matter a peep: if it can be leveraged it will --- just take a look at the migrating production in far east. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Thu Oct 4 23:44:28 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:45:06 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47041A76.4000106@knowprose.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> Message-ID: <4705DD4C.9080609@zurich.ibm.com> Taran Rampersad wrote: > Zha Ewry wrote: >> This was the point I was on at office hours yesterday. For better, or >> worse, GPL is an impediment. It is fine for people to say "GPL >> doesn't stop you from looking at the code." On a personal level, I >> tend to understand, and maybe even agree with that premise. On a >> pragmatic level, and having dealt with IP lawyers, on a regular basis >> for a long time, the actual. real world, non idealistic effect of the >> GPL has been exactly as Sean describes. Lawyers raise red flags. >> People ask the question "Where is the line between what is safe to >> look at and what is not safe to look at." Pretty soon, the answer is >> "Just don't look." I won't argue about whether that position is >> legally necessary, or sane, or useful. But, I will observe, it is the >> position a *LOT* of people take. > Completely ducking the implicit Holy War, I will say this: Looking at > GPL'd code doesn't really mean anything *unless* you copy the code or > you try to patent a process which the code works with. The GPL is not > an impediment in any other way; Copyright is fuzzy in areas of code > but it is safe to say that there is more than one way to skin a cat. > It didn't work very well for SCO, which seems to be the boilerplate of > this discussion. right. GPL is about what you can do with the code (copy, modify, redistribute, etc). you can't really license concepts and methods --- as SCO has found out. there are certain companies where the legal people are exhibiting a certain hysteria about the "viral" nature of the GPL --- and seemingly forgetting that it's not a kind of human mad-cow-disease that can infect you by just looking at GPL code... i've had arguments with colleagues about participating in this mailing list: they babbled something about getting contaminated by looking at publicly available stuff (luckily our IP lawyer on campus cleared that brain fudge up). > > Seeing how a GPL piece of code works and replicating it on one's own > is not likely to be a copyright violation, or abuse of the GPL itself. > The trouble is with demonstrating to LAWYERS and COURTS that you > didn't steal the code, and really every possible software license has > the same problem. It isn't about the software license in this regard, > it *is* about how IP is handled. it relieves the burden of proof if you can copy the code and use as you want (which BSD-style license kind of allow). -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Thu Oct 4 23:52:44 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 4 23:52:49 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> Message-ID: <4705DF3C.3080009@zurich.ibm.com> Argent Stonecutter wrote: > On 03-Oct-2007, at 17:40, Taran Rampersad wrote: >> Seeing how a GPL piece of code works and replicating it on one's own >> is not likely to be a copyright violation, or abuse of the GPL >> itself. The trouble is with demonstrating to LAWYERS and COURTS that >> you didn't steal the code, and really every possible software license >> has the same problem. > > It's only a problem if there is the appearance that you violated the > license when you allegedly copied it. > [...] > > So if the code was released under one of these licenses it would not > create a situation where someone using the code as documentation would > automatically be at risk of being placed in a position where they had > to defend their work. The original voice API license, Microsoft's > license on some of their documentation, all have similar issues. That > is, there are licenses that create a problem for open systems use, and > ones that don't. The GPL happens to be one that does. i'd phrase that as "there are licenses where you might have to show that you didn't copy and ones where you don't" --- except, as we have seen with SCO you have ALWAYS the possibility of a greedy fool trying to attack you anyhow (e.g., claiming that the code you used was stolen from him, don't mind the BSD/GPL/whatever license). so, in essence: there's always a risk --- which kind of levels the playing field a bit... -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From ingmar at RiversRunRed.com Fri Oct 5 01:14:20 2007 From: ingmar at RiversRunRed.com (Ingmar Hupp) Date: Fri Oct 5 01:14:33 2007 Subject: [sldev] [VWR] LSL Compiler Limitations? In-Reply-To: <46FC3D78.8060602@blueflash.cc> References: <46FB9D55.4030706@blueflash.cc> <20070927121201.GB7052@bruno.sbruno> <46FB9F2B.9030405@blueflash.cc> <20070927123124.GC7052@bruno.sbruno> <46FC3D78.8060602@blueflash.cc> Message-ID: <2FFCD688-3C4A-4CC1-ADAC-DFB8D74DA4A9@RiversRunRed.com> See https://jira.secondlife.com/browse/VWR-811 The bug seems to occur only on the Windows platform and not on the Mac platform (both official, 1.18.0 when I tested), which also indicates differences in the build tools used (lexx/yacc) might be the cause. Ingmar On 28 Sep 2007, at 00:32, Nicholaz Beresford wrote: > > Dale Glass wrote: >> I use my own viewer 99% of the time, but I haven't changed any of >> that >> source. >> Also the fix seems to have went in months before I started working >> on my >> own viewer. >> This is probably a scripter who still remembers the problem and just >> noticed they wrote an if with 20 else clauses and it worked. > > Ok, have three demo scripts now (two essentially the same). > if else if ... breaks on the 24th in the official viewer but > run on mine. > > Power of two sign (m?) in a string breaks official but not > mine. > > I'm not sure if I'm going to dig deeper, just sharing the info > for the moment, in case someone doing more LSL wants to > investigate. > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Ingmar "Ezhar Fairlight" Hupp | Head of Technology | Rivers Run Red http://riversrunred.com From robin.cornelius at gmail.com Fri Oct 5 03:32:56 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Oct 5 03:32:58 2007 Subject: [sldev] Win32 debug problem Message-ID: Hi Everyone, What am i doing wrong, trying to run a debug on 1.18.3.5 using visual studio .net 2003. Everything builds ok, but running results in an exception in the embedded web browser. (llstartup.cpp) // initialize Mozilla - pass in executable dir, location of extra dirs (chrome/, greprefs/, plugins/ etc.) and path to profile dir) LLMozLib::getInstance()->init( gDirUtilp->getExecutableDir(), componentDir, gDirUtilp->getExpandedFilename( LL_PATH_MOZILLA_PROFILE, "" ) ); is the kiss of death and the stack trace is not helpful :- ntdll.dll!7c901230() xul.dll!100703ce() xul.dll!1007030e() ntdll.dll!7c96e0d4() ntdll.dll!7c926abe() ntdll.dll!7c94a5d0() ntdll.dll!7c96e0d4() ntdll.dll!7c94a5d0() ntdll.dll!7c926abe() As its a thread in the xul.dll that is crashing. My guess is that a bad parameter has been passed somewhere during the earlier initalisation calls. Anyone know if this is the case and which one it might be? Thanks Robin From nicholaz at blueflash.cc Fri Oct 5 04:27:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Oct 5 04:27:58 2007 Subject: [sldev] Win32 debug problem In-Reply-To: References: <4706185B.7070002@blueflash.cc> Message-ID: <47061FB9.7090900@blueflash.cc> Robin Cornelius wrote: > Not sure if you have any ideas on this one, Callum thought it may have > been to do with VBO on 64bit, haven't had chance to run a memory > profile with VBO turned off as well. If you want to look at VBO, I'd say do the leak debugging with my source. It has LLMOZLIB disabled in the debug configuation by default and should run with leak debugging right away. It will (in the current versions) even give you a per minute snapshot of memory allocation in the leaks.log file (top allocators sorted by file and location) together with a memory heap summmary (you can tweak that in the nbleakdebug.cpp). It's the best starting point you can get without re-cheking and re-fixing stuff which I already dealt with. From there, there are two things that can happen. 1) either you see the memory growth and leaking on the heap (in the heap snapshots and leaks at the end of the program). There you'll probably be able to identify the point of the source. 2) you don't see them, which means it's happening in the gl-memory (outside the program heap ... for example texture buffering (memory shown in ctrl+alt+3 .. or sTotalTextureMemory in llviewerimage.cpp) is also not showing on the heap), which will most likely be a driver or opengl issue. The latter is more likely, I've looked at the leak dumps just recently, and in my viewer there is only marginal stuff being left over (as far as I can tell mostly from fmod). Nick From nicholaz at blueflash.cc Fri Oct 5 04:41:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Oct 5 04:41:55 2007 Subject: [sldev] [VWR] VBO is broken In-Reply-To: <1191518629.11151.208.camel@localhost> References: <1191518629.11151.208.camel@localhost> Message-ID: <470622FD.7050205@blueflash.cc> Btw, I had a user contact me yesterday who said that lowering the process priority on Windows to "below normal" stopped his memory growth. Maybe there are threading issues with some drivers. Nick From robin.cornelius at gmail.com Fri Oct 5 05:32:42 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Oct 5 05:32:44 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <47013253.5000301@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> Message-ID: On 10/1/07, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > > Which is why LL should focus on working with Linux distributions to get > > Second Life into the distributions themselves, rather than distributing > > binary blobs. > > We're happy to see people packaging the viewer for different Linux > distributions (for example, I'm watching the Fedora packaging tasks), > and willing to help out where we can. I've done quite a bit of work to > make it easier to build a standalone viewer, for example. > > If there are specific things you'd like to see done, file JIRA tasks, > and we'll plug away at them as the opportunity presents itself. If you > want to file an umbrella task and connect the subtasks to it so that > it's easier to see which ones are intended to ease distro integration, > all the better. Coming back to this thread, ATM the viewer is an enormous tar ball and I know there are a few of us now doing our own builds with various different patchsets for different arch's. Can we maybe think about splitting up the viewer (distribution) into smaller packages. Surely the various artwork and supplied textures remain pretty constant and it seems wasteful redistributing the same data over and over again. If we can come up with a basic structure for grouping files then this will make packaging the viewer for rpm/deb or even different tar.bz2s easier and certainly makes distribution easier. Possibly even on windows or mac distribute smaller files or have an automated update/installer that can just pull the required package(s). One of the main questions is anybody have a feel for how static various files are. I am sure the various translations and languages are being adjusted fairly frequently with addition of new features and corrections but what about all the artwork, that must almost be static across many versions. As a bare minimum the viewer splits up into a common arch independent package and a secondlife-official-1.18.4-amd64 etc package, this would also allow easy deployment of multiple viewers and 3rd party viewers if we all use the same basic system in packages. (Thanks for the discussion Julie). I am wondering if infact it should split even further with the language files in one package, various artwork in others, main binary in another etc. I am not sure at this point how this effects anything LL are doing to the code base. Its more a policy decision for packagers distributing a viewer. For the moment any body have any objections to creating a wiki page to outline a packaging policy so at least we can all work from the same sheet if we are deploying our own builds of the viewers. Where it does effect LL is i suppose that we want minimum changes from upstream code to the version packaged, so we really don't want to have to move files around everywhere and greatly change the code base. So to achieve this would require a better build and moving to a more standard makefile so we can do various build steps with just make, eg make all, make viewer-tarball or what ever? This is quite a big step so anybody have any thoughts on that. Regards Robin From q at lindenlab.com Fri Oct 5 05:32:55 2007 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri Oct 5 05:34:37 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <4705CEE1.1050802@gmail.com> References: <4705CEE1.1050802@gmail.com> Message-ID: <47062EF7.2000507@lindenlab.com> Jason: I don't (yet) know the answers to your questions, but I can tell you that starting next week, I'm going to be working on a project (along with a couple of other people) called "User Interface Cleanup" that includes, among other things, a reworking of the way we handle callbacks and a reorganization of XUI. We expect to spend most of the next quarter on it. SL grew a bit more organically than any of us would like -- but now we're trying to apply some good engineering principles. So hang in there and we'll keep you posted. Q Jason Giglio wrote: > 2. Why are all the Observer patterns used in the client so simplistic? > Is this a design decision? It seems they all only get a bitmask > parameter on the changed() event. Why can't we pass them more complex > data structures so that things like the entire UI could be turned into > Observer patterns? > > 3. What are the proper ways to use the XUI? Why do some floaters use > hidden "text" types for things that are really just misc strings? Why > not use the much easier getUIString? > > I see a whole lot of inconsistancy in the way the XUI is used. What > is the right way? Where are we going with this? From secret.argent at gmail.com Fri Oct 5 06:42:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 5 06:42:06 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: <4705DB61.2060402@zurich.ibm.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <200710031928.43221.dale@daleglass.net> <258BD93D-06BF-4646-8750-BC759D78C676@gmail.com> <200710032032.10720.dale@daleglass.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <4705DB61.2060402@zurich.ibm.com> Message-ID: On 05-Oct-2007, at 01:36, dirk husemann wrote: > Argent Stonecutter wrote: >> On 03-Oct-2007, at 13:32, Dale Glass wrote: >> Look, if it was cost effective then people would be doing it, and >> out-competing the people running dumb bots. > hmm...considering that we don't have the captcha stuff yet, it's a bit > difficult to claim that people are not doing it, thus, it's not cost > effective :-) You're not talking about what I'm talking about. Right now it's apparently cost effective to NOT look at plots but to buy them blind instead, because the cost of having a few junk plots you have to abandon because the don't sell is less than the cost of taking the time to actually look to see if you really WANT the funny shaped plot next to the badly placed ad farm. If you've gotta bring in a human to fill in the captcha anyway, then having that human go "don't be daft, nobody's going to buy that for what we'd need to sell it for" and cancel out becomes cost-effective. From secret.argent at gmail.com Fri Oct 5 07:16:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 5 07:16:51 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <4705DF3C.3080009@zurich.ibm.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <4705DF3C.3080009@zurich.ibm.com> Message-ID: On 05-Oct-2007, at 01:52, dirk husemann wrote: > as we have seen > with SCO you have ALWAYS the possibility of a greedy fool trying to > attack you anyhow (e.g., claiming that the code you used was stolen > from > him, don't mind the BSD/GPL/whatever license). Um, the SCO case was coming from exactly the opposite direction. They were claiming that certain GPLed code was derived from their code, because it had been part of a system derived from their code. If they actually *had* the licenses they claimed they had, *and* their license terms meant what they claimed they meant, then they might have had had a case. Their problems included: * They claimed that writing your code to function as a module in their code made your code a derived work of their code, when their license didn't actually say that. * They ignored the USL-CSRG case, which eliminated the 'viral UNIX license' theory and the 'copyright on the structure of the code' theory: it was settled by removing specific files from BSD, which would not have made any difference if the license worked the way they claimed it did. * They claimed that code that had been explicitly released under a different license by previous copyright owners was still covered by the license they were trying to use. * They claimed that code that had been released without copyright prior to the US adopting the Berne Convention was still covered by copyright. * They didn't actually own all the rights to the code that they claimed they did. From secret.argent at gmail.com Fri Oct 5 07:29:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 5 07:29:31 2007 Subject: [sldev] [VWR] LSL Compiler Limitations? In-Reply-To: <2FFCD688-3C4A-4CC1-ADAC-DFB8D74DA4A9@RiversRunRed.com> References: <46FB9D55.4030706@blueflash.cc> <20070927121201.GB7052@bruno.sbruno> <46FB9F2B.9030405@blueflash.cc> <20070927123124.GC7052@bruno.sbruno> <46FC3D78.8060602@blueflash.cc> <2FFCD688-3C4A-4CC1-ADAC-DFB8D74DA4A9@RiversRunRed.com> Message-ID: <550F2765-EBDA-4068-AA38-998C3DED4C96@gmail.com> On 05-Oct-2007, at 03:14, Ingmar Hupp wrote: > See https://jira.secondlife.com/browse/VWR-811 > > The bug seems to occur only on the Windows platform and not on the > Mac platform (both official, 1.18.0 when I tested), which also > indicates differences in the build tools used (lexx/yacc) might be > the cause. Try #defining YYMAXDEPTH to a larger number (try 2000, as Strife suggested) in the header part of indra.y. Eg: #ifdef LL_WINDOWS + #define YYMAXDEPTH 2000 // avoid syntax error on deeply nested LSL #pragma warning( disable : 4065 ) // warning: switch statement con tains 'default' but no 'case' labels #endif From nicholaz at blueflash.cc Fri Oct 5 08:02:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Oct 5 08:02:10 2007 Subject: [sldev] [VWR] LSL Compiler Limitations? In-Reply-To: <550F2765-EBDA-4068-AA38-998C3DED4C96@gmail.com> References: <46FB9D55.4030706@blueflash.cc> <20070927121201.GB7052@bruno.sbruno> <46FB9F2B.9030405@blueflash.cc> <20070927123124.GC7052@bruno.sbruno> <46FC3D78.8060602@blueflash.cc> <2FFCD688-3C4A-4CC1-ADAC-DFB8D74DA4A9@RiversRunRed.com> <550F2765-EBDA-4068-AA38-998C3DED4C96@gmail.com> Message-ID: <470651EA.6050001@blueflash.cc> Well, AFAIK the bug only appears in the official Linden versions. My compiles here don't the limitations compiling on Windows and without code changes. So I guess it's something the Lindens need to at in their environment. Nick Argent Stonecutter wrote: > On 05-Oct-2007, at 03:14, Ingmar Hupp wrote: >> See https://jira.secondlife.com/browse/VWR-811 >> >> The bug seems to occur only on the Windows platform and not on the Mac >> platform (both official, 1.18.0 when I tested), which also indicates >> differences in the build tools used (lexx/yacc) might be the cause. > > Try #defining YYMAXDEPTH to a larger number (try 2000, as Strife > suggested) in the header part of indra.y. > > Eg: > > #ifdef LL_WINDOWS > + #define YYMAXDEPTH 2000 // avoid syntax error on > deeply nested LSL > #pragma warning( disable : 4065 ) // warning: switch > statement con > tains 'default' but no 'case' labels > #endif > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From hud at zurich.ibm.com Fri Oct 5 08:44:20 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Oct 5 08:45:15 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <4705DF3C.3080009@zurich.ibm.com> Message-ID: <47065BD4.2030605@zurich.ibm.com> Argent Stonecutter wrote: > On 05-Oct-2007, at 01:52, dirk husemann wrote: >> as we have seen >> with SCO you have ALWAYS the possibility of a greedy fool trying to >> attack you anyhow (e.g., claiming that the code you used was stolen from >> him, don't mind the BSD/GPL/whatever license). > > Um, the SCO case was coming from exactly the opposite direction. They > were claiming that certain GPLed code was derived from their code, > because it had been part of a system derived from their code. If they > actually *had* the licenses they claimed they had, *and* their license > terms meant what they claimed they meant, then they might have had had > a case. Their problems included: originally they claimed that code had been copied pretty much literally from their code basis --- thus, claiming that code that was used in linux was copied from them. not sure how that is the opposite direction. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From phoenix at secondlife.com Fri Oct 5 09:06:29 2007 From: phoenix at secondlife.com (Phoenix) Date: Fri Oct 5 09:06:50 2007 Subject: [sldev] [VWR] LSL Compiler Limitations? In-Reply-To: <470651EA.6050001@blueflash.cc> References: <46FB9D55.4030706@blueflash.cc> <20070927121201.GB7052@bruno.sbruno> <46FB9F2B.9030405@blueflash.cc> <20070927123124.GC7052@bruno.sbruno> <46FC3D78.8060602@blueflash.cc> <2FFCD688-3C4A-4CC1-ADAC-DFB8D74DA4A9@RiversRunRed.com> <550F2765-EBDA-4068-AA38-998C3DED4C96@gmail.com> <470651EA.6050001@blueflash.cc> Message-ID: <419F4FB7-32C5-49F7-8EA1-028EAC2AF2D4@secondlife.com> The build team here continues to use lex and yacc and the process to strip out things we cannot redistribute swaps around a few uuids and filenames to switch it over to flex and bison. SL-45464: Fix lex-compiler issue causing a hard limit in the number of script parameters is marked as resolved, but obviously something is wrong. I will investigate. On 2007-10-05, at 08:02, Nicholaz Beresford wrote: > Well, AFAIK the bug only appears in the official Linden > versions. My compiles here don't the limitations compiling > on Windows and without code changes. So I guess it's > something the Lindens need to at in their environment. > > > Nick > > > > Argent Stonecutter wrote: >> On 05-Oct-2007, at 03:14, Ingmar Hupp wrote: >>> See https://jira.secondlife.com/browse/VWR-811 >>> >>> The bug seems to occur only on the Windows platform and not on >>> the Mac platform (both official, 1.18.0 when I tested), which >>> also indicates differences in the build tools used (lexx/yacc) >>> might be the cause. >> Try #defining YYMAXDEPTH to a larger number (try 2000, as Strife >> suggested) in the header part of indra.y. >> Eg: >> #ifdef LL_WINDOWS >> + #define YYMAXDEPTH 2000 // avoid syntax >> error on deeply nested LSL >> #pragma warning( disable : 4065 ) // warning: switch >> statement con >> tains 'default' but no 'case' labels >> #endif >> _______________________________________________ >> 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: 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/20071005/09f2e87a/PGP.pgp From secret.argent at gmail.com Fri Oct 5 09:36:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 5 09:36:03 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47065BD4.2030605@zurich.ibm.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <4705DF3C.3080009@zurich.ibm.com> <47065BD4.2030605@zurich.ibm.com> Message-ID: <1C24A18D-B6CF-401B-8099-E424BAD8A0DC@gmail.com> On 05-Oct-2007, at 10:44, dirk husemann wrote: > Argent Stonecutter wrote: >> On 05-Oct-2007, at 01:52, dirk husemann wrote: >>> as we have seen >>> with SCO you have ALWAYS the possibility of a greedy fool trying to >>> attack you anyhow (e.g., claiming that the code you used was >>> stolen from >>> him, don't mind the BSD/GPL/whatever license). >> Um, the SCO case was coming from exactly the opposite direction. They >> were claiming that certain GPLed code was derived from their code, >> because it had been part of a system derived from their code. If they >> actually *had* the licenses they claimed they had, *and* their >> license >> terms meant what they claimed they meant, then they might have had >> had >> a case. Their problems included: > originally they claimed that code had been copied pretty much > literally > from their code basis --- thus, claiming that code that was used in > linux was copied from them. not sure how that is the opposite > direction. That is that it was code copied from their license to GPL, not that they were claiming that the GPL or any other open source license imposed limitations on someone's use of directly or indirectly derived work. So I don't think there's any application here. The only thing that could conceivably apply is that they claimed both literal copying and that IBM's code was a derived work simply because it was developed by a licensee (the 'viral UNIX license' theory). That should have been dead in the water because of the CSRG-USL row over the BSD code, and Novell shot it down anyway. Linden Labs contributor agreement should protect against any indirect claims like that. If Linden Labs states[1] that simply using the code to figure out the protocol (including using things like constants from header files) does NOT make a work a derived work, that should eliminate any concern about direct claims. [1] with appropriate legal terminology From richard at lindenlab.com Fri Oct 5 10:29:47 2007 From: richard at lindenlab.com (Richard Nelson) Date: Fri Oct 5 10:29:54 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <4705CEE1.1050802@gmail.com> References: <4705CEE1.1050802@gmail.com> Message-ID: 1. The camera can only get so close to the object before it starts getting clipped against the near clip plane. The purpose of the FOV zoom is to approximate the camera actually getting closer when it can't. Can you elaborate on how this fails when working with small prims (since that was the test case for the original implementation). 2. We are currently redesigning and replacing many of our existing callbacks/observers with one or more flexible idioms. One of the requirements is allowing for flexible interfaces from the Observed (not just a bitmask) and easy binding of user data. However, I think this is a case of a hammer making everything look like nails. The Observer pattern is very useful but when used in the place of clear functional dependencies can make the code harder to understand and debug, as I've seen in other codebases. 3. I am currently replacing hidden text elements with elements that don't purport to be widgets (via getUIString()). However this transition hasn't been completed (and we need to make sure that our localization tools support it properly), so you'll see both implementations until we clean that up. Richard On Thu, 04 Oct 2007 22:42:57 -0700, Jason Giglio wrote: > 1. Why does zoom transform into FOV zoom when you are closer than the > (fairly large) MIN_ZOOM threshold? That makes working on small prims a > real bitch. Can we lower MIN_ZOOM safely? > > 2. Why are all the Observer patterns used in the client so simplistic? > Is this a design decision? It seems they all only get a bitmask > parameter on the changed() event. Why can't we pass them more complex > data structures so that things like the entire UI could be turned into > Observer patterns? > > 3. What are the proper ways to use the XUI? Why do some floaters use > hidden "text" types for things that are really just misc strings? Why > not use the much easier getUIString? > > I see a whole lot of inconsistancy in the way the XUI is used. What is > the right way? Where are we going with this? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ley From seg at haxxed.com Fri Oct 5 10:41:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Oct 5 10:42:09 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: References: <4705CEE1.1050802@gmail.com> Message-ID: <1191606113.26663.16.camel@localhost> On Fri, 2007-10-05 at 10:29 -0700, Richard Nelson wrote: > 2. We are currently redesigning and replacing many of our existing > callbacks/observers with one or more flexible idioms. One of the > requirements is allowing for flexible interfaces from the Observed (not > just a bitmask) and easy binding of user data. However, I think this is a > case of a hammer making everything look like nails. The Observer pattern > is very useful but when used in the place of clear functional dependencies > can make the code harder to understand and debug, as I've seen in other > codebases. Would libsigc++ be any help here? (As opposed to reinventing more wheels...) http://libsigc.sourceforge.net/ Fairly widely used, LGPL licensed. I've got some code of my own I really need to port over to it... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071005/5fc882d2/attachment.pgp From richard at lindenlab.com Fri Oct 5 10:44:17 2007 From: richard at lindenlab.com (Richard Nelson) Date: Fri Oct 5 10:44:25 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <1191606113.26663.16.camel@localhost> References: <4705CEE1.1050802@gmail.com> <1191606113.26663.16.camel@localhost> Message-ID: We're evaluating that as well as boost::signals, which is more familiar to many of our devs. The goal is to also provide a Listener pattern as a wrapper around the signals/slots library. R. On Fri, 05 Oct 2007 10:41:52 -0700, Callum Lerwick wrote: > On Fri, 2007-10-05 at 10:29 -0700, Richard Nelson wrote: >> 2. We are currently redesigning and replacing many of our existing >> callbacks/observers with one or more flexible idioms. One of the >> requirements is allowing for flexible interfaces from the Observed (not >> just a bitmask) and easy binding of user data. However, I think this >> is a >> case of a hammer making everything look like nails. The Observer >> pattern >> is very useful but when used in the place of clear functional >> dependencies >> can make the code harder to understand and debug, as I've seen in other >> codebases. > > Would libsigc++ be any help here? (As opposed to reinventing more > wheels...) > > http://libsigc.sourceforge.net/ > > Fairly widely used, LGPL licensed. I've got some code of my own I really > need to port over to it... From michael at michaelverdi.com Fri Oct 5 10:51:45 2007 From: michael at michaelverdi.com (Michael Verdi) Date: Fri Oct 5 10:51:47 2007 Subject: [sldev] Flycam bug Message-ID: <94b4a6520710051051p5bdd9da1k21c92829b21038da@mail.gmail.com> I'm using the 3Dconnection Space Navigator as the flycam with Second Life 1.18.3.5 on Windows XP. I noticed that it works with SL in window mode but not in fullscreen. Also if you switch to full screen and back to window mode it won't work and the only way to get working again is to shut SL down (in window mode) and restart it. I verified this on two different machines with two different controllers. - Michael -- http://michaelverdi.com http://freevlog.org http://nscape.tv From mark.burhop at gmail.com Fri Oct 5 12:51:48 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Fri Oct 5 12:51:51 2007 Subject: [sldev] New SL Architecture Message-ID: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> Where do we stand with the new SL architecture? The Wiki ( https://wiki.secondlife.com/wiki/Category:Architecture_Working_Group) has been mostly quiet lately and the chat logs from Tao Takashi and what's been posted on the Wiki seem to have more questions than answers. I've got about 100 questions and didn't want to spam sldev if there's a better place. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071005/e8da4533/attachment.htm From tao.takashi at googlemail.com Fri Oct 5 13:59:28 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Fri Oct 5 13:59:30 2007 Subject: [sldev] New SL Architecture In-Reply-To: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> References: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> Message-ID: <23bbb49e0710051359n478b9acembd50641f42075e08@mail.gmail.com> Hi! 2007/10/5, Mark Burhop : > > Where do we stand with the new SL architecture? The Wiki (https://wiki.secondlife.com/wiki/Category:Architecture_Working_Group) > has been mostly quiet lately and the chat logs from Tao Takashi and what's > been posted on the Wiki seem to have more questions than answers. I've got > about 100 questions and didn't want to spam sldev if there's a better place. > What about simply setting up a questions list in the wiki, it might be the start of a FAQ or something. Zero also said that he wanted to look over the wiki on monday. Beside that I recommend Zero's office hours anyway. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071005/c9b13ab2/attachment.htm From lenglish5 at cox.net Fri Oct 5 14:26:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Oct 5 14:26:17 2007 Subject: [sldev] New SL Architecture In-Reply-To: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> References: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> Message-ID: <4706ABF7.2000208@cox.net> Mark Burhop wrote: > > Where do we stand with the new SL architecture? The Wiki ( > https://wiki.secondlife.com/wiki/Category:Architecture_Working_Group) > has been mostly quiet lately and the chat logs from Tao Takashi and > what's been posted on the Wiki seem to have more questions than > answers. I've got about 100 questions and didn't want to spam sldev if > there's a better place. > > - Mark > We just finished an AWG meeting in-world (IM Zha Ewry for group invite/ notification of time of next meeting) and they are posting the chat log to the wiki as I type. Lawson aka Saijanai Kuhn From lenglish5 at cox.net Fri Oct 5 14:35:10 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Oct 5 14:35:11 2007 Subject: [sldev] New SL Architecture In-Reply-To: <4706ABF7.2000208@cox.net> References: <773a33dc0710051251q6d7b7863n52b595c1a713efbc@mail.gmail.com> <4706ABF7.2000208@cox.net> Message-ID: <4706AE0E.5010103@cox.net> Lawson English wrote: > > We just finished an AWG meeting in-world (IM Zha Ewry for group > invite/ notification of time of next meeting) and they are posting the > chat log to the wiki as I type. > > Minutes for AWG meeting: https://wiki.secondlife.com/wiki/Oct5_scale_rest From lenglish5 at cox.net Fri Oct 5 14:37:53 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Oct 5 14:37:55 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 Message-ID: <4706AEB1.7050601@cox.net> Friday's log-chat of the AWG meeting is now up. Feel free to comment here or on the wiki. https://wiki.secondlife.com/wiki/Oct5_scale_rest L From seg at haxxed.com Fri Oct 5 14:43:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Oct 5 14:43:32 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> Message-ID: <1191620596.26663.34.camel@localhost> On Fri, 2007-10-05 at 13:32 +0100, Robin Cornelius wrote: > Can we maybe think about splitting up the viewer (distribution) into > smaller packages. Surely the various artwork and supplied textures > remain pretty constant and it seems wasteful redistributing the same > data over and over again. Ah, something else on the to do list I've forgotten about. In Fedora, we've been encouraging upstream projects to separate (arch-independent) game data from source. This is advantageous for us, no only can we issue updates to the binaries without everyone having to re-download a large amount of game data, but the game data can be a "noarch" package, shared across all architectures, reducing storage requirements on our mirrors. LL already separates the "artwork" from the viewer source, which is most of the way there. What makes it much less useful to us is the fact that a new artwork tarball comes out with every source release. Could LL avoid releasing a new artwork tarball unless it has actually changed? I haven't got around to diffing it and seeing how often it actually changes, if it is changing, maybe it shouldn't. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071005/3b736db9/attachment.pgp From dale at daleglass.net Fri Oct 5 15:43:18 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Oct 5 15:43:34 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <1191620596.26663.34.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> Message-ID: <200710060043.24118.dale@daleglass.net> On Friday 05 October 2007 23:43:16 Callum Lerwick wrote: > LL already separates the "artwork" from the viewer source, which is most > of the way there. What makes it much less useful to us is the fact that > a new artwork tarball comes out with every source release. Could LL > avoid releasing a new artwork tarball unless it has actually changed? I > haven't got around to diffing it and seeing how often it actually > changes, if it is changing, maybe it shouldn't. ;P How about putting the artwork and libraries packages into SVN (or whatever)? That'd allow to tell much more easily when it changes, and updates would be less of a pain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071006/bc08598d/attachment.pgp From jhurliman at wsu.edu Fri Oct 5 18:12:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Oct 5 18:12:09 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <200710060043.24118.dale@daleglass.net> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> <200710060043.24118.dale@daleglass.net> Message-ID: <4706E0F0.50100@wsu.edu> Dale Glass wrote: > On Friday 05 October 2007 23:43:16 Callum Lerwick wrote: > >> LL already separates the "artwork" from the viewer source, which is most >> of the way there. What makes it much less useful to us is the fact that >> a new artwork tarball comes out with every source release. Could LL >> avoid releasing a new artwork tarball unless it has actually changed? I >> haven't got around to diffing it and seeing how often it actually >> changes, if it is changing, maybe it shouldn't. ;P >> > > How about putting the artwork and libraries packages into SVN (or > whatever)? That'd allow to tell much more easily when it changes, and > updates would be less of a pain. > > > The openmetaverse.org project went the route of putting everything in SVN, and branching can be a huge pain. Having 10,000(ish) boost header files in every single branch and tag creates these monstrous databases and makes committing and checking out a huge pain every time a new release is made. In theory I would love to see everything in SVN, but we found out in practice it can be fairly painful. Also, one odd thing I noticed is it seems to be easier at LL to get stuff in the artwork or libraries packages then in to SVN. The MSVC 2005 project files in SVN are more or less the originals I submitted long long ago on a JIRA task and haven't been updated in ages, yet the libraries package comes with (almost) updated solution/project files that overwrite the ones in SVN! I would hate to see this "easy" avenue of pushing out bleeding edge stuff to the community squashed. John Hurliman From dzonatas at dzonux.net Fri Oct 5 18:21:01 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Oct 5 18:18:48 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <4706E0F0.50100@wsu.edu> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> <200710060043.24118.dale@daleglass.net> <4706E0F0.50100@wsu.edu> Message-ID: <4706E2FD.8050107@dzonux.net> John Hurliman wrote: > The openmetaverse.org project went the route of putting everything in > SVN, and branching can be a huge pain. Having 10,000(ish) boost header > files in every single branch and tag creates these monstrous databases > and makes committing and checking out a huge pain every time a new > release is made. In theory I would love to see everything in SVN, but > we found out in practice it can be fairly painful. Sounds like svn:externals would ease that. http://svnbook.red-bean.com/en/1.1/ch07s04.html -- Power to Change the Void From robla at lindenlab.com Fri Oct 5 18:21:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Oct 5 18:21:34 2007 Subject: [sldev] MSVC 2005 project files (Re: Packaging the viewer for Linux distributions) In-Reply-To: <4706E0F0.50100@wsu.edu> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> <200710060043.24118.dale@daleglass.net> <4706E0F0.50100@wsu.edu> Message-ID: <4706E310.9010300@lindenlab.com> On 10/5/07 6:12 PM, John Hurliman wrote: > Also, one odd thing I noticed is it seems to be easier at LL to get > stuff in the artwork or libraries packages then in to SVN. The MSVC > 2005 project files in SVN are more or less the originals I submitted > long long ago on a JIRA task and haven't been updated in ages, yet the > libraries package comes with (almost) updated solution/project files > that overwrite the ones in SVN! That almost certainly shouldn't be the case, and is probably an artifact of some bug in the scripts we're using to publish source code. Which exact files/branches are you talking about? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071005/b57c985a/signature-0001.pgp From odysseus654 at gmail.com Fri Oct 5 18:36:35 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Oct 5 18:36:39 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4706AEB1.7050601@cox.net> References: <4706AEB1.7050601@cox.net> Message-ID: <1674f6c70710051836g7fbb7c81oaff5da98ada4e1b3@mail.gmail.com> I have a heck of a lot of reactions to this, but not sure where to stuff them. Are the conversations in this log still being put up? Closest match I see is "Brainstorming", although I'm curious about the flamewar in the latter half of the thread, also interested in the DRM discussion that came up. I'm not that familiar with wiki discussions, limit myself to talk pages? On 10/5/07, Lawson English wrote: > > Friday's log-chat of the AWG meeting is now up. Feel free to comment > here or on the wiki. > > https://wiki.secondlife.com/wiki/Oct5_scale_rest > > > L > _______________________________________________ > 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/20071005/e34666af/attachment.htm From nicholaz at blueflash.cc Fri Oct 5 18:38:25 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Oct 5 18:38:32 2007 Subject: [sldev] MSVC 2005 project files (Re: Packaging the viewer for Linux distributions) In-Reply-To: <4706E310.9010300@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> <200710060043.24118.dale@daleglass.net> <4706E0F0.50100@wsu.edu> <4706E310.9010300@lindenlab.com> Message-ID: On Oct 6, 2007, at 3:21 AM, Rob Lanphier wrote: > On 10/5/07 6:12 PM, John Hurliman wrote: >> Also, one odd thing I noticed is it seems to be easier at LL to get >> stuff in the artwork or libraries packages then in to SVN. The MSVC >> 2005 project files in SVN are more or less the originals I submitted >> long long ago on a JIRA task and haven't been updated in ages, yet >> the >> libraries package comes with (almost) updated solution/project files >> that overwrite the ones in SVN! > > That almost certainly shouldn't be the case, and is probably an > artifact > of some bug in the scripts we're using to publish source code. Which > exact files/branches are you talking about? As far as I can tell, pretty much every branch since 1.14 (btw, see VRW-1151) ... not that I bothered to check anymore after 1.17 Nick From jhurliman at wsu.edu Fri Oct 5 18:39:33 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Oct 5 18:39:17 2007 Subject: [sldev] Re: MSVC 2005 project files (Re: Packaging the viewer for Linux distributions) In-Reply-To: <4706E310.9010300@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> <1191620596.26663.34.camel@localhost> <200710060043.24118.dale@daleglass.net> <4706E0F0.50100@wsu.edu> <4706E310.9010300@lindenlab.com> Message-ID: <4706E755.9020709@wsu.edu> Rob Lanphier wrote: > On 10/5/07 6:12 PM, John Hurliman wrote: > >> Also, one odd thing I noticed is it seems to be easier at LL to get >> stuff in the artwork or libraries packages then in to SVN. The MSVC >> 2005 project files in SVN are more or less the originals I submitted >> long long ago on a JIRA task and haven't been updated in ages, yet the >> libraries package comes with (almost) updated solution/project files >> that overwrite the ones in SVN! >> > > That almost certainly shouldn't be the case, and is probably an artifact > of some bug in the scripts we're using to publish source code. Which > exact files/branches are you talking about? > > Rob > > I just went back and checked through everything twice and I was wrong, ignore that last comment entirely. I downloaded vc8_1_18_V1.zip from https://jira.secondlife.com/browse/VWR-1151 and extracted it to the same directory as the library and artwork files before merging them in to the source tree, and coming back to look at it I mistakenly thought they had come from the artwork or libraries package. Dzonatas, svn:externals seems like something that should be looked in to for this. John Hurliman From lenglish5 at cox.net Fri Oct 5 20:59:51 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Oct 5 20:59:53 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1674f6c70710051836g7fbb7c81oaff5da98ada4e1b3@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <1674f6c70710051836g7fbb7c81oaff5da98ada4e1b3@mail.gmail.com> Message-ID: <47070837.9080104@cox.net> Erik Anderson wrote: > I have a heck of a lot of reactions to this, but not sure where to > stuff them. Are the conversations in this log still being put up? > Closest match I see is "Brainstorming", although I'm curious about the > flamewar in the latter half of the thread, also interested in the DRM > discussion that came up. I'm not that familiar with wiki discussions, > limit myself to talk pages? > > On 10/5/07, *Lawson English* > wrote: > > Friday's log-chat of the AWG meeting is now up. Feel free to comment > here or on the wiki. > > https://wiki.secondlife.com/wiki/Oct5_scale_rest > I think that that is the total of it, and I started a talk-page discussion on my little sub-topic. Not sure if there are other venues for disucssion via the wiki, either. The flame-war mostly came about because we'd been chatting for so many hours non-stop without a break, I think. Note starting and ending times. L From blindwanderer at gmail.com Fri Oct 5 22:02:59 2007 From: blindwanderer at gmail.com (Strife Onizuka) Date: Fri Oct 5 22:03:03 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47070837.9080104@cox.net> References: <4706AEB1.7050601@cox.net> <1674f6c70710051836g7fbb7c81oaff5da98ada4e1b3@mail.gmail.com> <47070837.9080104@cox.net> Message-ID: <89ca6da00710052202l192af1p2edbb005676c6852@mail.gmail.com> *kicks self for missing meeting* When is the next meeting scheduled? On 10/5/07, Lawson English wrote: > Erik Anderson wrote: > > I have a heck of a lot of reactions to this, but not sure where to > > stuff them. Are the conversations in this log still being put up? > > Closest match I see is "Brainstorming", although I'm curious about the > > flamewar in the latter half of the thread, also interested in the DRM > > discussion that came up. I'm not that familiar with wiki discussions, > > limit myself to talk pages? > > > > On 10/5/07, *Lawson English* > > wrote: > > > > Friday's log-chat of the AWG meeting is now up. Feel free to comment > > here or on the wiki. > > > > https://wiki.secondlife.com/wiki/Oct5_scale_rest > > > > I think that that is the total of it, and I started a talk-page > discussion on my little sub-topic. Not sure if there are other venues > for disucssion via the wiki, either. > > The flame-war mostly came about because we'd been chatting for so many > hours non-stop without a break, I think. Note starting and ending times. > > > L > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From zha.ewry at gmail.com Fri Oct 5 22:55:10 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Fri Oct 5 22:55:12 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <89ca6da00710052202l192af1p2edbb005676c6852@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <1674f6c70710051836g7fbb7c81oaff5da98ada4e1b3@mail.gmail.com> <47070837.9080104@cox.net> <89ca6da00710052202l192af1p2edbb005676c6852@mail.gmail.com> Message-ID: <920d7d850710052255q4b293db2j89c3db64ef4622f7@mail.gmail.com> Tuesday, 8:00 am PDT (SLT) is our next target. (Try to not torture the Europeans quite as much) I'll post it via a notice, if SL stops being cranky - Zha On 10/6/07, Strife Onizuka wrote: > > *kicks self for missing meeting* > When is the next meeting scheduled? > > On 10/5/07, Lawson English wrote: > > Erik Anderson wrote: > > > I have a heck of a lot of reactions to this, but not sure where to > > > stuff them. Are the conversations in this log still being put up? > > > Closest match I see is "Brainstorming", although I'm curious about the > > > flamewar in the latter half of the thread, also interested in the DRM > > > discussion that came up. I'm not that familiar with wiki discussions, > > > limit myself to talk pages? > > > > > > On 10/5/07, *Lawson English* > > > wrote: > > > > > > Friday's log-chat of the AWG meeting is now up. Feel free to > comment > > > here or on the wiki. > > > > > > https://wiki.secondlife.com/wiki/Oct5_scale_rest > > > > > > > I think that that is the total of it, and I started a talk-page > > discussion on my little sub-topic. Not sure if there are other venues > > for disucssion via the wiki, either. > > > > The flame-war mostly came about because we'd been chatting for so many > > hours non-stop without a break, I think. Note starting and ending times. > > > > > > L > > _______________________________________________ > > 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/20071006/fd10cbeb/attachment.htm From lenglish5 at cox.net Sat Oct 6 00:09:33 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 00:09:35 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4706AEB1.7050601@cox.net> References: <4706AEB1.7050601@cox.net> Message-ID: <470734AD.4080802@cox.net> Lawson English wrote: > Friday's log-chat of the AWG meeting is now up. Feel free to comment > here or on the wiki. > > https://wiki.secondlife.com/wiki/Oct5_scale_rest > > My comment on my own contribution: https://wiki.secondlife.com/wiki/Talk:Oct5_scale_rest From secret.argent at gmail.com Sat Oct 6 06:40:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 06:40:34 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470734AD.4080802@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> Message-ID: <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> On 06-Oct-2007, at 02:09, Lawson English wrote: > Lawson English wrote: >> Friday's log-chat of the AWG meeting is now up. Feel free to >> comment here or on the wiki. >> >> https://wiki.secondlife.com/wiki/Oct5_scale_rest Very dense (high information content) material, I second the call for a summary. :) > My comment on my own contribution: > > https://wiki.secondlife.com/wiki/Talk:Oct5_scale_rest Added a comment there too. Some kind of general asset tagging needs to be established pretty early on, even if at first it's only used between grids. Properties on an asset with some kind of domain key and name. The first thing I thought of was to index it by creator- UUID and property name, and internally or in transport use reference compression like DNS does - instead of storing N copies of the creator UUID for N properties, have the UUIDs be indexed by back- reference. Maybe a separate UUID table would be better, though, since any given asset shouldn't need too many UUIDs associated with it. (I think better in pseudo-SQL than XML) CREATE TABLE uuids ( uuid_num short integer primary key, -- not stored separately, just the index of this UUID in the array. uuid long long integer ); CREATE TABLE properties ( domain_uuid_num short integer, -- domain that defined it, or NULL for standard-defined properties creator_uuid_num short integer, -- UUID of creator agent, or NULL for domain-global permissions short integer, -- bitmap, includes flags for things like whether other domains should allow it to change name varchar, value varchar, UNIQUE (domain_uuid_num, name) -- primary key ); Having the key for the property include the creator domain will avoid namespace collisions and let the standard add required properties without worrying about whether some random domain has used that name already. Permissions are of course discretionary, but are also hints as to whether the property will be ignored when the asset returns to the originating domain. From zha.ewry at gmail.com Sat Oct 6 09:15:19 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Sat Oct 6 09:15:22 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> Message-ID: <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> Unless I miss the mark badly, the intent is that any asset which can be used by a service (ie has a public appearance) will have a URL form.This should allow complete disambiguation as to which asset server holds each asset. With REST and the overall web approach, when we want to know the extrinsic properties of an asset, a properly formed query against the URL should/could result in the properties being returned. In general, looking towards existing REST style web resource patterns is the goal here. - Zha On 10/6/07, Argent Stonecutter wrote: > > On 06-Oct-2007, at 02:09, Lawson English wrote: > > Lawson English wrote: > >> Friday's log-chat of the AWG meeting is now up. Feel free to > >> comment here or on the wiki. > >> > >> https://wiki.secondlife.com/wiki/Oct5_scale_rest > > Very dense (high information content) material, I second the call for > a summary. :) > > > My comment on my own contribution: > > > > https://wiki.secondlife.com/wiki/Talk:Oct5_scale_rest > > Added a comment there too. Some kind of general asset tagging needs > to be established pretty early on, even if at first it's only used > between grids. Properties on an asset with some kind of domain key > and name. The first thing I thought of was to index it by creator- > UUID and property name, and internally or in transport use reference > compression like DNS does - instead of storing N copies of the > creator UUID for N properties, have the UUIDs be indexed by back- > reference. Maybe a separate UUID table would be better, though, since > any given asset shouldn't need too many UUIDs associated with it. > > (I think better in pseudo-SQL than XML) > > CREATE TABLE uuids ( > uuid_num short integer primary key, -- not stored separately, > just the index of this UUID in the array. > uuid long long integer > ); > > CREATE TABLE properties ( > domain_uuid_num short integer, -- domain that defined it, or > NULL for standard-defined properties > creator_uuid_num short integer, -- UUID of creator agent, or > NULL for domain-global > permissions short integer, -- bitmap, includes flags for > things like whether other domains should allow it to change > name varchar, > value varchar, > UNIQUE (domain_uuid_num, name) -- primary key > ); > > Having the key for the property include the creator domain will avoid > namespace collisions and let the standard add required properties > without worrying about whether some random domain has used that name > already. Permissions are of course discretionary, but are also hints > as to whether the property will be ignored when the asset returns to > the originating domain. > > _______________________________________________ > 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/20071006/7be89b43/attachment.htm From aaron at metaversatility.com Sat Oct 6 10:18:33 2007 From: aaron at metaversatility.com (Aaron Delwiche) Date: Sat Oct 6 10:18:35 2007 Subject: [sldev] What do developers think about Second Life community and platform? Message-ID: Hi, I am one of the co-founders of the virtual world development agency Metaversatility. From now through October 15th, we are surveying Second Life residents on behalf of a well-known technology company. You might have read something about this survey in the Second Life Insider or the Second Life Herald. We are particularly interested in understanding what coders of all stripes think about Second Life, both as a community and as a platform. The SLDEV list seems like one of the best ways of reaching the expert SL development community. If you have seven minutes, I encourage you to participate in the survey, which is posted at: http://www.metaversatility.com/survey/welcome.sldev.html Though this is privately sponsored, the researchers and sponsors are committed to sharing highlights with the Second Life community after the data has been collected. Also, in recognition of their time, survey respondents are eligible to participate in a sweepstakes with prizes worth hundreds of US dollars. The grand prize is a donation of $50,000 Linden Dollars to the charity of the winner's choice. Respondents are also eligible to receive $20,000 Linden Dollars deposited in the inventory of their personal avatar. The full list of prizes is appended to this message. We are also trying to reach out to beginning SL programmers, and I suspect that many of the newer developers do not read this list regularly. If you have any suggestions for how to best approach beginning coders, please feel free to contact me at: aaron@metaversatility.com Thanks in advance for your time! Aaron Delwiche Co-founder, Metaversatility ------ Prizes include the following: 50,000 Linden Dollars donated to your favorite charity in your name. 20,000 Linden Dollars donated to your avatar's personal account. Advertising for your business on SLExchange.Com (15,000 impressions) Advertising your business with a half-page ad in The Metaverse Messenger Jeff Heaton, Scripting Recipes for Second Life (364 pages, PDF format) Terraforming tool: Land Worker 1.01 Production holodeck from Inside This World Anti-griefing tool: Omicron 1.3.3 Building tool: Virtual Builder Studio Pack Animation tool: Puppeteer Prim Animation Kit (Vendor Edition) WeatherSystem tool by Damanios Thetan Inventory management tool: AND Inventory Sorter Music: Frogg Marlowe, Ain't No Women (CD format) Music: AldoManutio Abruzzo, Deep Winter, North Texas Skies (CD format) Music: Cylindrian Rutabega, Living Stories (CD format) Music: Jonathan Coulton Where Tradition Meets Tomorrow and Smoking Monkey (MP3) -- Aaron Delwiche Co-founder, Metaversatility +1 (210) 347-6888 From secret.argent at gmail.com Sat Oct 6 11:21:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 11:21:52 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> Message-ID: On 06-Oct-2007, at 11:15, Zha Ewry wrote: > Unless I miss the mark badly, the intent is that any asset which > can be used by a service (ie has a public appearance) will have a > URL form.This should allow complete disambiguation as to which > asset server holds each asset. With REST and the overall web > approach, when we want to know the extrinsic properties of an > asset, a properly formed query against the URL should/could result > in the properties being returned. In general, looking towards > existing REST style web resource patterns is the goal here. I think you're talking about a different issue than I am. I'm talking about managing domain-specific properties associated with an asset, not the location of a specific copy of an asset on a particular asset server, nor the mechanism for accessing those properties. First, whether you're accessing an asset from a remote server via a URL, or working with a local cached copy of the asset, or making a permanent copy of the asset in another region (for example, rezzing an object into the world), the properties need to be available. Second, properties on an asset may originate in different domains... for example, a property that describes a characteristic of an asset that the original domain didn't support would be expected to be maintained, and it needs to avoid conflicting with any properties specific to the original domain. Third, the domain a property is specific to is not necessarily defined by the location of the asset server. A property may be specific to a particular simulator software package, and so the domain of that property would be associated with that package, and any regions running that software would use the same domain identifier when setting that property. A property may even be specific to a viewer, set from the client, and treated as an opaque object by all regions. So... it doesn't matter whether the identifier of a domain is a UUID or a URL. It doesn't matter whether it's fetched through multiple HTTP requests, or one HTTP request, or by any other mechanism. There needs to be a mechanism to allow software to assign properties specific to a domain. These properties have to avoid conflicting with properties set by other domains, but they have to be enumerable and copyable so that they are maintained whether the asset is copied, cached, or always explicitly fetched. The tuple { domain_id, creator_id, permissions, name, value } with { domain_id, name } being a unique key. Creator ID and permissions are advisory, but useful to have there so that users won't be surprised when (for example) the changes they made to their jacket when they were in another grid get lost whenever they return home. Anyway, the tuple could be reduced to { domain_id, name, value }. The key point is that the domain_id of the property should not be constrained to being the same as the domain of the asset server the asset is at that moment residing on. From gigstaggart at gmail.com Sat Oct 6 11:35:39 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Oct 6 11:35:39 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: References: <4705CEE1.1050802@gmail.com> Message-ID: <4707D57B.4050803@gmail.com> Richard Nelson wrote: > 1. The camera can only get so close to the object before it starts > getting clipped against the near clip plane. The purpose of the FOV > zoom is to approximate the camera actually getting closer when it > can't. Can you elaborate on how this fails when working with small > prims (since that was the test case for the original implementation). > The camera behaves in unexpected ways when it's in FOV zoom on small prims mainly. I'll have to play with it some. > 2. We are currently redesigning and replacing many of our existing > callbacks/observers with one or more flexible idioms. One of the > requirements is allowing for flexible interfaces from the Observed (not > just a bitmask) and easy binding of user data. However, I think this is > a case of a hammer making everything look like nails. The Observer > pattern is very useful but when used in the place of clear functional > dependencies can make the code harder to understand and debug, as I've > seen in other codebases. > OK, cool. This is the kind of communication we need more of. Thanks. :) > 3. I am currently replacing hidden text elements with elements > that don't purport to be widgets (via getUIString()). However this > transition hasn't been completed (and we need to make sure that our > localization tools support it properly), so you'll see both > implementations until we clean that up. OK, so if we are adding new UI, we should avoid text elements that aren't really text elements, and use XUI strings instead, if appropriate? Should we clean these up if we are touching a file that has them anyway? -Jason From roamingryozu at gmail.com Sat Oct 6 12:31:43 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Sat Oct 6 12:31:45 2007 Subject: [sldev] Flycam bug In-Reply-To: <94b4a6520710051051p5bdd9da1k21c92829b21038da@mail.gmail.com> References: <94b4a6520710051051p5bdd9da1k21c92829b21038da@mail.gmail.com> Message-ID: <5eff6d3b0710061231w368ba633ka62771a65b88be05@mail.gmail.com> Very strange. Have you posted an issue to pjira about it? On 10/5/07, Michael Verdi wrote: > I'm using the 3Dconnection Space Navigator as the flycam with Second > Life 1.18.3.5 on Windows XP. I noticed that it works with SL in window > mode but not in fullscreen. Also if you switch to full screen and back > to window mode it won't work and the only way to get working again is > to shut SL down (in window mode) and restart it. > I verified this on two different machines with two different controllers. > > - Michael > > > -- > http://michaelverdi.com > http://freevlog.org > http://nscape.tv > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Sat Oct 6 13:42:04 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Oct 6 13:42:26 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> Message-ID: <1191703325.26663.98.camel@localhost> On Sat, 2007-10-06 at 12:15 -0400, Zha Ewry wrote: > Unless I miss the mark badly, the intent is that any asset which can > be used by a service (ie has a public appearance) will have a URL > form.This should allow complete disambiguation as to which asset > server holds each asset. With REST and the overall web approach, when > we want to know the extrinsic properties of an asset, a properly > formed query against the URL should/could result in the properties > being returned. In general, looking towards existing REST style web > resource patterns is the goal here. "Almost all programming can be viewed as an exercise in caching" The way I see the internet moving as a whole, is being a giant distributed cache. We need to stop caring about where an asset is stored, and be more concerned with the identity of the asset. The asset could very well be stored in thousands of places across the internet, both large and small. For this to happen, we need a way to unambiguously identify an asset, completely independent of its location. A content hash is probably the best way to do this. Duplicate copies of an asset become obvious to identify, and likewise maliciously modified or corrupted copies of the asset can be identified and culled. You then need a process with which to take an asset hash and find a location from which to request a full copy. DNS is one example of this kind of process. You take an identifier like secondlife.com and resolve it to a physical location, an IP address. Note that it can easily resolve to *multiple* IP addresses. A distributed system like Kademlia is another route to take. Or you can just ask Google. Or all three. Note that this all can nicely coexist, abstracted behind URLs. You can have assets on the web as it exists today: http://foo.com/bar/baz/lolcat.j2k Or do something like this: findassetprotocol://3d2b5bf415880e67f5c2aecccdc238f4c5dbf5a1 Which may very well resolve to a referral to the above URL. Or resolve to a torrent. Or resolve to a locally cached copy. Or resolve to an asset that currently only exists locally. Local asset storage is not hard problem, people. Or even: http://assetgateway.secondlife.com/3d2b5bf415880e67f5c2aecccdc238f4c5dbf5a1 And even: http://legacyassets.secondlife.com/a996abeb-fe86-0e45-8740-a8be3a8b8178 Something to keep in mind: http://online-desktop.org/wiki/Online_Desktop -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071006/76c47c27/attachment.pgp From secret.argent at gmail.com Sat Oct 6 14:25:28 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 14:25:26 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191703325.26663.98.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> Message-ID: <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> On 06-Oct-2007, at 15:42, Callum Lerwick wrote: > "Almost all programming can be viewed as an exercise in caching" Yah. Caching was the thing that immediately sprang to mind as a problem with using a URL and making requests in real time. Resources need to live "close" to where they're used. Assets are going to get copied around. Assets referred to from in-world objects need to still work even if the asset server from Joe's Bar and Grid is offline, so they need to be cached. > For this to happen, we need a way to unambiguously > identify an asset, completely independent of its location. A content > hash is probably the best way to do this. Duplicate copies of an asset > become obvious to identify, and likewise maliciously modified or > corrupted copies of the asset can be identified and culled. What about assets with editable properties, like clothing, gestures, notecards, and so on? Where do permissions live? They're a common property of all assets in the SL domain. They're not part of the asset, because different "copies" of the asset have different permissions. Or does the asset need to get split into a static part (eg, the actual texture) and a dynamic one (SL permissions)? From tao.takashi at googlemail.com Sat Oct 6 14:53:12 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sat Oct 6 14:53:14 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> Message-ID: <23bbb49e0710061453x6a3245aqf3851534197f2d7a@mail.gmail.com> Hi! 2007/10/6, Argent Stonecutter : > > > > Where do permissions live? They're a common property of all assets in > the SL domain. They're not part of the asset, because different > "copies" of the asset have different permissions. Or does the asset > need to get split into a static part (eg, the actual texture) and a > dynamic one (SL permissions)? So why aren't they just copies? I think if you take caching too far it gets very complicated. E.g. you probably cannot make sure anyway that every cached instance of a copy gets invalidated or changed once you change the original object. I was thinking more about really copying the object to the region domain once it gets rezzed. It might then have another URL on the region domain (part of the URL might be some sort of UUID or internal ID). So if I give a notecard to somebody I wouldn't expect it to change if I change my original version. I would still do these things via a script or in some "intelligent" object. What I thought was something like the scope a creator can define once they give or rez the object. This might define in which circles it can be used. Like scope can be "only that region", "all regions on this domain", "only trusted domains of level X" etc. Problem is of course once it hits the region domain in Joe's garage nothing should be trusted anymore. With having a scope we can nevertheless still allow these regions to connect, you just cannot rez every object on them because the agent domain might forbid it (surely one would need to think about all the possible cases). -- Tao _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071006/bb8dc23f/attachment.htm From lenglish5 at cox.net Sat Oct 6 15:11:53 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 15:11:53 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> Message-ID: <47080829.1000200@cox.net> Argent Stonecutter wrote: > > The key point is that the domain_id of the property should not be > constrained to being the same as the domain of the asset server the > asset is at that moment residing on. Save in the special case of private/unpublished assets. L. From seg at haxxed.com Sat Oct 6 15:30:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Oct 6 15:30:35 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> Message-ID: <1191709820.26663.133.camel@localhost> On Sat, 2007-10-06 at 16:25 -0500, Argent Stonecutter wrote: > What about assets with editable properties, like clothing, gestures, > notecards, and so on? Copy on write. If you edit it, it is a new asset, and gets a new identifier. I've been musing on this. I think what we need to do is make a clear definition between an asset, and an instance of an asset. An asset is immutable. It never changes. Its identity *is* its content, summarized by a content hash. (This greatly simplifies mirroring and caching.) Linden Lab's proposed design doesn't even mention an "Asset Domain", but that is where this stuff lives. However, an instance of an asset can have additional dynamic state attached. Its location in a sim, script state, etc. This stuff would live in the Region and maybe Agent domains. We have the case of objects being actively edited. "Editing" could mean a script modifying the object. We should perhaps think of the Asset Domain as long term storage. Objects being actively edited live in mutable, ethereal anonymous state, that exists only in the Region domain. To be accessible outside that region, it must be "baked" and passed into the Asset domain. > Where do permissions live? They're a common property of all assets > in > the SL domain. They're not part of the asset, because different > "copies" of the asset have different permissions. Or does the asset > need to get split into a static part (eg, the actual texture) and a > dynamic one (SL permissions)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071006/6b2439c2/attachment.pgp From secret.argent at gmail.com Sat Oct 6 15:35:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 15:35:33 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <23bbb49e0710061453x6a3245aqf3851534197f2d7a@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <23bbb49e0710061453x6a3245aqf3851534197f2d7a@mail.gmail.com> Message-ID: On 06-Oct-2007, at 16:53, Tao Takashi wrote: > So why aren't they just copies? I think if you take caching too far it > gets very complicated. E.g. you probably cannot make sure anyway > that every > cached instance of a copy gets invalidated or changed once you > change the > original object. I was thinking more about really copying the > object to the region > domain once it gets rezzed. It might then have another URL on the > region domain > (part of the URL might be some sort of UUID or internal ID). Well, that's what I was thinking too. That's what confused me about Zha's comment, the implication that the asset and its properties would have a permanent home with a specific URL. It has to be copied around, but the properties don't necessarily make sense outside the the original domain, but they need to keep them so when you get back you haven't had them stripped out. There's really two classes of assets: 1. Static content: textures, animations, and so on. 2. Dynamic content: gestures, notecards, and so on. The static content could be cached, but the dynamic content needs to be copied when it's rezzed or edited. Really, this would be simplified if logically every inventory item was treated as a compound object, with the texture inventory item containing the local editable properties and a reference to the global asset that is the actual texture. Within a single domain this wouldn't require any changes for native objects. > What I thought was something like the scope a creator can define > once they give or > rez the object. This might define in which circles it can be used. > Like scope can be > "only that region", "all regions on this domain", "only trusted > domains of level X" etc. That's what I was getting at a while back when I was talking about having as an attribute of an asset a list of certificates (or references to certificates in its domain, or similar asymmetric encryption keys). When a region requests an asset with a non-empty certificate list it would need to have a matching key to at least one of the certificates. The creator wouldn't have to see the certificates, of course. They'd just have a list of names they could grant access to the asset. So you could say your "Cool Prim Hair" could be exported to "SL Grid, Disney, AOL, and Offshore Casino Co-op". A domain that didn't want to play the encryption game could just allow any asset in its domain to go to anyone. Or allow none. I'm not sure that it would be meaningful to have restrictions tighter than a domain, particularly since you're maintaining local copies (in cache or in a local asset server) and transfers between regions in a domain wouldn't even be seen by the originating domain. From secret.argent at gmail.com Sat Oct 6 15:37:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 15:36:55 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47080829.1000200@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <47080829.1000200@cox.net> Message-ID: On 06-Oct-2007, at 17:11, Lawson English wrote: > Argent Stonecutter wrote: >> The key point is that the domain_id of the property should not be >> constrained to being the same as the domain of the asset server >> the asset is at that moment residing on. > Save in the special case of private/unpublished assets. Well, unless the viewer puts some on them. But I suppose a domain could disallow that as well (after all, SL does). From secret.argent at gmail.com Sat Oct 6 15:45:27 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 15:45:25 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191709820.26663.133.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> Message-ID: <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> On 06-Oct-2007, at 17:30, Callum Lerwick wrote: > On Sat, 2007-10-06 at 16:25 -0500, Argent Stonecutter wrote: >> What about assets with editable properties, like clothing, gestures, >> notecards, and so on? > Copy on write. If you edit it, it is a new asset, and gets a new > identifier. That would cause some problems for SL: you don't change the UUID of a texture when you change the permissions or description. They'd have to be separate from the asset. > However, an instance of an asset can have additional dynamic state > attached. Its location in a sim, script state, etc. This stuff would > live in the Region and maybe Agent domains. That should work as well as - and be a lot clearer than - my idea of making the texture a compound asset. > We have the case of objects being actively edited. "Editing" could > mean > a script modifying the object. I think LL are ahead of this one: scripts can't modify assets. > We should perhaps think of the Asset > Domain as long term storage. Objects being actively edited live in > mutable, ethereal anonymous state, that exists only in the Region > domain. To be accessible outside that region, it must be "baked" and > passed into the Asset domain. I think the "instance" needs to be a long term object, as well. If you edit a texture in your inventory, change its properties, its identifier shouldn't change. From lenglish5 at cox.net Sat Oct 6 15:52:52 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 15:52:54 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191709820.26663.133.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> Message-ID: <470811C4.10003@cox.net> Callum Lerwick wrote: > > > We have the case of objects being actively edited. "Editing" could mean > a script modifying the object. We should perhaps think of the Asset > Domain as long term storage. Objects being actively edited live in > mutable, ethereal anonymous state, that exists only in the Region > domain. To be accessible outside that region, it must be "baked" and > passed into the Asset domain. > > Again, where does the unpublished asset live? Is it simply not-an-asset? This issue needs to be addressed because you can't reasonably do a regexp search of all notecards in your inventory, letalone all notes taken of all people you have ever met anywhere in the metaverse friend or not, unless some private version of these exist client-side in a format that is flagged as "searchable content". Why go creating special-case flags when you can simply have a generic class of object that doesn't require validation from some asset server before you can gain access? Private content is never "stale" or invalid, since the client itself has the only copy and no external asset server can even know it exists until it is published (either as a copy of the original or transformed into an external asset with no private copy leftover). My keyword floater can't use the LLInventory* classes to display folder-style hierarchies because keywords aren't an asset, for a more trivial example. For a more complex example, how does one deal with locally built assets, such as avatars, prims, etc., that have never been published, even to a private sim? An example of this would be prims (or avatar appearances) created/edited via plug-ins with more complex interfaces than the rudimentary in-world tools provide. Do we just say "let the plug-in writers worry about this" or do we address the issue from the start and provide a generic mechanism to allow manipulation of non-published stuff using the same GUI as currently only handles published stuff? L. From roamingryozu at gmail.com Sat Oct 6 16:25:48 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Sat Oct 6 16:25:50 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470811C4.10003@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> Message-ID: <5eff6d3b0710061625g31bc8ccfo43b3e3bd542730e5@mail.gmail.com> >I think the "instance" needs to be a long term object, as well. If >you edit a texture in your inventory, change its properties, its >identifier shouldn't change. So in a multisource system where I call for an asset by it's ID What permissions will it have when I recieve it? Probably, the ID itself wouldn't change, but when calling for an asset, it's permissions would be a part of the call. (ID)(Base Permissions Byte)(Extend Permissions Byte for servers that use it) Aside from that, do we even have a definition of what an asset is, or can be? Right now, we have a defined list of asset types. Texture, Gesture, Clothing, etc. For an extensible architecture, in a world where SL is a common thing, it needs to be versatile. I figure, an asset needs to be defined in separate parts. A header that defines common attributes such as asset type. Textures probably won't always be jpeg2000, so obviously a way to define just what kind data is in the asset is needed. What other attributes would be static and go in the header? (Size, Data block CRC, Identifier) If each block is marked, additional blocks can be added. Forgive me if I'm missing something obvious, I'm missing a huge chunk of the conversation having not read the meeting logs yet. From seg at haxxed.com Sat Oct 6 16:34:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Oct 6 16:34:35 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> Message-ID: <1191713659.26663.169.camel@localhost> On Sat, 2007-10-06 at 17:45 -0500, Argent Stonecutter wrote: > > Copy on write. If you edit it, it is a new asset, and gets a new > > identifier. > > That would cause some problems for SL: you don't change the UUID of a > texture when you change the permissions or description. They'd have > to be separate from the asset. I thought we were agreeing that permissions are part of an asset instance. :) Description is a bit less clear cut. An asset creator would probably want to be able to set a name and a description that is part of the asset, thus part of its identity. You would then be unable to edit that description without ending up with a new asset. You could have your own description, that lives as part of the asset instance in your inventory, in the Agent domain, and is not part of the global asset itself. We can't count on the creator to give things sensible, unique names or useful descriptions... > > However, an instance of an asset can have additional dynamic state > > attached. Its location in a sim, script state, etc. This stuff would > > live in the Region and maybe Agent domains. > > That should work as well as - and be a lot clearer than - my idea of > making the texture a compound asset. Well, we would have compound assets. An SL object would be a list of prims, with references to textures, scripts and whatnot that are stored as separate assets. > > We have the case of objects being actively edited. "Editing" could > > mean > > a script modifying the object. > > I think LL are ahead of this one: scripts can't modify assets. Well, I'm proposing humans shouldn't be able to either. Copy on write. :) > > We should perhaps think of the Asset > > Domain as long term storage. Objects being actively edited live in > > mutable, ethereal anonymous state, that exists only in the Region > > domain. To be accessible outside that region, it must be "baked" and > > passed into the Asset domain. > > I think the "instance" needs to be a long term object, as well. If > you edit a texture in your inventory, change its properties, its > identifier shouldn't change. Which properties? Either you're creating a new global asset, or you're editing instance properties. You'll have to be more specific. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071006/9197832a/attachment.pgp From ac251404 at ohio.edu Sat Oct 6 18:24:46 2007 From: ac251404 at ohio.edu (Alex Ciarlillo) Date: Sat Oct 6 18:25:07 2007 Subject: [sldev] Trying to create a menu entry/dialog Message-ID: <4708355E.9040602@ohio.edu> I have programmed a dialog for the viewer and am trying to get it to open from a menu. I followed the 2 tutorials on the wiki: https://wiki.secondlife.com/wiki/Adding_a_dialog https://wiki.secondlife.com/wiki/Adding_a_menu_item I followed the first tut to the letter except for changing the names on the commit/button. For the second tutorial I followed pretty much everything except the last part where it has you add a line to the intialize_menu_actions() function. This appeared deprecated to me so I added the following to the initialize_menus() function: addMenu(new LLToolsSearch(), "Tools.Search"); The name of the class for the menus is LLToolSearch and it calls the show method of my dialog which is named LLFloaterSearch. When I compiled however I keep getting the following error: In function 'LLToolsSearch::handleEvent(LLPointer, LLSD const&)': undefined reference to 'LLFloaterSearch::show(void*)' I have checked and triple checked all my includes and they seem to be in order but I will list them - llviewermenu.cpp: "llfloatersearch.h" llfloatersearch.h: "llfloater.h" llfloatersearch.cpp: "llviewerprecompiledheaders.h", "llfloatersearch.h", "llvieweruictrlfactory.h" I am developing on Ubuntu 7.04 using scons. I have specified a build directory and when I looked in the newview folder of the partially completed build I noticed it had llfloatersearch.h but no .cpp or .o file. I have tried building from scratch as well and it does not work. This is the first time I have added my own source files to the viewer (llfloatersearch.h and .cpp) and am thinking I must be doing something wrong either in the compile command im using for SCons or in the linking. It is also possible that the wiki is dated enough that the instructions to not work. So does anyone have an idea of what the problem could be? Thanks, Alex C. From michael at michaelverdi.com Sat Oct 6 20:18:37 2007 From: michael at michaelverdi.com (Michael Verdi) Date: Sat Oct 6 20:18:39 2007 Subject: [sldev] Flycam bug In-Reply-To: <5eff6d3b0710061231w368ba633ka62771a65b88be05@mail.gmail.com> References: <94b4a6520710051051p5bdd9da1k21c92829b21038da@mail.gmail.com> <5eff6d3b0710061231w368ba633ka62771a65b88be05@mail.gmail.com> Message-ID: <94b4a6520710062018t3d7d9817nbae6cbcc8e1ffe24@mail.gmail.com> I didn't know about pjira but now I do (thanks). Posted here: http://jira.secondlife.com/browse/VWR-2679 - Michael On 10/6/07, Andre Roche wrote: > Very strange. Have you posted an issue to pjira about it? > > On 10/5/07, Michael Verdi wrote: > > I'm using the 3Dconnection Space Navigator as the flycam with Second > > Life 1.18.3.5 on Windows XP. I noticed that it works with SL in window > > mode but not in fullscreen. Also if you switch to full screen and back > > to window mode it won't work and the only way to get working again is > > to shut SL down (in window mode) and restart it. > > I verified this on two different machines with two different controllers. > > > > - Michael > > > > > > -- > > http://michaelverdi.com > > http://freevlog.org > > http://nscape.tv > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- http://michaelverdi.com http://freevlog.org http://nscape.tv From mark.burhop at gmail.com Sat Oct 6 20:24:54 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Sat Oct 6 20:24:56 2007 Subject: [sldev] Fire wall issues with new Architecture? Message-ID: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> One of the use cases I'm having trouble understanding with the new architecture is what the corporate or organzational avatar sees from behind a fire wall. Consider the digram from the wiki below: https://wiki.secondlife.com/wiki/Running_at_Home_and_Offline#The_grid_2008 If company XYZ has a region hosted behind its fire wall for research or internal use, will the avatar be able to move (teleport) to a public region? Or would the corporate user have to log out and log in again with a "public" avatar? It would be better for avatars to be able to move between public and private (behind the firewall) space just as most of us do today when we access internal and external web pages. However, I imagine supporting this could create some problem with where assets are stored. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071006/08f136be/attachment-0001.htm From lenglish5 at cox.net Sat Oct 6 20:41:13 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 20:41:14 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <47062EF7.2000507@lindenlab.com> References: <4705CEE1.1050802@gmail.com> <47062EF7.2000507@lindenlab.com> Message-ID: <47085559.2010703@cox.net> Kent Quirk (Q Linden) wrote: > Jason: > > I don't (yet) know the answers to your questions, but I can tell you > that starting next week, I'm going to be working on a project (along > with a couple of other people) called "User Interface Cleanup" that > includes, among other things, a reworking of the way we handle > callbacks and a reorganization of XUI. We expect to spend most of the > next quarter on it. > > SL grew a bit more organically than any of us would like -- but now > we're trying to apply some good engineering principles. So hang in > there and we'll keep you posted. > > Q I'm abot half done with my faux outline panel for keywords. Steve Indicated that it would be a while before a generic outline/folder panel would be ready so I'm rolling my own, as best I cant, without rewriting any of the existing classes. Can I suggest a long-term project of "rewrite the GUI from scratch?" I know that some want to just get rid of the GUI, and, for "plain vanilla" clients, any old GUI could easily be used for most/all SL-related purposes. However, there's plenty of potential for a well designed GUI that was designed with Second LIfe in mind, so I'd rather see a core GUI requirement for SL that any modren GUI framework could handle, PLUS optional features, that would require either a seriously tweaked regular GUI, or a GUI designed from the ground up for that purpose. I've mentioned a few possibilities in http://wiki.secondlife.com/wiki/Use_Cases#Extended_Capability_Clients and I'm sure there are countless other capabilities that would require an SL-oriented GUI to take full advantage of. L. From lenglish5 at cox.net Sat Oct 6 20:47:44 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 20:47:45 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <47062EF7.2000507@lindenlab.com> References: <4705CEE1.1050802@gmail.com> <47062EF7.2000507@lindenlab.com> Message-ID: <470856E0.2080704@cox.net> Kent Quirk (Q Linden) wrote: > Jason: > > I don't (yet) know the answers to your questions, but I can tell you > that starting next week, I'm going to be working on a project (along > with a couple of other people) called "User Interface Cleanup" that > includes, among other things, a reworking of the way we handle > callbacks and a reorganization of XUI. We expect to spend most of the > next quarter on it. > > SL grew a bit more organically than any of us would like -- but now > we're trying to apply some good engineering principles. So hang in > there and we'll keep you posted. In the long run (probably doesn't apply to the cleanup project), it would be good for everyone to keep in mind the consensus of the open source community appears to be that the GUI should be at least as scriptable as WOW. In the very long run, the GUI and viewer library could be closely or loosely coupled depending on what capabilities are desired, and a client might consist of zero or more camera views of the SL interacting with a GUI that is merely a set of elements controlled by a script that interacts with the viewer library. L. From secret.argent at gmail.com Sat Oct 6 21:29:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 21:29:18 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <5eff6d3b0710061625g31bc8ccfo43b3e3bd542730e5@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <5eff6d3b0710061625g31bc8ccfo43b3e3bd542730e5@mail.gmail.com> Message-ID: On 06-Oct-2007, at 18:25, Andre Roche wrote: >> I think the "instance" needs to be a long term object, as well. If >> you edit a texture in your inventory, change its properties, its >> identifier shouldn't change. > So in a multisource system where I call for an asset by it's ID > What permissions will it have when I recieve it? Using Callum's terminology, you should get an instance of that asset, I think. That instance should be filled out by the source, using whatever policy it has... it may be a "master" instance that domain maintains, or it may be filled in with the local domain info. When you request that asset again, you should get the same instance (it's cached). > Aside from that, do we even have a definition of what an asset is, > or can be? I think we're trying to work that out now. > Right now, we have a defined list of asset types. Texture, Gesture, > Clothing, etc. For an extensible architecture, in a world where SL is > a common thing, it needs to be versatile. How about, at the highest level: An asset is some kind of static data, with a MIME type indicating what the asset type is (image/jpeg2000, application/x-llNotecard), plus some instance properties that are inherited by copies. A copy of an asset contains a reference to and possibly a cached copy of the static data and a copy of the properties at the time. Compound assets, like gestures and clothes, have a set of properties including the static assets they're based on, along with references to any locally cached copies of those assets. Raw static assets are transferred as the identifier, the mime type and an efficiently compressed blob. Instances are transferred as an encoded serialized form of the asset along with, if requested, copies of any required data. Conceptually like DNS, with back references and request types that can pull in more or less data. In practice, something like compressed XML followed by counted blocks containing blobs (since images and the like are generally already compressed). From secret.argent at gmail.com Sat Oct 6 21:37:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 21:37:26 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191713659.26663.169.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> <1191713659.26663.169.camel@localhost> Message-ID: On 06-Oct-2007, at 18:34, Callum Lerwick wrote: > I thought we were agreeing that permissions are part of an asset > instance. :) OK. > Description is a bit less clear cut. An asset creator would > probably want to be able to set a name and a description that is > part of > the asset, thus part of its identity. You would then be unable to edit > that description without ending up with a new asset. In SL the description and name can be changed if the asset is not read-only. Permissions are informational only. In this case they mean "if you change this, it will get reset if you return this asset to this domain". > Well, we would have compound assets. An SL object would be a list of > prims, with references to textures, scripts and whatnot that are > stored > as separate assets. Yah, I mean we don't need to make ALL assets compound assets. And prims are kind of a special case. A prim is a container, a linkset a two-level tree. The prim itself is a compoint asset in that it has references to textures (at least) as properties of the prim itself, the assets inside it are references in the local domain, but probably need to be fetched recursively or even completely serialized for transfers. >> I think the "instance" needs to be a long term object, as well. If >> you edit a texture in your inventory, change its properties, its >> identifier shouldn't change. > Which properties? Either you're creating a new global asset, or you're > editing instance properties. You'll have to be more specific. If you edit instance properties of the asset inside your inventory, the id you get when you ask for its UUID should not change, and that instance should still be what you get when you ask for that asset within the domain (say, rendering a prim you textured through that instance of that asset). So within your local domain (say, within second life... it's a domain in this context) the "instance" in your inventory is stored in an asset server (it may be called an agent server or an inventory server, but it answers asset server queries). Damn, I can't see how to make that clearer. Am I making sense? From secret.argent at gmail.com Sat Oct 6 21:41:11 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 21:41:03 2007 Subject: [sldev] Fire wall issues with new Architecture? In-Reply-To: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> References: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> Message-ID: <8E42A79F-9FBC-4714-BC20-673BB8CB42FE@gmail.com> On 06-Oct-2007, at 22:24, Mark Burhop wrote: > If company XYZ has a region hosted behind its fire wall for > research or internal use, will the avatar be able to move > (teleport) to a public region? Or would the corporate user have to > log out and log in again with a "public" avatar? Since the architecture is early... how SHOULD it work? That should depend on where the avatar is known, I think. If the avatar has a global identity it should be able to leave the region, but when it does it will only have access to assets that are available globally. You'd likely have a few missing image incidents until you remember to change into a public suit before going out. This is another reason that the identifier of an asset shouldn't be the same as the storage location of the local copy (or cached copy). From secret.argent at gmail.com Sat Oct 6 21:51:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 21:51:17 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <470856E0.2080704@cox.net> References: <4705CEE1.1050802@gmail.com> <47062EF7.2000507@lindenlab.com> <470856E0.2080704@cox.net> Message-ID: <7D536B36-C660-4AAF-B6FC-691598811FF2@gmail.com> On 06-Oct-2007, at 22:47, Lawson English wrote: > In the long run (probably doesn't apply to the cleanup project), it > would be good for everyone to keep in mind the consensus of the > open source community appears to be that the GUI should be at least > as scriptable as WOW. It might be worthwhile making the "new" GUI implement the Tk API (or even be a GL-aware version of Tk), because there's bindings for the Tk API for pretty much every major scripting language out there, and at the same time Tk is a relatively small and simple API. From lenglish5 at cox.net Sat Oct 6 21:58:18 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 21:58:20 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <7D536B36-C660-4AAF-B6FC-691598811FF2@gmail.com> References: <4705CEE1.1050802@gmail.com> <47062EF7.2000507@lindenlab.com> <470856E0.2080704@cox.net> <7D536B36-C660-4AAF-B6FC-691598811FF2@gmail.com> Message-ID: <4708676A.3040303@cox.net> Argent Stonecutter wrote: > On 06-Oct-2007, at 22:47, Lawson English wrote: >> In the long run (probably doesn't apply to the cleanup project), it >> would be good for everyone to keep in mind the consensus of the open >> source community appears to be that the GUI should be at least as >> scriptable as WOW. > > It might be worthwhile making the "new" GUI implement the Tk API (or > even be a GL-aware version of Tk), because there's bindings for the Tk > API for pretty much every major scripting language out there, and at > the same time Tk is a relatively small and simple API. > I'm all in favor of KISS. However, for the very long-run, I'd like to keep dynamic skinning options open that are OGL dependent. Any GUI that can be modified to handle Windlight-type settings would do for the extended viewer case. Which, if any, is "best " for that is open to much debate. A LUA-scripted client (or Python or Perl or Ruby or whatever) could make use of whatever GUI is best suited for that client's needs. L From seg at haxxed.com Sat Oct 6 22:03:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Oct 6 22:04:12 2007 Subject: [sldev] Fire wall issues with new Architecture? In-Reply-To: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> References: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> Message-ID: <1191733389.23363.21.camel@localhost.localdomain> On Sat, 2007-10-06 at 22:24 -0500, Mark Burhop wrote: > One of the use cases I'm having trouble understanding with the new > architecture is what the corporate or organzational avatar sees from > behind a fire wall. Consider the digram from the wiki below: > > https://wiki.secondlife.com/wiki/Running_at_Home_and_Offline#The_grid_2008 > > If company XYZ has a region hosted behind its fire wall for research > or internal use, will the avatar be able to move (teleport) to a > public region? Or would the corporate user have to log out and log in > again with a "public" avatar? Well, this would be a matter of policy. There's a big discussion lurking here over just what *is* an avatar anyway? If we abstract it away from an identity (multiple avatars per identity) and abstract it from an inventory, (one inventory shared among avatars. Possibly shared among identities.) what is left? Just an instance of an asset that happens to be of the "avatar" type? What is an identity? Etc... :) > It would be better for avatars to be able to move between public and > private (behind the firewall) space just as most of us do today when > we access internal and external web pages. However, I imagine > supporting this could create some problem with where assets are > stored. It would be up to the IT department to set up a policy, and poke holes in the corporate firewall to allow this to happen. If they even want it to happen. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071007/95c2ac9f/attachment-0001.pgp From lenglish5 at cox.net Sat Oct 6 22:06:48 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Oct 6 22:06:50 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <5eff6d3b0710061625g31bc8ccfo43b3e3bd542730e5@mail.gmail.com> Message-ID: <47086968.8090409@cox.net> Argent Stonecutter wrote: > On 06-Oct-2007, at 18:25, Andre Roche wrote: >>> I think the "instance" needs to be a long term object, as well. If >>> you edit a texture in your inventory, change its properties, its >>> identifier shouldn't change. > >> So in a multisource system where I call for an asset by it's ID >> What permissions will it have when I recieve it? > > Using Callum's terminology, you should get an instance of that asset, > I think. That instance should be filled out by the source, using > whatever policy it has... it may be a "master" instance that domain > maintains, or it may be filled in with the local domain info. When you > request that asset again, you should get the same instance (it's cached). > >> Aside from that, do we even have a definition of what an asset is, or >> can be? > > I think we're trying to work that out now. > >> Right now, we have a defined list of asset types. Texture, Gesture, >> Clothing, etc. For an extensible architecture, in a world where SL is >> a common thing, it needs to be versatile. > > How about, at the highest level: > > An asset is some kind of static data, with a MIME type indicating what > the asset type is (image/jpeg2000, application/x-llNotecard), plus > some instance properties that are inherited by copies. A copy of an > asset contains a reference to and possibly a cached copy of the static > data and a copy of the properties at the time. Compound assets, like > gestures and clothes, have a set of properties including the static > assets they're based on, along with references to any locally cached > copies of those assets. > > Raw static assets are transferred as the identifier, the mime type and > an efficiently compressed blob. Instances are transferred as an > encoded serialized form of the asset along with, if requested, copies > of any required data. Conceptually like DNS, with back references and > request types that can pull in more or less data. In practice, > something like compressed XML followed by counted blocks containing > blobs (since images and the like are generally already compressed). > Zha and I went around on this. From her high-level perspective, an asset is something that exists in a server outside the client, but that the client might get a reference of for some reason. A proto-asset would be some kind of information that no asset server knows about, that might someday, somehow be transformed/copied into an asset. There might be other kinds of data that exist client-side that wouldn't even be proto-asset in nature but you might still want to be displayed in the same list that an asset reference or proto-asset reference appears in (a proto-asset reference might be to a local texture file, or to a file accessable via ftp, etc). L From kamilion at gmail.com Sat Oct 6 22:13:26 2007 From: kamilion at gmail.com (Kamilion) Date: Sat Oct 6 22:13:29 2007 Subject: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution Message-ID: I've been doing some surfing on OpenID, and found out a lot about it. The first two links I have to share: http://video.google.com/videoplay?docid=-7463164786703060643 How to Use OpenID http://video.google.com/videoplay?docid=-3812012811402026027 The Future of OpenID These are both videos by Simon Willison. The first is ~5 minutes, the second is ~35 minutes. They give a good overview of OpenID as a system. What I've learned from all this stuff: OpenID is an open authentication solution: You go to a site that supports OpenID. You type in your OpenID Authentication URL. (Mine is http://Kamilion.myopenid.com ) It redirects you to your provider's page, in this case, myopenid.com. You log in there, somehow. MyOpenID asks you which "persona" you want to share with a site. I have two, one with my SL name as my realname, and another with my real realname and birthdate and email and timezone and postal code. I select my Default persona. (Kamilion Schnook) OpenID then redirects you back to the site you were originally at. Now, the real neat thing about OpenID is that authentication is completely handed off to the provider, which allows the user to choose their authentication scheme. For instance, Simon Willison runs idproxy.net, which allows you to use a Yahoo! account as an OpenID. Yahoo does not support OpenID directly, but they do have their own Authentication API, which idproxy uses to translate into OpenID. It's likely Google won't be far behind. But even if Google doesn't bother with OpenID, Their Authentication API is accessible as well, so it wouldn't surprise me to see a googleidproxy spring up. AOL already supports OpenID, using http://openid.aol.com/screename Livejournal also supports OpenID, using http://username.livejournal.com MyOpenID is the provider I'm currently using, which I found by watching the videos linked above. They allow authentication in multiple ways: Username/Password SSL Client Certificates And any OpenID provider can code any authentication system they wish, even going so far as to use the RSA tokens Paypal and Entropia Online use. That's all on the provider side. The site requesting the data has no access to any of that, it just gets a true or false that the person is authenticated or not, and then requests any data it wants to know from the OpenID profile that you've selected to share with the site. The first OpenID supporting site I took a look at was Jyte.com. Jyte allows people to state Claims. For instance, I might Claim that Kamilion Schnook is the owner of Sllabs.com. People can then look up sllabs.com and see that Kamilion Schnook is the owner of it. Then they would either Agree, or Disagree. It also allows groups. Groups can also make claims. But it's also another powerful OpenID feature: Whitelist transfers. Say you're Bob.livejournal.com. On livejournal, you have three friends, Carol, Ann, and Todd. By adding them to your whitelise, when you go to digg.com, OpenID knows that carol.livejournal.com and todd.livejournal.com have been there, and can automatically add them to your Digg friends list, and spread that trust network. Almost like a more secure version of Seven degrees of Kevin Bacon. I've created a public group on Jyte, called Second Life. It's free to join for anyone with an OpenID, from anywhere. Now, using the OpenID API, I can ask jyte things on my site's behalf. For instance, let's say I wanted a list of every member in that group: http://jyte.com/api/group/second_life/roster will return a newline separated list of members. Okay, now I have a list of members. That's cool, but what can you do with stuff like this? I'm writing a ruby on rails application now. It will support OpenID, because rails makes it easy! But it will also support things like Jyte groups. So I can do neat things now. http://jyte.com/api/group/second_life/is_member?openid=URLENCODE(kamilion.myopenid.com) returns text 'true' or 'false'. I can have rails ask jyte if "kamilion.myopenid.com" is part of the group second_life. I am a member, so it returns "true". So if I wanted an easy hack on 'Group Roles' on my rails application, it's as easy as creating some user groups invite only on jyte and asking jyte if someone is a member of a role when they do something like access the Administrator page(s) instead of coding all of that myself, likely insecurely. When combined with Personas, which are basically an OpenID AltAccount from the same OpenID AuthURL. For instance, I could login at my OpenID Provider and be given a list of Personas to choose. Say I'm using SL's OpenID system, and I have two accounts, Kamilion Schnook and SLLabs Backer. Both of them would be set up as Personas. To login to SL, instead of a username and password, I would input my OpenID URL, http://www.sllabs.com/kamilion/ and llmozlib would be redirected to the OpenID login, which is set up to automatically log me in with a client certificate. I would then be presented with the Persona list, and choose SLLabs Backer, and then click Allow Once. If I wanted, I could also select Allow Always. I would then be logged into SL as SLLabs Backer, without ever leaving the SL client. Same goes for logging into the website or the forums, I just provide my OpenID URL, then choose a persona. Since OpenID can exchange information about a person, and you select what information you want to provide through your provider, you can do very powerful things. If Linden Labs were to use OpenID as an authentication mechanism, they would likely need to meet the following: 1> Be an OpenID consumer. (Allow OpenIDs from other providers.) 2> Be an OpenID Provider. (Accept OpenID Requests from others.) 3> Be an OpenID Proxy. (Login to a LLOpenID from an outside OpenID and return extended data.) Now, the extended data that should be available from an LLOpenID: 1> SLFirstname 2> SLLastname 3> SLAgentKey 4> SLIsOnline 5> SLBornDate 6> SLPaymentInfoOnFile 7> SLPartner(?) Same public info as an avatar profile in SL. With this, it would be possible to be a complete SL newbie: Sign up for SL. Get an OpenID with an SL account. Take that OpenID URL to slexchange.com, and attempt to login there. You're redirected to openid.secondlife.com, which asks you to log in, then asks you which persona, then asks to confirm what data on file you want to share with slexchange.com. In this case, SLExchange wants to know your email address, SL first, last, key, and isonline. SLExchange now knows the person's key (like using a SLex terminal to associate an SLExchange account with a Second Life account) and the person adds L$100. They then go and purchase an item for L$100, and since SLExchange already has their key and knows they are currently online, the item is immediately delivered. The only thing the user did to SLExchange was give their OpenID URL. No signup form with the same questions over and over again, no email link activation. >From what I've seen from OpenID already, it seems it meets most of what the people are clamoring about. SSL Certificates are already supported. Alt accounts are Personas. To sum up: OpenID for Second Life Yes, you can pick your alt (Personas are an integral feature of OpenID, handled by the provider) Yes, it's all done within the SL Client (No need to open an external browser) Yes, it does support AJAX (for great justice) Yes, crypto is mandatory (No more plaintext passwords buzzing over the wire) Yes, you can use SSL Certificates (Firefox/Mozilla support this, so llmozlib likely does too) Yes, it's already widely used and mostly trusted. (AOL, Digg, Six Apart, livejournal) Right now, there's only one really major nagging issue: Is llmozlib up to the task? At the current point in time, I think it could use some work. Proxy support NEEDS to work. That is the most pressing issue. Other than that, it will work fine. SSL has already been working for a while now (Tested by any https:// link with a valid server certificate in the Web Profile section.) The only change users will notice, is instead of a login/password box, there is an OpenID URL box. I would suggest a dropdown text box that remembers OpenID URLs. Anyway, that's a pretty lengthly overview of OpenID from a n00b. I hope this has interested more people in this solution once the questions about it are answered. Comments? From secret.argent at gmail.com Sat Oct 6 22:59:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Oct 6 22:59:06 2007 Subject: [sldev] Fire wall issues with new Architecture? In-Reply-To: <1191733389.23363.21.camel@localhost.localdomain> References: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> <1191733389.23363.21.camel@localhost.localdomain> Message-ID: On 07-Oct-2007, at 00:03, Callum Lerwick wrote: > There's a big discussion lurking here over just what *is* an avatar > anyway? An avatar is how an agent presents in a region. An agent is a set of resources associated with a connection to a grid. From gigstaggart at gmail.com Sat Oct 6 23:14:54 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Oct 6 23:14:52 2007 Subject: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution In-Reply-To: References: Message-ID: <4708795E.9090902@gmail.com> Kamilion wrote: > I've been doing some surfing on OpenID, and found out a lot about it. So I set up gigstaggart.com/openid as my own provider. I claim to be Bill Clinton. Second Life has no way of knowing I'm not Bill Clinton, since my provider (me) doesn't do any strong authentication of who I am. Replace Bill Clinton with "over 18", if you want the age verification angle. Basically, OpenID is only as strong as the provider in terms of real authentication. The only OpenID provider that would be acceptable for Second Life would be Linden Lab. Back to square 1. -Jason From kamilion at gmail.com Sun Oct 7 00:49:20 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Oct 7 00:49:24 2007 Subject: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution In-Reply-To: <4708795E.9090902@gmail.com> References: <4708795E.9090902@gmail.com> Message-ID: On 10/6/07, Jason Giglio wrote: > Kamilion wrote: > > I've been doing some surfing on OpenID, and found out a lot about it. > > So I set up gigstaggart.com/openid as my own provider. I claim to be > Bill Clinton. Second Life has no way of knowing I'm not Bill Clinton, > since my provider (me) doesn't do any strong authentication of who I am. A OpenID provider is only responsible for proving identity, not trust. > Replace Bill Clinton with "over 18", if you want the age verification angle. No, but LL's provider & data storage should tie this in with the age verification so that other OpenID consumers being authenticated against LLOpenID get a IsAnAdult bool. Of course, in doing this, it also opens up other problems: Little 16 year old Bobby Jr could borrow Bobby Sr.'s ID once, AgeVerify through SL, and leverage his SL account believing he is over 21 to other sites by using his LLOpenID externally. > Basically, OpenID is only as strong as the provider in terms of real > authentication. The only OpenID provider that would be acceptable for > Second Life would be Linden Lab. Back to square 1. Yes, exactly. The only OpenID provider that would be acceptable for Second Life would be Linden Lab. Hence the proxy OpenID support. You log in to the SL website. Somehow. Then while there, you add an existing OpenID by entering it's URL. It connects to your provider, which asks you to log in. You log into your Open ID Provider, and select a persona. That Persona now has access to the account. OpenID supports Delegation. For a given page to act as a OpenID provider, you only need to add two tags to your HTML source: If I added this to http://www.sllabs.com/kamilion/index.php, when I use http://www.sllabs.com/kamilion/ as an OpenID URL, it will be delegated to myopenid. Likewise, Linden Labs could allow you to delegate to another provider. Linden Labs is now no longer responsible for keeping a password for you; The authentication scheme is separate from the application but still tied to it. On 10/6/07, Argent Stonecutter wrote: > > Yes, you can pick your alt (Personas are an integral feature of > > OpenID, handled by the provider) > > *concurrently*? Using different OpenIDs? Without sharing any > information with anyone but Linden Labs? Even if I visit someone's > web page in their profile and it's on LiveJournal? Concurrently, yes. Every instance of login should bring you to the Persona selection. It's also possible to change personas on the fly. You're free to use as many OpenID providers, personas & URLs as you want. Most browsers will remember entries to webforums, so adding a OpenID URL box to the SL website simply allows you to dropdown a list of OpenIDs to authenticate against. > I don't *want* to have one ID that logs me into livejournal, > sixapart, and Second Life. I don't *want* the possibility of > someone's blog site having access to information about my SL > identity, through any possible chain of events. You're free to keep them seperate. Should you choose to use them like I've mentioned, you're free to do that as well. OpenID works fine as a chained system, and you can delegate and hand off through as many layers of security as you wish for your account. For instance, you may wish to use the Three-point authentication mechanism: Something you Have Something you Know Something you Are Something you Are refers to biometrics, in this case, a fingerprint from a fingerprint reader. Something you Know refers to a password or passphrase, in this case an AES-256 class passphrase. Something you Have refers to a hardware token, in this case the fingerprint reader with a specific serial number, UUID, or PKI/SSL certificate on Flash. Your provider is only proving identity, not trust. So, here is how a chained login would work: You go to SLExchange.com. You log in with your LLOpenID, say http://openid.secondlife.com/Stonecutter/Argent/ >From there, SLExchange redirects you to openid.secondlife.com. Openid.secondlife.com checks it's database and locates your provider on file there. Let's say that's http://argentstonecutter.com/ openid.secondlife.com redirects to the OpenID provider delegated at argentstonecutter.com. That OpenID is further delegated off to secretargent.myopenid.com. And that OpenID is delegated to a linux box running in your basement, locally networked to your PC that you can access only from your subnet, not the internet. That box talks to a shared USB fingerprint device with built in flash memory plugged into your desktop. You plug the USB fingerprint device in, and it's autorun opens up the SSL client key stored on the flash. You swipe your finger. It's correct. It supplies the passphrase to the SSL Client key. The SSL client key is decrypted, and used to authenticate to the linux box. The linux box decides you are who you say you are, and accepts the login. It sends it's default persona of Your Linux Box to secretargent.myopenid.com. You're now authenticated there. secretargent.myopenid.com then requests you to select a persona there. You choose your Non-Business persona, which then authenticates you against openid.secondlife.com through argentstonecutter.com, allowing you to select which persona you have associated with that SL account, which will then be passed to slexchange. You've just replaced your authentication with strong biometric verification. Ow, my fingers. That's a little bit of an extreme case. But it becomes possible. An OpenID is basically as strong and rooted or as weak and lonely as you want. All it allows you to do is defer authentication to a provider YOU choose to trust. If you choose to trust Google to be your primary provider, that's fine. Or Yahoo through idproxy.net. Or MyOpenID. Or LL. It ceases to matter, as long as YOU are convinced that they are properly managing your identity. If you stop trusting them, you can change providers. This is covered quite well in the 30 minute video I linked in the original email. Simon proposes that the creators of livejournal become evil. Hilarity ensues. In your case, you would use completely different OpenIDs for all the services. In ORDER for an OpenID to function, you MUST willfully give something the URL to your OpenID. If you go to Joe Schmoe's blog, just don't log with your LLOpenID. Use one of the links higher up the chain, with a different persona. Or a TypePad OpenID from your own blog. Or an AIM account with http://openid.aol.com/screenname Or a Yahoo account through idproxy.net. Anyway, OpenID allows you to be as paranoid as you want, as it's just a different way to store and verify a password. OpenID, Like SSH, uses strong crypto, including Diffie-Hellman key exchange, full end to end SSL, requiring verified SSL server certificates for domains involved, which is it's own little identity proving hoops to jump through, usually providing a StateID or passport ID to prove identity, and ownership of a domain. SSL protects us from man-in-the-middle attacks for the most part. Read the specifications... They even list how OpenID can protect against a couple of common attacks. Some known bad browser UserAgents can be barred from being used, for instance. http://openid.net/specs/openid-authentication-2_0-11.html From zha.ewry at gmail.com Sun Oct 7 00:58:16 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Sun Oct 7 00:58:17 2007 Subject: [sldev] Fire wall issues with new Architecture? In-Reply-To: References: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> <1191733389.23363.21.camel@localhost.localdomain> Message-ID: <920d7d850710070058pdc9068j4ebd48df8445b557@mail.gmail.com> You can model this several ways. IT departments will end up making choices. The sane model, in many ways, would have the corporate data in corporate asset servers, behind firewalls, and some sims there as well. These would have full access to assets in corporate space, and assuming they allow the sims in corporate space to reach out to the public asset servers, access to public ones as well. Depending on where you place an agent domain, and whether you allow agents to log on to separate ones, at different times, you get somewhat different permutations As a designer, my intent is to make sure we design for all the possible cases, and then let the real world decide which ones succeed. I think that the mixed models, where private space still deeply shares assets and avatars with public space is best, but other people will have other opinions. HTTP/HTML works well across inter and intra nets, with any permutations of deployment. 3d internet web wide, should as well. - Zha On 10/7/07, Argent Stonecutter wrote: > > On 07-Oct-2007, at 00:03, Callum Lerwick wrote: > > There's a big discussion lurking here over just what *is* an avatar > > anyway? > > An avatar is how an agent presents in a region. > > An agent is a set of resources associated with a connection to a grid. > > _______________________________________________ > 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/20071007/d541b12e/attachment.htm From kamilion at gmail.com Sun Oct 7 01:12:07 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Oct 7 01:12:11 2007 Subject: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution In-Reply-To: References: <4708795E.9090902@gmail.com> Message-ID: Oh, and I forgot -- something else I saw someone mention in the earlier discussions. A login log. This is standard at myopenid.com. Recent Events When IP Address Event 2 minutes ago 24.6.134.7 Approve for http://*.zooomr.com/ 2 minutes ago 24.6.134.7 AuthorizeOnce for http://*.zooomr.com/ 3 minutes ago 24.6.134.7 Sign in by certificate:B131 4 minute ago 24.6.134.7 Failed password sign-in attempt 4 minute ago 24.6.134.7 Signed out 4 minutes ago 24.6.134.7 Disapprove for http://*.zooomr.com/ 5 minutes ago 24.6.134.7 Approve for http://*.zooomr.com/ 5 minutes ago 24.6.134.7 AuthorizeOnce for http://*.zooomr.com/ 5 minutes ago 24.6.134.7 Disapprove for http://*.zooomr.com/ 36 minutes ago 24.6.134.7 Approve for http://jyte.com/ 36 minutes ago 24.6.134.7 Sign in by certificate:B131 38 minutes ago 24.6.134.7 Approve for http://www.livejournal.com/ 38 minutes ago 24.6.134.7 Authorize for http://www.livejournal.com/ 47 minutes ago 24.6.134.7 Authorize for http://slopenid.net From matthew.dowd at hotmail.co.uk Sun Oct 7 01:36:36 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Oct 7 01:36:38 2007 Subject: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution In-Reply-To: <4708795E.9090902@gmail.com> References: <4708795E.9090902@gmail.com> Message-ID: I've already covered this scenario in other posts to the list. There is a lot of work on brokered id validation, which could use OpenID or similar as the foundation piece. A feature an OpenID provider can do is to provide an attribute look up service (similar to Shibolleth), so that SL (or others) can send back queries such as Age, Over18Status, Address. You can control how much or how little is revealed to a particular provider (so SL may be able to ask Over18Status but not Age; your web service provider may be able to ask for MobilePhoneNumber etc.) It terms of validating - this is done by third party brokers - so your bank may sign the Age and Over18Status properties (using certificates or similar) - there is some industry interest in providing such services. This validation is therefore completely independent of who the OpenID provider is. If this gets off the ground, on LL's side, it becomes a case of which identity providers they are willing to trust (say some major league banks). On the users side, LL gets to access *only* the information they need (i.e. Over18Status), whilst all the supporting information for this only needs to go to someone who trust or have already trusted with this information (e.g. your bank). In essence this is a digital automated equivalent of a notary signing a "this person is over eighteen" statement... Yes - there is still a lot of work outstanding on the above, and it will only fly if there's enough momentum behind it, but this is a direction that is attracting a lot of interest in the online verification debate. Matthew > Date: Sun, 7 Oct 2007 02:14:54 -0400> From: gigstaggart@gmail.com> To: kamilion@gmail.com; sldev@lists.secondlife.com> Subject: Re: [sldev] [Auth] [OpenID] OpenID as SL Authentication Solution> > Kamilion wrote:> > I've been doing some surfing on OpenID, and found out a lot about it.> > So I set up gigstaggart.com/openid as my own provider. I claim to be > Bill Clinton. Second Life has no way of knowing I'm not Bill Clinton, > since my provider (me) doesn't do any strong authentication of who I am.> > Replace Bill Clinton with "over 18", if you want the age verification angle.> > Basically, OpenID is only as strong as the provider in terms of real > authentication. The only OpenID provider that would be acceptable for > Second Life would be Linden Lab. Back to square 1.> > -Jason> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/91e47716/attachment.htm From matthew.dowd at hotmail.co.uk Sun Oct 7 05:10:21 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Oct 7 05:10:24 2007 Subject: [sldev] Populating the Resident Chooser dialog with people within chat distance In-Reply-To: References: <4708795E.9090902@gmail.com> Message-ID: There's been enough discussion on this that I thought I'd just go ahead and implement this. Patch at http://jira.secondlife.com/browse/VWR-2681 Matthew _________________________________________________________________ Feel like a local wherever you go. http://www.backofmyhand.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/e952c727/attachment.htm From dzonatas at dzonux.net Sun Oct 7 07:38:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Oct 7 07:36:22 2007 Subject: [sldev] [Auth] [OpenID] OpenID and AWG In-Reply-To: References: <4708795E.9090902@gmail.com> Message-ID: <4708EF6A.1000408@dzonux.net> Should AWG focus on this first as discussion? After I read that long long wiki log...hmmm..., I think this is something that can be tackled easier and have more of an immediate impact. Matthew Dowd wrote: > I've already covered this scenario in other posts to the list. > > There is a lot of work on brokered id validation, which could use > OpenID or similar as the foundation piece. > > A feature an OpenID provider can do is to provide an attribute look up > service (similar to Shibolleth), so that SL (or others) can send back > queries such as Age, Over18Status, Address. > > You can control how much or how little is revealed to a particular > provider (so SL may be able to ask Over18Status but not Age; your web > service provider may be able to ask for MobilePhoneNumber etc.) > > It terms of validating - this is done by third party brokers - so your > bank may sign the Age and Over18Status properties (using certificates > or similar) - there is some industry interest in providing such services. > > This validation is therefore completely independent of who the OpenID > provider is. > > If this gets off the ground, on LL's side, it becomes a case of which > identity providers they are willing to trust (say some major league > banks). > > On the users side, LL gets to access *only* the information they need > (i.e. Over18Status), whilst all the supporting information for this > only needs to go to someone who trust or have already trusted with > this information (e.g. your bank). In essence this is a digital > automated equivalent of a notary signing a "this person is over > eighteen" statement... > > Yes - there is still a lot of work outstanding on the above, and it > will only fly if there's enough momentum behind it, but this is a > direction that is attracting a lot of interest in the online > verification debate. > > Matthew > > > > > Date: Sun, 7 Oct 2007 02:14:54 -0400 > > From: gigstaggart@gmail.com > > To: kamilion@gmail.com; sldev@lists.secondlife.com > > Subject: Re: [sldev] [Auth] [OpenID] OpenID as SL Authentication > Solution > > > > Kamilion wrote: > > > I've been doing some surfing on OpenID, and found out a lot about it. > > > > So I set up gigstaggart.com/openid as my own provider. I claim to be > > Bill Clinton. Second Life has no way of knowing I'm not Bill Clinton, > > since my provider (me) doesn't do any strong authentication of who I am. > > > > Replace Bill Clinton with "over 18", if you want the age > verification angle. > > > > Basically, OpenID is only as strong as the provider in terms of real > > authentication. The only OpenID provider that would be acceptable for > > Second Life would be Linden Lab. Back to square 1. > > > > -Jason > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > Get free emoticon packs and customisation from Windows Live. Pimp My > Live! > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/25a7a8a9/attachment-0001.htm From dzonatas at dzonux.net Sun Oct 7 07:41:11 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Oct 7 07:38:51 2007 Subject: [sldev] Populating the Resident Chooser dialog with people within chat distance In-Reply-To: References: <4708795E.9090902@gmail.com> Message-ID: <4708F007.3020109@dzonux.net> Woot! freak'n awesome! Matthew Dowd wrote: > > There's been enough discussion on this that I thought I'd just go > ahead and implement this. > > Patch at http://jira.secondlife.com/browse/VWR-2681 > > Matthew > > > > > ------------------------------------------------------------------------ > Do you know a place like the back of your hand? Share local knowledge > with BackOfMyHand.com > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/7add7fae/attachment.htm From james at lindenlab.com Sun Oct 7 09:39:46 2007 From: james at lindenlab.com (James Cook) Date: Sun Oct 7 09:38:38 2007 Subject: [sldev] Trying to create a menu entry/dialog In-Reply-To: <4708355E.9040602@ohio.edu> References: <4708355E.9040602@ohio.edu> Message-ID: <47090BD2.80307@lindenlab.com> > https://wiki.secondlife.com/wiki/Adding_a_dialog > https://wiki.secondlife.com/wiki/Adding_a_menu_item I wrote those, so I'm happy someone else is following them! I'll patch them up with any comments you have. > I followed the first tut to the letter except for changing the names on > the commit/button. For the second tutorial I followed pretty much > everything except the last part where it has you add a line to the > intialize_menu_actions() function. This appeared deprecated to me so I > added the following to the initialize_menus() function: > > addMenu(new LLToolsSearch(), "Tools.Search"); You're right. It looks like someone changed this -- I'll patch the wiki. > In function 'LLToolsSearch::handleEvent(LLPointer, LLSD const&)': > undefined reference to 'LLFloaterSearch::show(void*)' This sounds to me like the .cpp files isn't getting built. Is llfloatersearch.cpp added in "files.lst"? That's the listing of all the files to build with the viewer. If not, add this: newview/llfloatersearch.cpp Hope this helps. James Software Engineer Linden Lab From lenglish5 at cox.net Sun Oct 7 09:53:03 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 09:53:04 2007 Subject: [sldev] [META][WEB] Platform-specific developer pages? Message-ID: <47090EEF.50807@cox.net> Someone recently started a Mac-specific SL developer group called "Second Mac." I've hunted around a bit and can't find any Mac-specific development page nor Linux/Windows-specific pages for that matter. I'm thinking of creating a platform-speciific page with pointers to a Mac specific page (WIndows and Linux users can add their own references). What would go on such an index page? Just references to the otehrs? How would it be referenced by the rest of the website? I'm not eve sure which category it should go in. L. From mark.burhop at gmail.com Sun Oct 7 12:14:21 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Sun Oct 7 12:14:23 2007 Subject: [sldev] Fire wall issues with new Architecture? In-Reply-To: <920d7d850710070058pdc9068j4ebd48df8445b557@mail.gmail.com> References: <773a33dc0710062024l11458697g9e2ce8674efc1a0@mail.gmail.com> <1191733389.23363.21.camel@localhost.localdomain> <920d7d850710070058pdc9068j4ebd48df8445b557@mail.gmail.com> Message-ID: <773a33dc0710071214g12f2ca0dg8fb1ba8a064f446b@mail.gmail.com> Thanks Zha and Argent.... So what I've done is docuemented a couple "firewall" related usecase on the Wiki http://wiki.secondlife.com/wiki/Firewall_Usecases The one-liners that exist today are ok for a start but something more in line line of Alistair Cockburn's templates seemed more useful. I also included a "wikified" cut-and-paste version of this if anyone is interested in the same format for other usecases: http://wiki.secondlife.com/wiki/Early_Stage_Usecase_Template If I receive postive feedback I'll try to document a few more of the "firewall" ones :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/746ca04b/attachment.htm From jessesa at gmail.com Sun Oct 7 12:15:43 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Sun Oct 7 12:15:45 2007 Subject: [sldev][Havoc ]New height limits Message-ID: I know there is soo much being worked on in Havoc 4 such as physical vehicles and flights assists which are wonky. It will continue to evole as we progress to a MG deployment. My question isn't dealing with the way physics act now but only about the new limits. The build height limit in Aditi has been raised from 768 meters to 1,024 meters. We used to be able to rez objects from 768 meters to 4,096 meters and that has now changed to a max height of 1,024 meters also. Are these new limits just an arbitrary number used for testing or is this what we are going to get in the MG? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/53a55d8f/attachment.htm From seg at haxxed.com Sun Oct 7 12:45:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Oct 7 12:46:28 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470811C4.10003@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> Message-ID: <1191786318.23363.86.camel@localhost.localdomain> On Sat, 2007-10-06 at 15:52 -0700, Lawson English wrote: > Again, where does the unpublished asset live? Is it simply not-an-asset? > This issue needs to be addressed because you can't reasonably do a > regexp search of all notecards in your inventory, letalone all notes > taken of all people you have ever met anywhere in the metaverse friend > or not, unless some private version of these exist client-side in a > format that is flagged as "searchable content". Why go creating > special-case flags when you can simply have a generic class of object > that doesn't require validation from some asset server before you can > gain access? Private content is never "stale" or invalid, since the > client itself has the only copy and no external asset server can even > know it exists until it is published (either as a copy of the original > or transformed into an external asset with no private copy leftover). > > My keyword floater can't use the LLInventory* classes to display > folder-style hierarchies because keywords aren't an asset, for a more > trivial example. > > For a more complex example, how does one deal with locally built assets, > such as avatars, prims, etc., that have never been published, even to a > private sim? > > An example of this would be prims (or avatar appearances) created/edited > via plug-ins with more complex interfaces than the rudimentary in-world > tools provide. Do we just say "let the plug-in writers worry about this" > or do we address the issue from the start and provide a generic > mechanism to allow manipulation of non-published stuff using the same > GUI as currently only handles published stuff? I'm really not understanding what you're saying here. You seem to be seeing grave complexity where there is none. Standard file formats are a given. The asset's local identity is a local implementation detail. It can be stored in a local file named "penisbike.slobj" or managed by a local asset manager in the same manner as other global assets. Or both. Remember, we're heading for a future where nontechnical users aren't going to know or care where their data actually is. All they know is they log in to Gmail and their email is there. They log in to Second Life and their inventory is there. (Or not there, as the case may be.) Local storage becomes nothing more than cache, and possibly a backup mirror. And unused disk space is wasted disk space... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071007/f13b859e/attachment.pgp From secret.argent at gmail.com Sun Oct 7 13:30:28 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Oct 7 13:30:26 2007 Subject: [sldev][Havoc ]New height limits In-Reply-To: References: Message-ID: On 07-Oct-2007, at 14:15, Jesse Barnett wrote: > We used to be able to rez objects from 768 meters to 4,096 meters > and that has now changed to a max height of 1,024 meters also. Gak, If that's going to be permanent I hope they also add better privacy controls, because I often work on platforms over the non- physical movement limit (up around 4k meters) to make it less likely for people to fly over and bug me when I'm concentrating. From zha.ewry at gmail.com Sun Oct 7 13:35:01 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Sun Oct 7 13:35:02 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191786318.23363.86.camel@localhost.localdomain> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> Message-ID: <920d7d850710071335w7530954dy43bb4f4f7bb0e78@mail.gmail.com> yeah verrily. We need to be clear. That which we make accessible via a AWG service is the bound of what we do. Many related things will manifest in code. This is fine but... out of scope. The insides of clients and services will rarely be our concern. - Zha On 10/7/07, Callum Lerwick wrote: > On Sat, 2007-10-06 at 15:52 -0700, Lawson English wrote: > > Again, where does the unpublished asset live? Is it simply not-an-asset? > > This issue needs to be addressed because you can't reasonably do a > > regexp search of all notecards in your inventory, letalone all notes > > taken of all people you have ever met anywhere in the metaverse friend > > or not, unless some private version of these exist client-side in a > > format that is flagged as "searchable content". Why go creating > > special-case flags when you can simply have a generic class of object > > that doesn't require validation from some asset server before you can > > gain access? Private content is never "stale" or invalid, since the > > client itself has the only copy and no external asset server can even > > know it exists until it is published (either as a copy of the original > > or transformed into an external asset with no private copy leftover). > > > > My keyword floater can't use the LLInventory* classes to display > > folder-style hierarchies because keywords aren't an asset, for a more > > trivial example. > > > > For a more complex example, how does one deal with locally built assets, > > such as avatars, prims, etc., that have never been published, even to a > > private sim? > > > > An example of this would be prims (or avatar appearances) created/edited > > via plug-ins with more complex interfaces than the rudimentary in-world > > tools provide. Do we just say "let the plug-in writers worry about this" > > or do we address the issue from the start and provide a generic > > mechanism to allow manipulation of non-published stuff using the same > > GUI as currently only handles published stuff? > > I'm really not understanding what you're saying here. You seem to be > seeing grave complexity where there is none. Standard file formats are a > given. The asset's local identity is a local implementation detail. It > can be stored in a local file named "penisbike.slobj" or managed by a > local asset manager in the same manner as other global assets. Or both. > > Remember, we're heading for a future where nontechnical users aren't > going to know or care where their data actually is. All they know is > they log in to Gmail and their email is there. They log in to Second > Life and their inventory is there. (Or not there, as the case may be.) > > Local storage becomes nothing more than cache, and possibly a backup > mirror. And unused disk space is wasted disk space... > From lenglish5 at cox.net Sun Oct 7 15:31:33 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 15:31:35 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <920d7d850710071335w7530954dy43bb4f4f7bb0e78@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <920d7d850710071335w7530954dy43bb4f4f7bb0e78@mail.gmail.com> Message-ID: <47095E45.9070906@cox.net> Zha Ewry wrote: > yeah verrily. We need to be clear. That which we make accessible via a > AWG service is the bound of what we do. Many related things will > manifest in code. This is fine but... out of scope. The insides of > clients and services will rarely be our concern. - Zha > The Lindens took this attitude as well, and that is why the client is a closed system that is impossible to extend. L. From lenglish5 at cox.net Sun Oct 7 15:49:13 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 15:49:17 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47095E45.9070906@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <920d7d850710071335w7530954dy43bb4f4f7bb0e78@mail.gmail.com> <47095E45.9070906@cox.net> Message-ID: <47096269.1090203@cox.net> Lawson English wrote: > Zha Ewry wrote: >> yeah verrily. We need to be clear. That which we make accessible via a >> AWG service is the bound of what we do. Many related things will >> manifest in code. This is fine but... out of scope. The insides of >> clients and services will rarely be our concern. - Zha >> > > The Lindens took this attitude as well, and that is why the client is > a closed system that is impossible to extend. > Or, to put it differently: "undefined" is fine as a category, but it has to be spelled out, rather than left as a dangling comma at the end of the list of definitions... L. From lenglish5 at cox.net Sun Oct 7 16:44:13 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 16:44:17 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191786318.23363.86.camel@localhost.localdomain> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> Message-ID: <47096F4D.20103@cox.net> Callum Lerwick wrote: [..] > I'm really not understanding what you're saying here. You seem to be > seeing grave complexity where there is none. Standard file formats are a > given. The asset's local identity is a local implementation detail. It > can be stored in a local file named "penisbike.slobj" or managed by a > local asset manager in the same manner as other global assets. Or both. > > Remember, we're heading for a future where nontechnical users aren't > going to know or care where their data actually is. All they know is > they log in to Gmail and their email is there. They log in to Second > Life and their inventory is there. (Or not there, as the case may be.) > > Local storage becomes nothing more than cache, and possibly a backup > mirror. And unused disk space is wasted disk space... > Well, that's the flipside of what Zha and I have been arguing about. I want to make sure we have "not an asset" defined. She thinks the definition isn't necessary, but I've been worrying that "not an asset" will mean to some people "doesn't exist." You seem to have proven me correct. I believe there can and likely SHOULD BE plenty of data associated with the client that doesn't live in an external asset server. If "not an asset" is defined as being "'unpublished' to the external world," where "external" includes 1-person sims, then plenty of data that the client might display will never be an asset or even a "proto-asset." But users will still want (or at least likely will still want) to be able to manipulate that data using the same general interface that is reserved only for assets in the current SL client. What that data is, or could be, is not defined, and I agree that discussing it in any detail it falls outside the purvue of designing the client-server architecture. BUT, we should keep in mind that some stuff that the user may see or want to see in the client, won't fit the protocols and not put up blinders when discussing what the client may or may not do. L. From zha.ewry at gmail.com Sun Oct 7 16:57:32 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Sun Oct 7 16:57:34 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47096F4D.20103@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> Message-ID: <920d7d850710071657p1c689fmd0fbf40a93c6b737@mail.gmail.com> Lawson and I chatted a fair bit about this in-world... I've two thoughts here. First, I'm just going to be brutally difficult about putting terms for things which don't show up as parts of the flows and services we define in the AWG. But... and listening to why, and how Lawson got to these issues, helped me a lot, in terms of explanatory need, we probably do need to think about the slightly larger, say eco-system, in which the architecture resides. In that world, which includes the clients, the tools, and things like backups of assets on people's private hard disks, there can, and should be terms for things like "asset under local construction" and "Freeze dried asset gorp ready to be turned into an asset" and "Cached Inventory handles" I'm totally ok with getting some good nomenclature into the eco-system, and I'm also pretty sure that a nice set of libraries, which had classes like "proto_asset" with constructors as such, and classes like "asset_service_proxy" with methods like "upload_proto_asset(proto_asset&,permissions_mask) Such clases wouldn't be within the scope of the architecture, ut they would be within the eco-system. - Zha On 10/7/07, Lawson English wrote: > > Callum Lerwick wrote: > [..] > > I'm really not understanding what you're saying here. You seem to be > > seeing grave complexity where there is none. Standard file formats are a > > given. The asset's local identity is a local implementation detail. It > > can be stored in a local file named "penisbike.slobj" or managed by a > > local asset manager in the same manner as other global assets. Or both. > > > > Remember, we're heading for a future where nontechnical users aren't > > going to know or care where their data actually is. All they know is > > they log in to Gmail and their email is there. They log in to Second > > Life and their inventory is there. (Or not there, as the case may be.) > > > > Local storage becomes nothing more than cache, and possibly a backup > > mirror. And unused disk space is wasted disk space... > > > Well, that's the flipside of what Zha and I have been arguing about. > > I want to make sure we have "not an asset" defined. She thinks the > definition isn't necessary, but I've been worrying that "not an asset" > will mean to some people "doesn't exist." You seem to have proven me > correct. > > > > > I believe there can and likely SHOULD BE plenty of data associated > with the client that doesn't live in an external asset server. If "not > an asset" is defined as being "'unpublished' to the external world," > where "external" includes 1-person sims, then plenty of data that the > client might display will never be an asset or even a "proto-asset." > > But users will still want (or at least likely will still want) to be > able to manipulate that data using the same general interface that is > reserved only for assets in the current SL client. > > What that data is, or could be, is not defined, and I agree that > discussing it in any detail it falls outside the purvue of designing the > client-server architecture. BUT, we should keep in mind that some stuff > that the user may see or want to see in the client, won't fit the > protocols and not put up blinders when discussing what the client may or > may not do. > > > > L. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/86d15904/attachment.htm From secret.argent at gmail.com Sun Oct 7 17:10:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Oct 7 17:10:49 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47096F4D.20103@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> Message-ID: On 07-Oct-2007, at 18:44, Lawson English wrote: > I believe there can and likely SHOULD BE plenty of data > associated with the client that doesn't live in an external asset > server. Can you distinguish between these two cases? * Data that does not live in an external asset server, but should be able to be stored there, such as local content that is being modified prior to uploading. * data that does not live in an external asset server because it is purely local to the client, such as user-interface layout files. Which are you talking about? From jhurliman at wsu.edu Sun Oct 7 18:14:29 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Oct 7 18:14:57 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> Message-ID: <47098475.9060100@wsu.edu> Argent Stonecutter wrote: > > On 06-Oct-2007, at 15:42, Callum Lerwick wrote: >> "Almost all programming can be viewed as an exercise in caching" > > Yah. Caching was the thing that immediately sprang to mind as a > problem with using a URL and making requests in real time. Resources > need to live "close" to where they're used. Assets are going to get > copied around. Assets referred to from in-world objects need to still > work even if the asset server from Joe's Bar and Grid is offline, so > they need to be cached. > >> For this to happen, we need a way to unambiguously >> identify an asset, completely independent of its location. A content >> hash is probably the best way to do this. Duplicate copies of an asset >> become obvious to identify, and likewise maliciously modified or >> corrupted copies of the asset can be identified and culled. > > What about assets with editable properties, like clothing, gestures, > notecards, and so on? I don't know if this has already been answered in the thread, but currently there is no such thing as an asset with editable properties. If you change a word in a notecard and save it, you are uploading a new asset to the grid. If you change the sleeve length of your shirt and save it, you are uploading a new wearable asset (and new temporary bakes for your final outfit). John Hurliman From lenglish5 at cox.net Sun Oct 7 20:34:56 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 20:34:58 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> Message-ID: <4709A560.6010703@cox.net> Argent Stonecutter wrote: > On 07-Oct-2007, at 18:44, Lawson English wrote: >> I believe there can and likely SHOULD BE plenty of data associated >> with the client that doesn't live in an external asset server. > > Can you distinguish between these two cases? > > * Data that does not live in an external asset server, but should be > able to be stored there, such as local content that is being modified > prior to uploading. > > * data that does not live in an external asset server because it is > purely local to the client, such as user-interface layout files. > > Which are you talking about? In my case, specifically, I'm talkign about the keywords/functions data for the floater I'm making. This obviously is never going to be published as an asset, but it still should "live" in the client. The issue I ran into that got me so incensed about this whole thing is that the folder class in the client is chained to the asset server. Anything "not an asset" can't be put into a folder. The classes themselves are so chained I can't derive a non-asset folder class from them without rewriting almost the entire class. This is a trivial example, but what about more interesting ones? I have perhaps 100 sample scripts in my inventory. There's no easy way to browse them save by name because they are assets. Why can't I have "proto" scripts that live in a folder that points to one or more xml files or to a database that only lives on my computer, but that I can still manipulate as a "first class" bit of data for every purpose EXCEPT dumping into some other inventory? (and translation mechanisms for most types of non-assets could still be automated ala the conventions that apple developed 24 years ago for the Mac clipboard and refined in the OpenDoc spec). What about the notes on friends/enemies/places of interest that everyone keeps? Those aren't sortable either. What about sculpty textures created with a client plug-in that aren't loaded to the asset server? And, in the world wide grid, what about assets that can't be used on one grid, but can be in another, that live in my inventory as "assets" even though they're not assets on the currently accessed grid? In principle, anything that a user can view inside the client, could become an asset, either as a notecard, or a screenshot-texture, but some things are more "asset-like" than others. And some things are an asset in one context (made on grid x) but not another (incompatible with grid y) or ARE assets, period, but you don't have permissions to take them with you. From secret.argent at gmail.com Sun Oct 7 21:22:19 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Oct 7 21:22:13 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709A560.6010703@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <4709A560.6010703@cox.net> Message-ID: <98D97F83-E183-4C21-966B-78F9EA128A92@gmail.com> On 07-Oct-2007, at 22:34, Lawson English wrote: > In my case, specifically, I'm talkign about the keywords/functions > data for the floater I'm making. This obviously is never going to > be published as an asset, but it still should "live" in the client. > The issue I ran into that got me so incensed about this whole thing > is that the folder class in the client is chained to the asset > server. Anything "not an asset" can't be put into a folder. The > classes themselves are so chained I can't derive a non-asset folder > class from them without rewriting almost the entire class. That's a fundamental design flaw in the UI library. You don't design a system around design flaws that absolutely need to be fixed. The Linden UI framework is pretty much worthless, except that it already works for OpenGL. Modifying a portable UI framework like Tk to include openGL calls in the same structure that already supports X11 and Win32 and Quartz calls is a better approach. > This is a trivial example, but what about more interesting ones? > > I have perhaps 100 sample scripts in my inventory. That's the other case. We're agreed, I think, that things that live in the asset server should be able to be treated as assets whether they're currently in the asset server or not. The solution is to fix the client so it can deal with them that way, but that's got nothing to do with the system architecture. > And, in the world wide grid, what about assets that can't be used > on one grid, but can be in another, that live in my inventory as > "assets" even though they're not assets on the currently accessed > grid? You need assets to be treated by the asset servers as blobs with properties anyway, so that when you get a prim with an asset in it that the local grid doesn't know how to handle it just sits there and gets copied and moved as an opaque object. That's got nothing to do with making things like names into assets in the client to work around bad design. From hud at zurich.ibm.com Fri Oct 5 05:40:43 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Sun Oct 7 21:24:45 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <47046DAD.5060400@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> <470445A4.4040301@gmail.com> <470467BB.8040702@gmail.com> <47046DAD.5060400@gmail.com> Message-ID: <470630CB.5080805@zurich.ibm.com> Tateru Nino wrote: > Jason Giglio wrote: > >> Argent Stonecutter wrote: >> >> [...] > If you boys did this inworld, I could totally sell tickets. :) > lol. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071005/c4e071b7/attachment-0001.htm From hud at zurich.ibm.com Fri Oct 5 05:38:46 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Sun Oct 7 21:24:49 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <470445A4.4040301@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <1191448391.11151.82.camel@localhost> <470445A4.4040301@gmail.com> Message-ID: <47063056.4050508@zurich.ibm.com> Jason Giglio wrote: > Callum Lerwick wrote: >> On Wed, 2007-10-03 at 16:42 -0500, Argent Stonecutter wrote: >>> That is, there are licenses that create a problem for open systems >>> use, and ones that don't. The GPL happens to be one that does. >> >> Can you point to a concrete example of the GPL causing such a problem? > > Callum, the GPL is constantly causing problems for people that want to > take GPL code, modify it, and keep the modifications secret, while > still distributing the modified work. > > In other words, the GPL doing what it's supposed to do. Some people > have a problem with this concept, and they'll bring up any ridiculous > argument they can to avoid coming out and saying their real problem > with the GPL is that it prevents them from closing the code. callum's point was about learning concepts and methods from GPL'd code, not about copying-modifying GPL'd code. cheers dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From seg at haxxed.com Sun Oct 7 22:30:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Oct 7 22:31:13 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47096F4D.20103@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> Message-ID: <1191821456.27061.13.camel@localhost> On Sun, 2007-10-07 at 16:44 -0700, Lawson English wrote: > I believe there can and likely SHOULD BE plenty of data associated > with the client that doesn't live in an external asset server. If "not > an asset" is defined as being "'unpublished' to the external world," > where "external" includes 1-person sims, then plenty of data that the > client might display will never be an asset or even a "proto-asset." You're really overthinking this. If I used the word "file" instead of asset would that make things any clearer? ;P Everything is a file, and every file is an asset. There are no "proto-assets". No "non-assets". Its all assets. And I'm getting sleepy and possibly incoherent. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071008/51cc36a3/attachment.pgp From lenglish5 at cox.net Sun Oct 7 22:43:40 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Oct 7 22:43:40 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191821456.27061.13.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <1191821456.27061.13.camel@localhost> Message-ID: <4709C38C.3060305@cox.net> Callum Lerwick wrote: > On Sun, 2007-10-07 at 16:44 -0700, Lawson English wrote: > >> I believe there can and likely SHOULD BE plenty of data associated >> with the client that doesn't live in an external asset server. If "not >> an asset" is defined as being "'unpublished' to the external world," >> where "external" includes 1-person sims, then plenty of data that the >> client might display will never be an asset or even a "proto-asset." >> > > You're really overthinking this. If I used the word "file" instead of > asset would that make things any clearer? ;P > > Everything is a file, and every file is an asset. There are no > "proto-assets". No "non-assets". Its all assets. > > And I'm getting sleepy and possibly incoherent. :) > Zha and I went around with this issue. I'm on the fence as far as terminology, but I DO agree with her that there is a dichotomy between stuff that lives on the server side and stuff that lives only on the client side (without any server knowing about it). Call it published vs unpublished assets, or assets vs non-assets, but there is an important architectural distinction, from the perspective of the client-server communication level, which is her concern in the AWG. I'll let her clarify her position beyond that. L From hud at zurich.ibm.com Sun Oct 7 22:18:54 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Sun Oct 7 23:13:04 2007 Subject: [sldev] Re: [PROTOCOL] Protocol Documentation In-Reply-To: <1C24A18D-B6CF-401B-8099-E424BAD8A0DC@gmail.com> References: <4702C702.1030100@wsu.edu> <20071003181130.GQ617@dague.net> <920d7d850710031142t113e87ebl9130e7702506bed5@mail.gmail.com> <47041A76.4000106@knowprose.com> <696F5C76-0221-4A32-A39A-F67176F6353F@gmail.com> <4705DF3C.3080009@zurich.ibm.com> <47065BD4.2030605@zurich.ibm.com> <1C24A18D-B6CF-401B-8099-E424BAD8A0DC@gmail.com> Message-ID: <4709BDBE.6060706@zurich.ibm.com> Argent Stonecutter wrote: > On 05-Oct-2007, at 10:44, dirk husemann wrote: >> Argent Stonecutter wrote: >>> On 05-Oct-2007, at 01:52, dirk husemann wrote: >>>> as we have seen >>>> with SCO you have ALWAYS the possibility of a greedy fool trying to >>>> attack you anyhow (e.g., claiming that the code you used was stolen >>>> from >>>> him, don't mind the BSD/GPL/whatever license). [..] > >> originally they claimed that code had been copied pretty much literally >> from their code basis --- thus, claiming that code that was used in >> linux was copied from them. not sure how that is the opposite direction. > > That is that it was code copied from their license to GPL, not that > they were claiming that the GPL or any other open source license > imposed limitations on someone's use of directly or indirectly derived > work. So I don't think there's any application here. > > The only thing that could conceivably apply is that they claimed both > literal copying and that IBM's code was a derived work simply because > it was developed by a licensee (the 'viral UNIX license' theory). That > should have been dead in the water because of the CSRG-USL row over > the BSD code, and Novell shot it down anyway. true. but my point was that *regardless of license type* you can always be taken to court (at least in the US it seems) --- if the court decides in your favour: fine --- but you'd have to cough up the funds to defend yourself first of all. and the SCO case is a "good" example of such a case. i'm not sure i personally would have those funds... > > Linden Labs contributor agreement should protect against any indirect > claims like that. If Linden Labs states[1] that simply using the code > to figure out the protocol (including using things like constants from > header files) does NOT make a work a derived work, that should > eliminate any concern about direct claims. it sure would. i think we both agree on that :-) -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Sun Oct 7 23:32:00 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Sun Oct 7 23:32:05 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <23bbb49e0710061453x6a3245aqf3851534197f2d7a@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <23bbb49e0710061453x6a3245aqf3851534197f2d7a@mail.gmail.com> Message-ID: <4709CEE0.8020204@zurich.ibm.com> Tao Takashi wrote: > Hi! > > > > 2007/10/6, Argent Stonecutter >: > > > > Where do permissions live? They're a common property of all assets in > the SL domain. They're not part of the asset, because different > "copies" of the asset have different permissions. Or does the asset > need to get split into a static part (eg, the actual texture) and a > dynamic one (SL permissions)? > > > > So why aren't they just copies? I think if you take caching too far it > gets very complicated. E.g. you probably cannot make sure anyway that > every > cached instance of a copy gets invalidated or changed once you change the > original object. I was thinking more about really copying the object > to the region > domain once it gets rezzed. It might then have another URL on the > region domain > (part of the URL might be some sort of UUID or internal ID). was just about to suggest the same: if different "copies" of the asset have different permissions/properties then they are really different copies in the true sense of the word. > > So if I give a notecard to somebody I wouldn't expect it to change if > I change > my original version. I would still do these things via a script or in > some "intelligent" > object. > > What I thought was something like the scope a creator can define once > they give or > rez the object. This might define in which circles it can be used. > Like scope can be > "only that region", "all regions on this domain", "only trusted > domains of level X" etc. > Problem is of course once it hits the region domain in Joe's garage > nothing should > be trusted anymore. With having a scope we can nevertheless still > allow these regions > to connect, you just cannot rez every object on them because the agent > domain > might forbid it (surely one would need to think about all the possible > cases). that ties back to the "allow export to region domains X, Y, Z"? -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071008/712663c1/attachment.htm From zha.ewry at gmail.com Sun Oct 7 23:36:46 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Sun Oct 7 23:36:51 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709C38C.3060305@cox.net> References: <4706AEB1.7050601@cox.net> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <1191821456.27061.13.camel@localhost> <4709C38C.3060305@cox.net> Message-ID: <920d7d850710072336w1cef3e5asfed9ad53246dd354@mail.gmail.com> Ok.. I need to get this to the wiki as well, but here goes. Lets think of two things. There's a broad eco system, full of servers, and services and clients and avatars, and tools. It's broader than the architecture that defines it. In particular, there are many concepts and nameable things which span the eco-system. In the center the architecture defines a very crisp set of things. Namely how the parts, defined largely as web services, interact, through a series of well defined web service contracts, some data formats, and some patterns how the calls should be assembled. This is where I get very pedantic.The architecture talks about the things which happen across the web services, between the various services and clients and the formats and such. The architecture cannot say a thing about what happens anywhere else. In the eco-system, spanning down to tools and internals, we will have many lovely concepts, such as nameable things which will soon be an asset. But.. things inside the guts of the client, and the servers themselves are not the things the architecture refers to. So.. An asset, even tho it is clearly still an asset, in some sense, inside the client, or inside a server.. is only, definable, in the context of how it is expressed in architectural space. If we accept, the notion that Zero, Which, and the Linden team is proposing, that this is deeply a web services, web style architecture, what that means, is, that an asset, as a term of architecture, only refers to the web addressable notion of the broader concept. The clients, and servers will, of course have lovely local objects, which happen to be the inside the component manifestation of the asset, but, they won't, in a formal sense, be the asset. If.. in order to make this make sense to people, one needs to define terms such as "asset" in the eco-system and terms "hosted_asset" or some such, in the architecture, that's fine. But.. We have to be crystal clear that there are two different things here. One is the addressable thing that I can refer to in an architectural sense, the other is the much broader, more informal sense of things which are clustered around the architectural idea. But, as they reside inside components, inside clients, without any way of being touched by architectural components, they aren't the same as the narrow term. Why get so pedantic? Because, we need to be able to say "We store the asset, in the asset server, and we pass it to other components, via a URL when passing by reference, and as a structured chunk of LLSD, when passing a copy down to the internal components of a server or client. And we need to distinguish between the copied hunk of state, and the web addressable item which gives us a copy of that state. - Zha On 10/8/07, Lawson English wrote: > > Callum Lerwick wrote: > > On Sun, 2007-10-07 at 16:44 -0700, Lawson English wrote: > > > >> I believe there can and likely SHOULD BE plenty of data associated > >> with the client that doesn't live in an external asset server. If "not > >> an asset" is defined as being "'unpublished' to the external world," > >> where "external" includes 1-person sims, then plenty of data that the > >> client might display will never be an asset or even a "proto-asset." > >> > > > > You're really overthinking this. If I used the word "file" instead of > > asset would that make things any clearer? ;P > > > > Everything is a file, and every file is an asset. There are no > > "proto-assets". No "non-assets". Its all assets. > > > > And I'm getting sleepy and possibly incoherent. :) > > > Zha and I went around with this issue. I'm on the fence as far as > terminology, but I DO agree with her that there is a dichotomy between > stuff that lives on the server side and stuff that lives only on the > client side (without any server knowing about it). > > Call it published vs unpublished assets, or assets vs non-assets, but > there is an important architectural distinction, from the perspective of > the client-server communication level, which is her concern in the AWG. > > I'll let her clarify her position beyond that. > > L > > > _______________________________________________ > 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/20071008/7ac8b93e/attachment-0001.htm From hud at zurich.ibm.com Sun Oct 7 23:43:25 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Sun Oct 7 23:43:37 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> Message-ID: <4709D18D.6070804@zurich.ibm.com> Argent Stonecutter wrote: > On 06-Oct-2007, at 17:30, Callum Lerwick wrote: >> On Sat, 2007-10-06 at 16:25 -0500, Argent Stonecutter wrote: >>> What about assets with editable properties, like clothing, gestures, >>> notecards, and so on? > >> Copy on write. If you edit it, it is a new asset, and gets a new >> identifier. > > That would cause some problems for SL: you don't change the UUID of a > texture when you change the permissions or description. They'd have to > be separate from the asset. once you've published an asset, why would that then cause a problem? -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From soft at lindenlab.com Sun Oct 7 23:44:15 2007 From: soft at lindenlab.com (Soft) Date: Sun Oct 7 23:44:18 2007 Subject: [sldev] [Ann] SLDev-Traffic #29 and #30 Message-ID: https://wiki.secondlife.com/wiki/SLDev-Traffic_29 https://wiki.secondlife.com/wiki/SLDev-Traffic_30 SLDev-Traffic numbers 29 and 30 are up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From lenglish5 at cox.net Mon Oct 8 02:11:06 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Oct 8 02:11:08 2007 Subject: [sldev] [META][AWG] AW Groupies meeting and wiki page Message-ID: <4709F42A.3090301@cox.net> The in-world discussion group is holding meetings once or twice a week now. The next meeting will be: When: Tue Oct 9, 2007 8am to 10am PDT Where: http://slurl.com/secondlife/ThorneBridgeTown/156/129/24 Contact Zha Ewry in-world for an invite into the group if you wish to attend the meeting as ThorneBridgeTown is closed to the public. The wiki page for the group, including references to current discussion pages, is: https://wiki.secondlife.com/wiki/AW_Groupies L. From hud at zurich.ibm.com Mon Oct 8 02:11:07 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 02:11:13 2007 Subject: [sldev] [Auth] [OpenID] OpenID and AWG In-Reply-To: <4708EF6A.1000408@dzonux.net> References: <4708795E.9090902@gmail.com> <4708EF6A.1000408@dzonux.net> Message-ID: <4709F42B.3020405@zurich.ibm.com> Dzonatas wrote: > Should AWG focus on this first as discussion? i think that would be a good starting point. also, i think AWG should focus their discussions :-) 3.5hrs chat log is nice and dandy but serves no real purpose from a spec point of view. chat log without summary and write up is pretty much wasted... dirk > > After I read that long long wiki log...hmmm..., I think this is > something that can be tackled easier and have more of an immediate impact. > > Matthew Dowd wrote: >> I've already covered this scenario in other posts to the list. >> >> There is a lot of work on brokered id validation, which could use >> OpenID or similar as the foundation piece. >> >> A feature an OpenID provider can do is to provide an attribute look >> up service (similar to Shibolleth), so that SL (or others) can send >> back queries such as Age, Over18Status, Address. >> >> You can control how much or how little is revealed to a particular >> provider (so SL may be able to ask Over18Status but not Age; your web >> service provider may be able to ask for MobilePhoneNumber etc.) >> >> It terms of validating - this is done by third party brokers - so >> your bank may sign the Age and Over18Status properties (using >> certificates or similar) - there is some industry interest in >> providing such services. >> >> This validation is therefore completely independent of who the OpenID >> provider is. >> >> If this gets off the ground, on LL's side, it becomes a case of which >> identity providers they are willing to trust (say some major league >> banks). >> >> On the users side, LL gets to access *only* the information they need >> (i.e. Over18Status), whilst all the supporting information for this >> only needs to go to someone who trust or have already trusted with >> this information (e.g. your bank). In essence this is a digital >> automated equivalent of a notary signing a "this person is over >> eighteen" statement... >> >> Yes - there is still a lot of work outstanding on the above, and it >> will only fly if there's enough momentum behind it, but this is a >> direction that is attracting a lot of interest in the online >> verification debate. >> >> Matthew >> >> >> >> > Date: Sun, 7 Oct 2007 02:14:54 -0400 >> > From: gigstaggart@gmail.com >> > To: kamilion@gmail.com; sldev@lists.secondlife.com >> > Subject: Re: [sldev] [Auth] [OpenID] OpenID as SL Authentication >> Solution >> > >> > Kamilion wrote: >> > > I've been doing some surfing on OpenID, and found out a lot about it. >> > >> > So I set up gigstaggart.com/openid as my own provider. I claim to be >> > Bill Clinton. Second Life has no way of knowing I'm not Bill Clinton, >> > since my provider (me) doesn't do any strong authentication of who >> I am. >> > >> > Replace Bill Clinton with "over 18", if you want the age >> verification angle. >> > >> > Basically, OpenID is only as strong as the provider in terms of real >> > authentication. The only OpenID provider that would be acceptable for >> > Second Life would be Linden Lab. Back to square 1. >> > >> > -Jason >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> ------------------------------------------------------------------------ >> Get free emoticon packs and customisation from Windows Live. Pimp My >> Live! >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -- > Power to Change the Void > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071008/e963be73/attachment.htm From hud at zurich.ibm.com Mon Oct 8 02:17:30 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 02:17:33 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <47098475.9060100@wsu.edu> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> Message-ID: <4709F5AA.6010704@zurich.ibm.com> John Hurliman wrote: > Argent Stonecutter wrote: >> >> On 06-Oct-2007, at 15:42, Callum Lerwick wrote: >>> "Almost all programming can be viewed as an exercise in caching" >> >> Yah. Caching was the thing that immediately sprang to mind as a >> problem with using a URL and making requests in real time. Resources >> need to live "close" to where they're used. Assets are going to get >> copied around. Assets referred to from in-world objects need to still >> work even if the asset server from Joe's Bar and Grid is offline, so >> they need to be cached. >> >>> For this to happen, we need a way to unambiguously >>> identify an asset, completely independent of its location. A content >>> hash is probably the best way to do this. Duplicate copies of an asset >>> become obvious to identify, and likewise maliciously modified or >>> corrupted copies of the asset can be identified and culled. >> >> What about assets with editable properties, like clothing, gestures, >> notecards, and so on? > > I don't know if this has already been answered in the thread, but > currently there is no such thing as an asset with editable properties. > If you change a word in a notecard and save it, you are uploading a > new asset to the grid. If you change the sleeve length of your shirt > and save it, you are uploading a new wearable asset (and new temporary > bakes for your final outfit). > which supports the change-an-asset-and-it-turns-into-a-new-asset faction --- which, i think, makes things much easier and reduces overhead and load. suggestion: asset: once created in-world is fixed. change permission, change description, change texture -> new asset. asset includes all properties. that way it can be cached without having to verify with the "originating" domain whether the creator has changed her mind... keep it simple. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Oct 8 02:21:16 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 02:21:52 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709A560.6010703@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <4709A560.6010703@cox.net> Message-ID: <4709F68C.6070502@zurich.ibm.com> Lawson English wrote: > Argent Stonecutter wrote: > [...] > In my case, specifically, I'm talkign about the keywords/functions > data for the floater I'm making. This obviously is never going to be > published as an asset, but it still should "live" in the client. The > issue I ran into that got me so incensed about this whole thing is > that the folder class in the client is chained to the asset server. > Anything "not an asset" can't be put into a folder. The classes > themselves are so chained I can't derive a non-asset folder class from > them without rewriting almost the entire class. > > This is a trivial example, but what about more interesting ones? > > I have perhaps 100 sample scripts in my inventory. There's no easy way > to browse them save by name because they are assets. Why can't I have > "proto" scripts that live in a folder that points to one or more xml > files or to a database that only lives on my computer, but that I can > still manipulate as a "first class" bit of data for every purpose > EXCEPT dumping into some other inventory? (and translation mechanisms > for most types of non-assets could still be automated ala the > conventions that apple developed 24 years ago for the Mac clipboard > and refined in the OpenDoc spec). > > What about the notes on friends/enemies/places of interest that > everyone keeps? Those aren't sortable either. > > What about sculpty textures created with a client plug-in that aren't > loaded to the asset server? those are all client-local. nothing to do with the architecture or asset at all. seems to me it's got a lot to do with how the client is implemented. > > And, in the world wide grid, what about assets that can't be used on > one grid, but can be in another, that live in my inventory as "assets" > even though they're not assets on the currently accessed grid? > > In principle, anything that a user can view inside the client, could > become an asset, either as a notecard, or a screenshot-texture, but > some things are more "asset-like" than others. And some things are an > asset in one context (made on grid x) but not another (incompatible > with grid y) or ARE assets, period, but you don't have permissions > to take them with you. i disagree. only things that you have rezzed on the grid --- that is, things OTHERS can see/access --- should become an asset. stuff that only you can see i would not consider an asset in the grid-sense. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From jhurliman at wsu.edu Mon Oct 8 06:16:37 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Oct 8 06:16:19 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709F5AA.6010704@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> Message-ID: <470A2DB5.203@wsu.edu> dirk husemann wrote: > John Hurliman wrote: > >> Argent Stonecutter wrote: >> >>> On 06-Oct-2007, at 15:42, Callum Lerwick wrote: >>> >>>> "Almost all programming can be viewed as an exercise in caching" >>>> >>> Yah. Caching was the thing that immediately sprang to mind as a >>> problem with using a URL and making requests in real time. Resources >>> need to live "close" to where they're used. Assets are going to get >>> copied around. Assets referred to from in-world objects need to still >>> work even if the asset server from Joe's Bar and Grid is offline, so >>> they need to be cached. >>> >>> >>>> For this to happen, we need a way to unambiguously >>>> identify an asset, completely independent of its location. A content >>>> hash is probably the best way to do this. Duplicate copies of an asset >>>> become obvious to identify, and likewise maliciously modified or >>>> corrupted copies of the asset can be identified and culled. >>>> >>> What about assets with editable properties, like clothing, gestures, >>> notecards, and so on? >>> >> I don't know if this has already been answered in the thread, but >> currently there is no such thing as an asset with editable properties. >> If you change a word in a notecard and save it, you are uploading a >> new asset to the grid. If you change the sleeve length of your shirt >> and save it, you are uploading a new wearable asset (and new temporary >> bakes for your final outfit). >> >> > which supports the change-an-asset-and-it-turns-into-a-new-asset faction > --- which, i think, makes things much easier and reduces overhead and load. > > suggestion: asset: once created in-world is fixed. change permission, > change description, change texture -> new asset. asset includes all > properties. that way it can be cached without having to verify with the > "originating" domain whether the creator has changed her mind... > > keep it simple. > > cheers, > dirk > > In the current model, only changing the asset data itself causes a new asset to be created. An asset consists of the data + metadata which includes name, description, and permissions. This works out pretty well because a lot of people might be running the same script, or the same notecard might be handed out to 500 different people, or a popular clothing item might be owned by a large number of people. In those cases where nothing has changed in the asset data, they all link to the same uuid to download the actual data but the metadata is different for each one (at a minimum the OwnerID is changed). That's just a description of the current model, but I think something similar might be a good approach for the future. John Hurliman From secret.argent at gmail.com Mon Oct 8 06:39:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 8 06:39:08 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709D18D.6070804@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> <4709D18D.6070804@zurich.ibm.com> Message-ID: <1CDBE6DF-A343-426C-8C93-43C4C3E20798@gmail.com> On 08-Oct-2007, at 01:43, dirk husemann wrote: > Argent Stonecutter wrote: >> On 06-Oct-2007, at 17:30, Callum Lerwick wrote: >>> On Sat, 2007-10-06 at 16:25 -0500, Argent Stonecutter wrote: >>>> What about assets with editable properties, like clothing, >>>> gestures, >>>> notecards, and so on? >>> Copy on write. If you edit it, it is a new asset, and gets a new >>> identifier. >> That would cause some problems for SL: you don't change the UUID of a >> texture when you change the permissions or description. They'd >> have to >> be separate from the asset. > once you've published an asset, why would that then cause a problem? Because the UUID (or, in the long term, this URL) is used to reference it from scripts and from references in assets and prims, so here you are, you have a bunch of such secondary assets, and they're in an attachment on your avatar... and you walk across a grid boundary from one domain to another, get your attachment re-parented in the new domain, turn around and walk back again... that stuff has to continue working... even if someone else changes the texture description of the "flaming sword" texture while you're over there. From secret.argent at gmail.com Mon Oct 8 06:41:43 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 8 06:41:31 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470A2DB5.203@wsu.edu> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <470A2DB5.203@wsu.edu> Message-ID: On 08-Oct-2007, at 08:16, John Hurliman wrote: > In the current model, only changing the asset data itself causes a > new asset to be created. An asset consists of the data + metadata > which includes name, description, and permissions. This works out > pretty well because a lot of people might be running the same > script, or the same notecard might be handed out to 500 different > people, or a popular clothing item might be owned by a large number > of people. In those cases where nothing has changed in the asset > data, they all link to the same uuid to download the actual data > but the metadata is different for each one (at a minimum the > OwnerID is changed). > > That's just a description of the current model, but I think > something similar might be a good approach for the future. Right, that metadata is what I'm referring to as "properties". From robin.cornelius at gmail.com Mon Oct 8 07:11:36 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Oct 8 07:11:39 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <1191620596.26663.34.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <1191620596.26663.34.camel@localhost> Message-ID: On 10/5/07, Callum Lerwick wrote: > On Fri, 2007-10-05 at 13:32 +0100, Robin Cornelius wrote: > > Can we maybe think about splitting up the viewer (distribution) into > > smaller packages. Surely the various artwork and supplied textures > > remain pretty constant and it seems wasteful redistributing the same > > data over and over again. > > Ah, something else on the to do list I've forgotten about. In Fedora, > we've been encouraging upstream projects to separate (arch-independent) > game data from source. This is advantageous for us, no only can we issue > updates to the binaries without everyone having to re-download a large > amount of game data, but the game data can be a "noarch" package, shared > across all architectures, reducing storage requirements on our mirrors. > > LL already separates the "artwork" from the viewer source, which is most > of the way there. What makes it much less useful to us is the fact that > a new artwork tarball comes out with every source release. Could LL > avoid releasing a new artwork tarball unless it has actually changed? I > haven't got around to diffing it and seeing how often it actually > changes, if it is changing, maybe it shouldn't. ;P > Ok here goes, as i was at work today i though i would look at the differences between artwork releases (instead of working) to see how volatile we are :- 1.16.0.5 -> 1.17.0.12 No difference 1.17.0.12 -> 1.17.1.0 skins/textures/ +1 file 1.17.1.0 -> 1.17.2.0 No difference 1.17.2.0 -> 1.17.3.0 skins/textures/ +8 files 1.17.3.0 -> 1.18.0.6 No difference 1.18.0.6 -> 1.18.1.2 skins/textures/ +23 files 1.18.1.2 -> 1.18.2.1 No difference 1.18.2.1 -> 1.18.3.5 character/ +2 files skins/textures/ (+252 files -184 files) The current artwork is broken down in to the following :- 8.1M app_settings 7.7M character 2.4M res 172K res-sdl 14M skins So mostly the artwork does not change very much, when it does its mostly the skins/textures directory. If skins/textures MUST change then prehpase this is worth splitting into 2 arch independent packages. One for skins the other for everything else? Certainly this is worth doing as it can save 24MB (zipped) data download each time and I think i will now split my .deb files to save my own bandwidth on my server for my amd64 versions. Can someone more knowledgeable than myself confirm if the textures/skins updates are needed or are these things that can be fetched inworld? eg just textures or are they part of the UI design. Regards Robin From dale at daleglass.net Mon Oct 8 07:27:00 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Oct 8 07:27:10 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <1191620596.26663.34.camel@localhost> Message-ID: <20071008142700.GA16690@bruno.sbruno> On Mon, Oct 08, 2007 at 03:11:36PM +0100, Robin Cornelius wrote: > Can someone more knowledgeable than myself confirm if the > textures/skins updates are needed or are these things that can be > fetched inworld? eg just textures or are they part of the UI design. > > Regards > > Robin AFAIK, the viewer will automatically fetch UI textures if needed if they can't be found locally. Now, with the size of the artwork package, that could take some time, and meanwhile you'd have things like missing icons in the inventory. Also, I remember discussing with Soft that there's a possibility that textures used in this way might suddenly disappear from the asset server if they're not referenced anywhere in-world. This is probably not a big deal for LL, who can make an exception, but third party viewer makers should have this in mind. Perhaps one way of doing this would be to add a texture download stage to the login process, and cache them permanently. Shouldn't be difficult. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071008/ebb1497e/attachment.pgp From richard at lindenlab.com Mon Oct 8 10:28:42 2007 From: richard at lindenlab.com (Richard Nelson) Date: Mon Oct 8 10:28:56 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: <4707D57B.4050803@gmail.com> References: <4705CEE1.1050802@gmail.com> <4707D57B.4050803@gmail.com> Message-ID: On Sat, 06 Oct 2007 11:35:39 -0700, Jason Giglio wrote: > > The camera behaves in unexpected ways when it's in FOV zoom on small > prims mainly. I'll have to play with it some. > Please do. Any feedback would be appreciated. There are other approaches we could take, such as bringing in the far clip plane dynamically or living with the reduced z buffer precision of a very close near plane, but each has their drawbacks. Keep in mind that when zooming in on an object, the object itself is not always the user's point of interest (which admittedly is a problem with the FOV zoom approach). For those unfamiliar with the mathematics of z buffering, wikipedia has a decent summary: http://en.wikipedia.org/wiki/Z-buffering > OK, so if we are adding new UI, we should avoid text elements that > aren't really text elements, and use XUI strings instead, if > appropriate? Should we clean these up if we are touching a file that > has them anyway? Yes, please stick to XUI strings for new UI. Don't worry about cleaning up existing files, since I plan to remove them in our cleanup pass anyway. Richard From lenglish5 at cox.net Mon Oct 8 11:02:59 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Oct 8 11:03:26 2007 Subject: [sldev] Various questions on the viewer. In-Reply-To: References: <4705CEE1.1050802@gmail.com> <4707D57B.4050803@gmail.com> Message-ID: <470A70D3.802@cox.net> Richard Nelson wrote: > On Sat, 06 Oct 2007 11:35:39 -0700, Jason Giglio > wrote: >> >> The camera behaves in unexpected ways when it's in FOV zoom on small >> prims mainly. I'll have to play with it some. >> > > Please do. Any feedback would be appreciated. There are other > approaches we could take, such as bringing in the far clip plane > dynamically or living with the reduced z buffer precision of a very > close near plane, but each has their drawbacks. Keep in mind that > when zooming in on an object, the object itself is not always the > user's point of interest (which admittedly is a problem with the FOV > zoom approach). > > For those unfamiliar with the mathematics of z buffering, wikipedia > has a decent summary: > > http://en.wikipedia.org/wiki/Z-buffering > >> OK, so if we are adding new UI, we should avoid text elements that >> aren't really text elements, and use XUI strings instead, if >> appropriate? Should we clean these up if we are touching a file that >> has them anyway? > > Yes, please stick to XUI strings for new UI. Don't worry about > cleaning up existing files, since I plan to remove them in our cleanup > pass anyway. > > Richard > Any tips on when it is appropriate to use XUI strings? I haven't seen a need for them in my faux-folder code, but that doens't accept user input save as mouse clicks. L From gigstaggart at gmail.com Mon Oct 8 12:34:19 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Oct 8 12:34:16 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <920d7d850710072336w1cef3e5asfed9ad53246dd354@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <1191821456.27061.13.camel@localhost> <4709C38C.3060305@cox.net> <920d7d850710072336w1cef3e5asfed9ad53246dd354@mail.gmail.com> Message-ID: <470A863B.8010407@gmail.com> Zha Ewry wrote: > Why get so pedantic? Because, we need to be able to say "We store the > asset, in the asset server, and we pass it to other components, via a > URL when passing by reference, and as a structured chunk of LLSD, when > passing a copy down to the internal components of a server or client. > And we need to distinguish between the copied hunk of state, and the web > addressable item which gives us a copy of that state. "Asset Instance" works for me, and anyone even a little familiar with OOP will know what we mean instantly. -Jason From 1337mail at gmail.com Mon Oct 8 13:00:49 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Oct 8 13:00:52 2007 Subject: [sldev] XCode bug - please help figure out why Message-ID: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> I contacted Apple about a bug when opening Second Life in a version of XCode > 2.5(you do the math). Apple replied, saying that the bug is in the following lines of the project file: D64E29CE0B4B288600963559 /* PBXTargetDependency */ = { isa = PBXTargetDependency; }; FD53B40C09BDFD3E00BFE3BC /* PBXTargetDependency */ = { isa = PBXTargetDependency; }; FD53B41009BDFD5300BFE3BC /* PBXTargetDependency */ = { isa = PBXTargetDependency; }; FD53B41209BDFD5A00BFE3BC /* PBXTargetDependency */ = { isa = PBXTargetDependency; }; According to Apple, it is due to a missing dependency with no name. Apple is inquiring about why this happening, so they can investigate and possibly fix the problem that originally caused this. Does anyone have any insight as to why this occurred? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071008/b71efe44/attachment.htm From dmahalko at gmail.com Mon Oct 8 13:10:51 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 8 13:10:53 2007 Subject: [sldev] Havok4: Offer LOD degrade priority to landowners and groups first In-Reply-To: <470125A4.7060909@lindenlab.com> References: <470125A4.7060909@lindenlab.com> Message-ID: >From my build tests it appears that the current LOD system gives absolutely no leeway for transient lag. All it takes is for a single frame to be slow and it instantly kicks in, usually exploding something that was previously stable for thousands of frames. Slow frames seem to be caused by both rezzing and derezzing, and so may not have anything to do with physics processing. In such events degrading will do nothing to fix the problem. It would be nice if you could give a little time for the LOD degrading to kick in, such as five seconds of slow frames, before it forces degrading. For a few rez-based slow frames, the high CPU load may go away in a frame or two all by itself without any need for degrade. - Scalar Tardis / Dale Mahalko On 10/1/07, Andrew Meadows wrote: > Such complex machines may lie outside the possibility space in SL for > a while. At the moment the shape LOD system is not very smart so yes, > the grief mode you describe would work. More importantly, it may be > possible for a griefer to cause someone's house to get boxified --> > ejecting all the avatars therein. From phoenix at secondlife.com Mon Oct 8 13:15:59 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Oct 8 13:16:10 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> Message-ID: D64E29CE0B4B288600963559 is the id for llkdu, which we strip out of the project file on export. This will need investigation on our part to see if something got broken. You should be able to delete that block for now. On 2007-10-08, at 13:00 , Michael Miller wrote: > I contacted Apple about a bug when opening Second Life in a version > of XCode > 2.5(you do the math). Apple replied, saying that the bug > is in the following lines of the project file: > D64E29CE0B4B288600963559 /* PBXTargetDependency */ = { > isa = PBXTargetDependency; > }; > FD53B40C09BDFD3E00BFE3BC /* PBXTargetDependency */ = { > isa = PBXTargetDependency; > }; > FD53B41009BDFD5300BFE3BC /* PBXTargetDependency */ = { > isa = PBXTargetDependency; > }; > FD53B41209BDFD5A00BFE3BC /* PBXTargetDependency */ = { > isa = PBXTargetDependency; > }; > According to Apple, it is due to a missing dependency with no name. > Apple is inquiring about why this happening, so they can > investigate and possibly fix the problem that originally caused this. > > Does anyone have any insight as to why this occurred? > > Thanks, > Mike > _______________________________________________ > 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/20071008/7765edf6/PGP.pgp From lenglish5 at cox.net Mon Oct 8 13:45:19 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Oct 8 13:45:32 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470A863B.8010407@gmail.com> References: <4706AEB1.7050601@cox.net> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <470811C4.10003@cox.net> <1191786318.23363.86.camel@localhost.localdomain> <47096F4D.20103@cox.net> <1191821456.27061.13.camel@localhost> <4709C38C.3060305@cox.net> <920d7d850710072336w1cef3e5asfed9ad53246dd354@mail.gmail.com> <470A863B.8010407@gmail.com> Message-ID: <470A96DF.5010205@cox.net> Jason Giglio wrote: > Zha Ewry wrote: >> Why get so pedantic? Because, we need to be able to say "We store the >> asset, in the asset server, and we pass it to other components, via a >> URL when passing by reference, and as a structured chunk of LLSD, >> when passing a copy down to the internal components of a server or >> client. And we need to distinguish between the copied hunk of state, >> and the web addressable item which gives us a copy of that state. > > > "Asset Instance" works for me, and anyone even a little familiar with > OOP will know what we mean instantly. > > Not in a shared, collaborative environmnent like SL. The term "instance" takes on new subtlties in this situation. Consider the design issues of the old OpenDoc document format and behavior. "Object" and "instance" are very complex in such a situation. What does it mean to "copy" an object when it can be viewed by many different programs at the same time, many of which might want editing privileges, for example? http://mactech.com/articles/mactech/Vol.13/13.06/LinksinOpenDocParts/index.html The issues that arose for distributed objects are starting to appear in the context of assets in a virtual world, which is an even larger issue than what OD had to worry about, which was quite complex, even so. L From seg at haxxed.com Mon Oct 8 13:46:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 8 13:46:40 2007 Subject: [sldev] Havok4: Offer LOD degrade priority to landowners and groups first In-Reply-To: References: <470125A4.7060909@lindenlab.com> Message-ID: <1191876384.29582.2.camel@localhost> On Mon, 2007-10-08 at 15:10 -0500, Dale Mahalko wrote: > >From my build tests it appears that the current LOD system gives > absolutely no leeway for transient lag. All it takes is for a single > frame to be slow and it instantly kicks in, usually exploding > something that was previously stable for thousands of frames. If this LOD stuff is going to happen at all, it needs to check if "cubing" the object creates new collisions before actually doing it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071008/bc196893/attachment.pgp From dmahalko at gmail.com Mon Oct 8 14:55:08 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 8 14:55:16 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <46FD501B.5080501@lindenlab.com> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> Message-ID: This thread is now a week old but I should respond to this: On 9/28/07, Kent Quirk (Q Linden) wrote: > So it's an interesting point of view you're expressing. > > To me, sculpties define a smooth mapping of the vertices of a > well-defined closed mesh. After that, anything that happens is largely > an artifact of the implementation and could easily vary between > platforms or implementations. > > You, as you put it, "see optimization and untapped power." You're trying > to find ways to extend sculpties to do things like change the topology > of the prims. > > The architect in me wants to preserve the freedom to change the > implementation of sculpties in the future as we learn more about ways to > improve and design the implementation. If people start depending on > implementation details to do things like drill holes in sculpties by > abusing the way rendering works, it constrains our ability to extend the > feature in the future. Of course, it'll probably happen whether I want > it to or not -- but it's where I'm coming from. > > In any case, seems like you're asking for sculpties to be able to do > things that are better suited to using separate objects. Could you > explain your motivation for wanting to extend the definition so far? I don't know who is in charge of the sculptie project, but it seems like nobody has made an effort to describe the future direction of scultpies. We as end-users are simply presented with the concept as it functions now, but are not given insight into the future plans for sculpties. Perhaps there isn't any plan at all, and this is just a seat-of-the-pants hack someone came up with one day, to exploit JPEG compression for the totally off-the-wall idea of compressing non-visual vertex data. It's long been my impression that sculpties are an extremely convoluted attempt to provide an equivelant to raw mesh data, while at the same time capping the amount of data involved to some absolute number of mesh triangles, and meanwhile also not needing to extend the dataserver storage systems to implement a new raw-mesh datatype. However, sculpties are generally triangle-inefficient to shape anything more complex than a rough blob, since to shape extremely complex objects like a chair it is necessary to overlap and "bunch up" whole swaths of triangles because there's too many in this spot, while then also weirdly deforming the desired shape because we can't get enough triangles moved over to where they're needed in another spot. One of LL's own initial sample objects demonstrate this useless bunching up of unneeded triangles that cause unnecessary rendering load, with the sharply curving "S" sculptie. A much simpler custom mesh could do the same thing with far fewer triangles: http://wiki.secondlife.com/wiki/Image:Sculpted-preview-04.png Sculpties may be exploiting JPEG as a vertex compressor, but at the cost of very sloppy detail-triangle usage and difficult-to-manage triangle disitributions. AFAIK, nobody has clearly explained why implementing sculpties is more desirable than just using direct meshed-objects and allowing direct triangle-mesh importing from 3DS Max or whatever. - If data storage is the issue then fine, set some absolute limit on the number of triangles a given freeform uploaded mesh is allowed to contain. - If compression is the issue, there's probably some way to optimize freeform mesh data storage that doesn't rely on a flat blanket of triangles as with sculpties. - If supporting a new storage datatype within a massive legacy database is the issue, there's probably a way to store it compressed on notecards or something. - If network load is the issue, make users of custom meshes pay for the sluggishness that progressively more complex meshes will cause for others. And I realy mean, make them pay more L$ to upload more complex triangle meshes. Make the cost high enough to upload something with many triangles vs something with few triangles, and people WILL make their meshes efficient to conserve bandwidth. Perhaps bind such custom meshes to a prim base as with sculpties and still limit the mesh to a max 10.0x10.0x10.0 size, nonphysical. If we can't have raw mesh importing directly, then people at least want to make sculpties perform as closely as possible to how normal custom meshes work. Already there's the demand for precise sculpt map storage without compression artifacts, which allows for very sharp edges and precise vertex control. This reduces the amount of "organic smoothing" done by the JPEG algorithm, but has the side effect of potentially increasing the size of the compressed data. With my suggestions I am simply trying to work within and expand upon the extremely constrained vertex-based environment LL has established with the implementing of sculpties. -Scalar Tardis aka Dale Mahalko From cnd at knowprose.com Mon Oct 8 18:21:11 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Mon Oct 8 16:25:00 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <50FABEFE-4FB6-4628-8B7F-370EDDE7E6CB@gmail.com> <200710032222.19372.dale@daleglass.net> <47041AF7.1020109@knowprose.com> <47051BC9.5050706@knowprose.com> Message-ID: <470AD787.5060205@knowprose.com> The interface does NOT stop land from being shown immediately once set for sale. That is pointedly NOT there, so I fail to see how the response deals with the request. Harold Brown wrote: > The interface already has a "think about what you are doing screen" > The interface already has a "You must select to sell to anyone or a > specific AV" > The Land Search already has a throttle on the amount of data you can > get in a period of time. (Do a land search and try rapidly changing > pages back and forth) > There is already a delay before the land set for sale is visible on > the "For Sale" list (I've helped people verify their land settings > before and it took a couple minutes for the plot to show up to verify > on the land sale screen) > Most everything you want is already there... people just do not use them. > On 10/4/07, *Matthew Dowd* > wrote: > > Well, my suggestion (and others have made it too) would be a five > minute moratorium after land is set for sale during which time > *only* those present on the sim when the land was set for sale can > buy. > > It provides a breathing space for second thoughts, mistake > correction, correction of mispriced land due to software > glitches/lag etc. before a bot can run in and purchase the land. > > It supports the typical scenario of "buyer was present and no-one > else was so I thought it was safe to set to sale to anyone and > that setting for sale to a specific person was just an additional > sequence of unnecessary steps..." > > It *is* theoretically possible that someone could get around this > by running enough bots - either as many bots as mainland sims, or > at least a large enough number that there is a good statistical > probability of being in a sim when land is set for sale... > > Matthew > > > ------------------------------------------------------------------------ > So what complaint do we really have? > 1. The interface is so confusing it causes people to make > mistakes in selling land > 2. Land Bots can find and buy land faster then a human > > > ------------------------------------------------------------------------ > Play Movie Mash-up and win BIG prizes! > > > -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From cnd at knowprose.com Mon Oct 8 18:29:01 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Mon Oct 8 16:32:47 2007 Subject: [sldev] CAPTCHA to validate land sales. In-Reply-To: References: Message-ID: <470AD95D.1020105@knowprose.com> It seems to me that few people here have sold much land within Second Life. Because of that, the defense of landbots is purely academic and as such is poor. Certainly, landbots are here to stay. But when you actually lose money because of some land sale glitch - these have been known to happen - or typos - more frequent - or user error... these armchair discussions seem less than enlightened. In the State of Florida, 5 people have to die at an intersection before they put up traffic lights. The point here is that whether or not you know the 5 people, at least there is someone keeping track and not saying 'jeepers, they sure are good for the economy', and 'all those mistakes must be human error'. The problem is hardly academic, and is quite easily solved should someone get off their butts and fix it. It isn't a perfect solution, we know, but a 5 minute hold on showing lots in a search query sure sounds reasonable. But, as we all know, people who use landbots to eek out those mistakes/glitches.... they use that money to buy t-shirts, houses and other stuff in Second Life, right? Right... you have GOT to hand me some of what you're smoking.... Ada Radius wrote: > In a RL economy, the land bots could be considered a benefit - > increasing liquidity in the land market. I don't use them, but if I > want to get rid of land in a hurry, I'm glad they're there. Since LL > controls both currency and land supply, and they're a for-profit > entity (and no better or worse at economics than governments), > liquidity in both land and L$ can be puzzling. I do think that there > should be more security in the way that money is handled in-game > (getting rid of L$ would be a good thing). Along with more > straightforward ways of describing "land" and "land sales" - we're > leasing CPU usage, after all, and paying for sets of locations. It's > not RL land, and shouldn't be handled as though it were. CAPTCHA is > one way to go for that security - my RL bank has other ways - those > are the folks we should be looking at for precedent and experience on > money transactions, I think. > Ada Radius > > Message: 1 > Date: Thu, 04 Oct 2007 10:58:49 -0600 > From: Taran Rampersad < cnd@knowprose.com > > Subject: Re: [sldev] CAPTCHA to validate land sales. > To: Matthew Dowd > > Cc: sldev@lists.secondlife.com > Message-ID: <47051BC9.5050706@knowprose.com > > > Content-Type: text/plain; charset=windows-1252; format=flowed > > Matthew Dowd wrote: > > > > >> Whatever you may personally feel about landbots - their use > is not > > >> illegal in SL nor against the TOS. > > >Lets quit mixing 'legality' and ToS. ToS is a contract, subject to > > >contract law. It is not *THE* Law. > > > > I never said it was *THE* law - the word "illegal" can be quite > > legitimately used as a synonym for banned, prohibited etc. > without it > > necessarily being anything to do the the Law of the land. > No. The word 'illegal' has very different connotations. It quite > literally means, "against the law". > > Against ToS? Against Community Standards? Legitimate. Saying something > is illegal is a very different thing. The ToS and Community Standards > have been in court at least once, and were modified due partly to the > legality of the ToS itself. > > I fully expect 'fictional currency' to be the next sticking point. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From seg at haxxed.com Mon Oct 8 19:08:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 8 19:08:48 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> Message-ID: <1191895700.29582.5.camel@localhost> On Mon, 2007-10-08 at 16:55 -0500, Dale Mahalko wrote: > AFAIK, nobody has clearly explained why implementing sculpties is more > desirable than just using direct meshed-objects and allowing direct > triangle-mesh importing from 3DS Max or whatever. Sculpties make LOD easy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071008/88097488/attachment.pgp From secret.argent at gmail.com Mon Oct 8 20:01:37 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 8 20:01:23 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <1191895700.29582.5.camel@localhost> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> Message-ID: <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> On 08-Oct-2007, at 21:08, Callum Lerwick wrote: > On Mon, 2007-10-08 at 16:55 -0500, Dale Mahalko wrote: >> AFAIK, nobody has clearly explained why implementing sculpties is >> more >> desirable than just using direct meshed-objects and allowing direct >> triangle-mesh importing from 3DS Max or whatever. > Sculpties make LOD easy. Sculptie LoD doesn't work very well, though. It would be better just to require a low detail and a high detail mesh. It would be better to let people provide a billboard textures for objects and use that instead of dropping LoD, just as a matter of course. llSetBillboardTexture(integer viewpoint, string texture, vector tint); Where the viewpoints correspond to the faces of the cube the billboard planes intersect. When the object's "too far" away, it gets replaced by the billboard texture most nearly facing the camera. From dzonatas at dzonux.net Mon Oct 8 20:13:11 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Oct 8 20:13:15 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> Message-ID: <470AF1C7.8070605@dzonux.net> Argent Stonecutter wrote: > It would be better to let people provide a billboard textures for > objects and use that instead of dropping LoD, just as a matter of course. That sounds more complicated. I wonder if the LOD field really needs to be so aggressive as it is now. Technology has changed, so some LOD triggers could be cooled off or even disabled on faster machines. -- Power to Change the Void From seg at haxxed.com Mon Oct 8 20:30:02 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 8 20:30:21 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <4709F5AA.6010704@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> Message-ID: <1191900602.29582.33.camel@localhost> On Mon, 2007-10-08 at 11:17 +0200, dirk husemann wrote: > which supports the change-an-asset-and-it-turns-into-a-new-asset faction > --- which, i think, makes things much easier and reduces overhead and load. That's the idea. :) > suggestion: asset: once created in-world is fixed. change permission, > change description, change texture -> new asset. asset includes all > properties. that way it can be cached without having to verify with the > "originating" domain whether the creator has changed her mind... No. Look at files on your disk. Metadata such as filename, its permissions, creation dates etc, are not part of the file itself. Changing the filename or its permissions does not change the file contents. What I've been calling an Asset is analogous to the contents of a file. How about if we call it a "static asset data"? This is the part that gets mirrored far and wide. An instance of an asset would contain a reference to the static asset data and is where editable descriptions and permissions live. This part would live in agent inventories. Note that it is and should be possible to put metadata in with the static asset data, using any number of methods. How to handle creation and modification dates is something to think about. Is there any way to prove someone created a file at a certain time, without involving a trusted third party? I don't think there is... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071008/9ea440bc/attachment.pgp From secret.argent at gmail.com Mon Oct 8 21:07:21 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Oct 8 21:07:10 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191900602.29582.33.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> Message-ID: <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> On 08-Oct-2007, at 22:30, Callum Lerwick wrote: > No. Look at files on your disk. Metadata such as filename, its > permissions, creation dates etc, are not part of the file itself. Metadata, properties, whatever you call them. I think we're on the same page. The metadata on the asset in the original domain is managed using that domain's tools, but when it's copied the metadata on the copy is copied and maintained separately whether the reference to the original asset is cached or not. That way you can have a copy of a texture in your inventory and change the description on your copy without having to create a new asset and independently of whether you've got a cached copy of the asset data. So we have the following states: Master - This is what's referred to by the URL, and it's managed by the domain the asset server at that URL is in. Reference - This is what's maintained in the local domain. It has a copy of the metadata as it was when the reference was made. It may be updated if the local metadata isn't changed, but it doesn't have to be. Cache - This is a reference plus a locally cached copy of the metadata. Copy - a cache or a reference with the metadata modifiable and independent of the original. Equivalent to a copy in your inventory. Master Copy - a copy exported by an agent who has the rights to modify the original. Changes to the metadata on this copy may be reflected on the original when it's re-imported to the original domain, if that domain allows it. That way if you buy a new Little Mermaid Bra in Disney Domain you can change the description on your old pirated Little Mermaid bra so you can keep track of it when you get back to the Second Life domain, and if Second Life domain trusts Disney Domain that change will be applied to your original inventory. From zha.ewry at gmail.com Mon Oct 8 21:17:08 2007 From: zha.ewry at gmail.com (Zha Ewry) Date: Mon Oct 8 21:17:11 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> Message-ID: <920d7d850710082117v74472acfkdc0c29390fbc30bc@mail.gmail.com> All well and good. Note, however, that 90% of what you just described happens in the eco-system and not in the architecture, as its mostly happening to private reosurces which nobody else gets to see. On 10/9/07, Argent Stonecutter wrote: > > > On 08-Oct-2007, at 22:30, Callum Lerwick wrote: > > No. Look at files on your disk. Metadata such as filename, its > > permissions, creation dates etc, are not part of the file itself. > > Metadata, properties, whatever you call them. I think we're on the > same page. > > The metadata on the asset in the original domain is managed using > that domain's tools, but when it's copied the metadata on the copy is > copied and maintained separately whether the reference to the > original asset is cached or not. > > That way you can have a copy of a texture in your inventory and > change the description on your copy without having to create a new > asset and independently of whether you've got a cached copy of the > asset data. > > So we have the following states: > > Master - This is what's referred to by the URL, and it's managed by > the domain the asset server at that URL is in. > > Reference - This is what's maintained in the local domain. It has a > copy of the metadata as it was when the reference was made. It may be > updated if the local metadata isn't changed, but it doesn't have to be. > > Cache - This is a reference plus a locally cached copy of the metadata. > > Copy - a cache or a reference with the metadata modifiable and > independent of the original. Equivalent to a copy in your inventory. > > Master Copy - a copy exported by an agent who has the rights to > modify the original. Changes to the metadata on this copy may be > reflected on the original when it's re-imported to the original > domain, if that domain allows it. > > That way if you buy a new Little Mermaid Bra in Disney Domain you can > change the description on your old pirated Little Mermaid bra so you > can keep track of it when you get back to the Second Life domain, and > if Second Life domain trusts Disney Domain that change will be > applied to your original inventory. > > _______________________________________________ > 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/20071009/5637b18a/attachment.htm From dmahalko at gmail.com Mon Oct 8 21:37:20 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 8 21:37:22 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> Message-ID: On 10/8/07, Argent Stonecutter wrote: > It would be better just to require a low detail and a high detail mesh. > There might be a still better way to store shape data which hasn't been discovered yet. An interesting direction is to look at how TrueType / Postscript outline fonts are defined vs bitmap fonts. Perhaps it'd be possible to have a similar scale-free outline shape in 3D-space, defined via control points and handles, which has no specific predefined vertexes at all. This would be very low bandwidth since you just need to know a few anchor and control points to define a mathematically-perfect shape that could be built up on the fly out of thousands of triangles by the client's computer -- a sort of freeform prim. In this situation, LOD is just simply a question of how finely the client renderer decides to auto-generate a mesh to match that outline form, and a person on a slow computer can have the objects really roughly shaped while a fast quad-CPU system can go with ultra-fine meshes, all generated from the same base outline-shape. I don't know what the heck to even call this since nothing like it apparantly exists. Outline meshes? :-) - Scalar Tardis / Dale Mahalko From philip at lindenlab.com Mon Oct 8 21:42:33 2007 From: philip at lindenlab.com (Philip Rosedale) Date: Mon Oct 8 21:43:16 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> Message-ID: <470B06B9.1000402@lindenlab.com> Hi Dale, Some history, perhaps helpful... Sculpties (though not with the same name) were actually a broad idea we had first talked about way back at the beginning of LL - around 2001. I was personally really interested in using wavelet compression (which is the kernel in JPEG2000) to compress fixed topologies (prims) as a way of creating arbitrary shapes that could be streamed to the viewer at a speed adequate to allow 'flyover' of typical terrain/objects without falling behind. While it is true that using lossy compression against fixed vertices results in a object type with weaknesses when compared to full mesh descriptions, the difference in terms of compression is really enormous. Though I am not versed in the most recent forms of lossless arbitrary mesh compression, they are generally nowhere near the 10-100x compression that can easily be obtained with the lossy compressor/sculpties. BTW, we didn't do sculpties back in 2001 because it was lots of work and the additional CPU load for decode seemed like a bad idea for machines at the time. A great new developer (Karl) joined us recently and independently implemented something pretty identical and so we got the capability out there. I would consider full mesh compression to be an idea for the future, and as you say one would need to carefully restrict use so as not to have the full mesh prims badly slow the loading of other objects. Also, I think we need to work most on dramatically increasing the load time of scenes, which would make this disparity in download times all the more jarring. We have some ideas about how to greatly speed the loading of objects so that those 'flyovers' we dreamed about back then actually work with the current density of objects and textures in SL. Philip From seg at haxxed.com Mon Oct 8 22:27:28 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Oct 8 22:27:45 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470B06B9.1000402@lindenlab.com> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <470B06B9.1000402@lindenlab.com> Message-ID: <1191907648.29582.56.camel@localhost> On Mon, 2007-10-08 at 21:42 -0700, Philip Rosedale wrote: > We have some ideas about how to greatly speed the > loading of objects so that those 'flyovers' we dreamed about back then > actually work with the current density of objects and textures in SL. Putting a real world dollar value on virtual space, of course, is what encourages high density building. Unused virtual space is virtual wasted space that costs residents very real $$$, so they make do with as little land as they can. Of course the reality is, virtual space is exactly the thing that costs nothing. :) Its a lack of something. It takes no storage space, it takes no CPU time. Its the prims that take CPU time, storage space and bandwidth to maintain. Now if virtual space were real-world free, and builders were limited purely by prim count, people could spread out their builds, reducing load on just about every level. Inter-dimensional portal web plz. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/9838000f/attachment.pgp From hud at zurich.ibm.com Mon Oct 8 22:16:29 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 23:02:16 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1CDBE6DF-A343-426C-8C93-43C4C3E20798@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> <4709D18D.6070804@zurich.ibm.com> <1CDBE6DF-A343-426C-8C93-43C4C3E20798@gmail.com> Message-ID: <470B0EAD.4010904@zurich.ibm.com> Argent Stonecutter wrote: > On 08-Oct-2007, at 01:43, dirk husemann wrote: >> once you've published an asset, why would that then cause a problem? > > Because the UUID (or, in the long term, this URL) is used to reference > it from scripts and from references in assets and prims, so here you > are, you have a bunch of such secondary assets, and they're in an > attachment on your avatar... and you walk across a grid boundary from > one domain to another, get your attachment re-parented in the new > domain, turn around and walk back again... that stuff has to continue > working... even if someone else changes the texture description of the > "flaming sword" texture while you're over there. that would then just create a new texture, the old one would still be available and your scripts would still be able to refer to it. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Oct 8 22:33:03 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 23:02:43 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <470A2DB5.203@wsu.edu> Message-ID: <470B128F.8000007@zurich.ibm.com> Argent Stonecutter wrote: > On 08-Oct-2007, at 08:16, John Hurliman wrote: >> In the current model, only changing the asset data itself causes a >> new asset to be created. An asset consists of the data + metadata >> which includes name, description, and permissions. This works out >> pretty well because a lot of people might be running the same script, >> or the same notecard might be handed out to 500 different people, or >> a popular clothing item might be owned by a large number of people. >> In those cases where nothing has changed in the asset data, they all >> link to the same uuid to download the actual data but the metadata is >> different for each one (at a minimum the OwnerID is changed). >> >> That's just a description of the current model, but I think something >> similar might be a good approach for the future. > > Right, that metadata is what I'm referring to as "properties". ah, ok, i'm getting that one now. thx for the patience to explain! -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From gigstaggart at gmail.com Mon Oct 8 23:06:56 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Oct 8 23:06:53 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> Message-ID: <470B1A80.9020703@gmail.com> Dale Mahalko wrote: > I don't know what the heck to even call this since nothing like it > apparantly exists. Outline meshes? :-) > NURBS sounds like what you are talking about. Rendering them in realtime is potentially difficult. -Jason From gigstaggart at gmail.com Mon Oct 8 23:11:45 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Oct 8 23:11:43 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <1191907648.29582.56.camel@localhost> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <470B06B9.1000402@lindenlab.com> <1191907648.29582.56.camel@localhost> Message-ID: <470B1BA1.60407@gmail.com> Callum Lerwick wrote: > Now if virtual space were real-world free, and builders were limited > purely by prim count, people could spread out their builds, reducing > load on just about every level. It doesn't even need to be free. Larger sims would help this a ton. Other than a whole lot of code cleanup to yank out assumptions, there's no reason we couldn't have 1024x1024 sims, or whatever, with the same limits as a 256 sim has now. Openspaces almost help here, but the steep 100% increase on price/prim is hard for people to swallow (you only get 7500 prims for all 4 regions). -Jason From hud at zurich.ibm.com Mon Oct 8 23:25:16 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 23:25:20 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191900602.29582.33.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> Message-ID: <470B1ECC.5010707@zurich.ibm.com> Callum Lerwick wrote: > O[...] >> suggestion: asset: once created in-world is fixed. change permission, >> change description, change texture -> new asset. asset includes all >> properties. that way it can be cached without having to verify with the >> "originating" domain whether the creator has changed her mind... >> > > No. Look at files on your disk. Metadata such as filename, its > permissions, creation dates etc, are not part of the file itself. > Changing the filename or its permissions does not change the file > contents. What I've been calling an Asset is analogous to the contents > of a file. How about if we call it a "static asset data"? This is the > part that gets mirrored far and wide. An instance of an asset would > contain a reference to the static asset data and is where editable > descriptions and permissions live. This part would live in agent > inventories. > yep, got it! :-) "asset = data + meta data" made the penny drop in my case. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071009/ea7d3200/attachment.htm From dmahalko at gmail.com Mon Oct 8 23:55:51 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Oct 8 23:55:53 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470B1A80.9020703@gmail.com> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> Message-ID: On 10/9/07, Jason Giglio wrote: > NURBS sounds like what you are talking about. Rendering them in > realtime is potentially difficult. It's not necessarily the same thing, because NURBS is usually ridiculously high detail with a very dense sheet of control points. Having thousands of control points across a scene is acceptable for something like Maya since render time isn't really constrained and rendering precision is more important than render speed. If raytracing a dense scene takes a day per frame for a professional 3D editor, oh well. What I'm talking about would use just the minimal number of anchors and control points to define the surface of a shape, to be as bandwidth-efficient as possible. To reduce processing load, calculation of a mesh for the outline surface might only be a one-shot process when the outline shape loads for the first time on the client. The client could pre-generate and locally cache just three or four stepped-LOD mesh versions, and use the cached meshes whenever the shape is needed. This way the client isn't repeatedly regenerating a new mesh for every frame. If game companies could figure out a way to implement outline shapes/surfaces, then 3D games wouldn't becomes "dated" so quickly. The triangle density for an old game could progressively improve to match the capability of better and faster new hardware, without needing to go back and re-edit raw vertex models to manually add more triangle detail. - Scalar Tardis / Dale Mahalko From hud at zurich.ibm.com Mon Oct 8 23:58:40 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Oct 8 23:59:07 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> Message-ID: <470B26A0.2070704@zurich.ibm.com> Argent Stonecutter wrote: > > On 08-Oct-2007, at 22:30, Callum Lerwick wrote: >> No. Look at files on your disk. Metadata such as filename, its >> permissions, creation dates etc, are not part of the file itself. > > Metadata, properties, whatever you call them. I think we're on the > same page. > > The metadata on the asset in the original domain is managed using that > domain's tools, but when it's copied the metadata on the copy is > copied and maintained separately whether the reference to the original > asset is cached or not. > > That way you can have a copy of a texture in your inventory and change > the description on your copy without having to create a new asset and > independently of whether you've got a cached copy of the asset data. > > So we have the following states: > > Master - This is what's referred to by the URL, and it's managed by > the domain the asset server at that URL is in. > > Reference - This is what's maintained in the local domain. It has a > copy of the metadata as it was when the reference was made. It may be > updated if the local metadata isn't changed, but it doesn't have to be. > > Cache - This is a reference plus a locally cached copy of the metadata. > > Copy - a cache or a reference with the metadata modifiable and > independent of the original. Equivalent to a copy in your inventory. > > Master Copy - a copy exported by an agent who has the rights to modify > the original. Changes to the metadata on this copy may be reflected on > the original when it's re-imported to the original domain, if that > domain allows it. just trying to rephrase in terms of data + meta data: master: original data + original meta data on original asset server reference: reference to data + copy of original meta data, meta data can be freshed (on local domain) cache: copy of data + copy of original meta data (in client?) copy: copy or reference to data + modifiable metadata master copy: exported modified copy of data + exported modified meta data (assuming agent may modify), may update master. i'm a bit unclear on copy and master copy: - copy: currently when i have a no-modify object i cannot rename for example, are you proposing to allow an agent to rename? how about permissions? - master copy: if it's a copy that's been modified, then that should really be a new asset. how about we just follow what john's been suggesting: asset = data + meta data. whoever needs to cache, copies data + meta data. whoever wants to modify the meta data does so IFF the permissions allow for that. meta data always contains reference to original meta data. if i modify the data, i get a new asset. wouldn't that be all that we need to define from an architecture point of view? bear with me if i'm too dense again, please... -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From seg at haxxed.com Tue Oct 9 00:24:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Oct 9 00:24:27 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470B1A80.9020703@gmail.com> References: <46FD090B.1030805@lindenlab.com> <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> Message-ID: <1191914649.29582.82.camel@localhost> On Tue, 2007-10-09 at 02:06 -0400, Jason Giglio wrote: > Dale Mahalko wrote: > > I don't know what the heck to even call this since nothing like it > > apparantly exists. Outline meshes? :-) > > > > NURBS sounds like what you are talking about. Rendering them in > realtime is potentially difficult. From what my friend tells me (Who's in school for Maya) NURBS can be tricky to deal with, just from a modeler's point of view. Maya seems to be all about the NURBS, though. (I've never really used Maya. I've used Lightwave quite a bit in the past though, starting with Video Toaster 4000 up to LW7 :) Subpatch modeling like Lightwave does seems simpler and much more intuitive. I even found an LGPL implementation, though it seems its in C#: http://www.kevs3d.co.uk/k3d2.html There's even an example of how subpatch can support LOD. You can get some nice smooth models with relatively few actual polygons. Just a control mesh and a weight per vertex: http://www.newtek.com/products/lightwave/tutorials/modeling/car/index22.html http://www.chrisevans3d.com/tutorials/weights.htm http://www.the123d.com/tutorial/lightwave4/form-down01.shtml (Lightwave 9 apparently has some new Subdivision thing that I'm not at all clear how it differs from Subpatches...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/1cd54cd8/attachment.pgp From secret.argent at gmail.com Tue Oct 9 03:22:15 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 9 03:22:02 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <920d7d850710082117v74472acfkdc0c29390fbc30bc@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <920d7d850710082117v74472acfkdc0c29390fbc30bc@mail.gmail.com> Message-ID: <4501CA67-B452-4253-BE5A-878124D49E5C@gmail.com> On 08-Oct-2007, at 23:17, Zha Ewry wrote: > All well and good. Note, however, that 90% of what you just > described happens in the eco-system and not in the architecture, as > its mostly happening to private reosurces which nobody else gets to > see. The meaning of TCP/IP port numbers are not part of TCP/IP architecture, they're only meaningful to applications using TCP/IP, however those port numbers are still defined in IP standards. So 100% of it has to be supported by the architecture. * The distinction between asset and metadata has to be exposed in the architecture. * The trust relationships have to be supported by the architecture. * The model has to be explicit in the architecture so that implementations agree on what metadata means. From secret.argent at gmail.com Tue Oct 9 03:25:57 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 9 03:25:42 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470B0EAD.4010904@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <1191709820.26663.133.camel@localhost> <07491B25-2B03-468C-9E77-866F2D559688@gmail.com> <4709D18D.6070804@zurich.ibm.com> <1CDBE6DF-A343-426C-8C93-43C4C3E20798@gmail.com> <470B0EAD.4010904@zurich.ibm.com> Message-ID: <35DDAD49-D175-43D8-A37F-D7AE233788A8@gmail.com> On 09-Oct-2007, at 00:16, dirk husemann wrote: > that would then just create a new texture, the old one would still be > available and your scripts would still be able to refer to it. The old one is not necessarily going to be available if assets are garbage collected. SL assets are in fact garbage collected. From secret.argent at gmail.com Tue Oct 9 03:37:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 9 03:36:56 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470B26A0.2070704@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> Message-ID: <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> On 09-Oct-2007, at 01:58, dirk husemann wrote: > master: original data + original meta data on original asset server > reference: reference to data + copy of original meta data, meta > data can > be freshed (on local domain) > cache: copy of data + copy of original meta data (in client?) caches will exist all over the place, even internally in a domain... in a region host, in an asset server of a domain the object has been carried to, in the client. > copy: copy or reference to data + modifiable metadata > master copy: exported modified copy of data + exported modified meta > data (assuming agent may modify), may update master. master copy: exported copy or reference to data + modifiable metadata, may update master. > copy: currently when i have a no-modify object i cannot rename for > example, are you proposing to allow an agent to rename? how about > permissions? * Permissions are inherently advisory between domains. * Some metadata, like owner and group, can always be modified even if the object is no-mod. > - master copy: if it's a copy that's been modified, then that should > really be a new asset. No, only the metadata is modified. The master copy is simply a copy that has only passed through domains that trust each other to restrict metadata changes to reflect the same permissions model. > how about we just follow what john's been suggesting: asset = data + > meta data. whoever needs to cache, copies data + meta data. > whoever wants to modify the meta data does so IFF the permissions > allow > for that. meta data always contains reference to original meta > data. if > i modify the data, i get a new asset. At no point in any of the quoted material did I suggest modifying the data. I was simply describing relationships between references, cached copies, and metadata. From hud at zurich.ibm.com Tue Oct 9 05:42:24 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 9 05:42:55 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> Message-ID: <470B7730.9000202@zurich.ibm.com> Argent Stonecutter wrote: > On 09-Oct-2007, at 01:58, dirk husemann wrote: > [...] >> copy: copy or reference to data + modifiable metadata >> master copy: exported modified copy of data + exported modified meta >> data (assuming agent may modify), may update master. > > master copy: exported copy or reference to data + modifiable metadata, > may update master. > >> copy: currently when i have a no-modify object i cannot rename for >> example, are you proposing to allow an agent to rename? how about >> permissions? > > * Permissions are inherently advisory between domains. > * Some metadata, like owner and group, can always be modified even if > the object is no-mod. even if it's no-transfer? i'm still struggling with the master copy concept: is the scenario that you take some object with you to a "foreign" domain (i.e., you copy it to the foreign domain), you modify the metadata of that object in that foreign domain and then want to have those changes reflected back to your native domain? i can see where i'd want this for stuff i wear. what about stuff i leave behind? or is this only applicable to worn objects? cheers, dirk/dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From mark.burhop at gmail.com Tue Oct 9 06:58:47 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Tue Oct 9 06:58:50 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <1191914649.29582.82.camel@localhost> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> <1191914649.29582.82.camel@localhost> Message-ID: <773a33dc0710090658s79250fbax6ebdf917441bcddf@mail.gmail.com> > > > > > NURBS sounds like what you are talking about. Rendering them in > > realtime is potentially difficult. > > From what my friend tells me (Who's in school for Maya) NURBS can be > tricky to deal with, just from a modeler's point of view. So maybe you are talking Brep (boundary representation). The first step is a bounded set of edges to create faces. bounded faces create "bodies". See http://en.wikipedia.org/wiki/Boundary_representation the the edge defintion sticks to "analytics" all you really pass is a math equation descripting the edges. LOD is determined by the client. - Burhop -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071009/b4d12783/attachment.htm From wiggo at lindenlab.com Tue Oct 9 07:19:36 2007 From: wiggo at lindenlab.com (Matthew Wiggins) Date: Tue Oct 9 07:19:47 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> Message-ID: <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Regarding a patching updater for the distributed viewer , there is an internal task to do just that, which I've now linked to a related PJIRA task: http://jira.secondlife.com/browse/VWR-603. I'm planning to resolve this as soon as possible. As you've rightly pointed out, there is a significant amount of non- changing data between releases so we should be able to cut the size of updates by a large amount. As Bushing Spatula has found on that VVR-603, getting to a 12MB delta is easily achievable. The main challenge is producing a system that works on all three platforms in a pleasing way for the user, and plays nicely with our versioning process. I'll post more once I've moved onto that task from current bug-fixing work. On 5 Oct 2007, at 13:32, Robin Cornelius wrote: > On 10/1/07, Bryan O'Sullivan wrote: >> Callum Lerwick wrote: >> >>> Which is why LL should focus on working with Linux distributions >>> to get >>> Second Life into the distributions themselves, rather than >>> distributing >>> binary blobs. >> >> We're happy to see people packaging the viewer for different Linux >> distributions (for example, I'm watching the Fedora packaging tasks), >> and willing to help out where we can. I've done quite a bit of >> work to >> make it easier to build a standalone viewer, for example. >> >> If there are specific things you'd like to see done, file JIRA tasks, >> and we'll plug away at them as the opportunity presents itself. >> If you >> want to file an umbrella task and connect the subtasks to it so that >> it's easier to see which ones are intended to ease distro >> integration, >> all the better. > > Coming back to this thread, ATM the viewer is an enormous tar ball and > I know there are a few of us now doing our own builds with various > different patchsets for different arch's. > > Can we maybe think about splitting up the viewer (distribution) into > smaller packages. Surely the various artwork and supplied textures > remain pretty constant and it seems wasteful redistributing the same > data over and over again. > > If we can come up with a basic structure for grouping files then this > will make packaging the viewer for rpm/deb or even different tar.bz2s > easier and certainly makes distribution easier. Possibly even on > windows or mac distribute smaller files or have an automated > update/installer that can just pull the required package(s). > > One of the main questions is anybody have a feel for how static > various files are. I am sure the various translations and languages > are being adjusted fairly frequently with addition of new features and > corrections but what about all the artwork, that must almost be static > across many versions. > > As a bare minimum the viewer splits up into a common arch independent > package and a secondlife-official-1.18.4-amd64 etc package, this > would also allow easy deployment of multiple viewers and 3rd party > viewers if we all use the same basic system in packages. (Thanks for > the discussion Julie). I am wondering if infact it should split even > further with the language files in one package, various artwork in > others, main binary in another etc. > > I am not sure at this point how this effects anything LL are doing to > the code base. Its more a policy decision for packagers distributing a > viewer. For the moment any body have any objections to creating a wiki > page to outline a packaging policy so at least we can all work from > the same sheet if we are deploying our own builds of the viewers. > > Where it does effect LL is i suppose that we want minimum changes from > upstream code to the version packaged, so we really don't want to have > to move files around everywhere and greatly change the code base. So > to achieve this would require a better build and moving to a more > standard makefile so we can do various build steps with just make, eg > make all, make viewer-tarball or what ever? This is quite a big step > so anybody have any thoughts on that. > > Regards > > Robin > _______________________________________________ > 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 Oct 9 07:30:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 9 07:31:34 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470B7730.9000202@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> Message-ID: <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> On 09-Oct-2007, at 07:42, dirk husemann wrote: > even if it's no-transfer? Sure, what does that have to do with it? > i'm still struggling with the master copy concept: is the scenario > that > you take some object with you to a "foreign" domain (i.e., you copy it > to the foreign domain), you modify the metadata of that object in that > foreign domain and then want to have those changes reflected back to > your native domain? Sure. > i can see where i'd want this for stuff i wear. what about stuff i > leave > behind? or is this only applicable to worn objects? It can apply to stuff you never even rez in that domain. You might make a change to something in your inventory in a domain that has the same trust level as the original domain, you don't want those changes lost when you return. From secret.argent at gmail.com Tue Oct 9 07:53:43 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Oct 9 07:53:28 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Message-ID: On 09-Oct-2007, at 09:19, Matthew Wiggins wrote: > As you've rightly pointed out, there is a significant amount of non- > changing data between releases so we should be able to cut the size > of updates by a large amount. As Bushing Spatula has found on that > VVR-603, getting to a 12MB delta is easily achievable. The main > challenge is producing a system that works on all three platforms > in a pleasing way for the user, and plays nicely with our > versioning process. You could use rsync. :) Actually, only half :). It might work. From 1337mail at gmail.com Tue Oct 9 09:52:22 2007 From: 1337mail at gmail.com (Michael Miller) Date: Tue Oct 9 09:52:25 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> Message-ID: <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> Right, Apple said to remove the lines and the project will open(I haven't had a chance to try this yet.) The question, and what Apple wants to know, is why it got broken. This is likely the real bug(unless the project was hand-edited by a person). If anyone knows why this happened, please reply; Apple needs to fix this bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071009/a1abed71/attachment-0001.htm From rdw at lindenlab.com Tue Oct 9 10:54:26 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Tue Oct 9 10:54:47 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> Message-ID: <470BC052.9080103@lindenlab.com> Michael Miller wrote: > Right, Apple said to remove the lines and the project will open(I > haven't had a chance to try this yet.) The question, and what Apple > wants to know, is why it got broken. This is likely the real > bug(unless the project was hand-edited by a person). If anyone knows > why this happened, please reply; Apple needs to fix this bug. > We edit the xcode file with a script during the export process. That's what Phoenix was alluding to in his previous email. I'm not too familiar with the script, but from my vantage point, I would guess that it's probably our bug and not Apple's. -RYaN From dzonatas at dzonux.net Tue Oct 9 11:53:56 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 9 11:53:53 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> Message-ID: <470BCE44.80401@dzonux.net> Dale Mahalko wrote: > If game companies could figure out a way to implement outline > shapes/surfaces, then 3D games wouldn't becomes "dated" so quickly. > The triangle density for an old game could progressively improve to > match the capability of better and faster new hardware, without > needing to go back and re-edit raw vertex models to manually add more > triangle detail. > This is the fear that game companies have that are dependent upon graphic cards as they have been. The new real-time raytracing hardware can do what you say. The triangular faced mesh does not need to exist in a ray-traced scene. LOD becomes more of critical prims to display in RT rather than re-sampled meshs. Also, far distant meshs in non-RT are more computational then RT scenes. The graphic card companies have attempted to create special RT hardware as a hybrid move on the cards so they can capture the RT audience, but it still is not pure RT. The main factor for very dense RT scenes is the memory bandwidth. With even hybrid RT on the graphics card, it creates a demand to greatly increase memory on that card to make it even useful. People will start to ask, why can't the graphics card just use the main memory, so then I can just buy main memory and make it all useful for even non graphical apps?!?!? One way to increase loading time is to get rid of the graphic card bandwidth bottleneck, and go with RT models on the main CPU where memory can be dynamically accessed faster. -- Power to Change the Void From 1337mail at gmail.com Tue Oct 9 11:57:05 2007 From: 1337mail at gmail.com (Michael Miller) Date: Tue Oct 9 11:57:07 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: <470BC052.9080103@lindenlab.com> References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> <470BC052.9080103@lindenlab.com> Message-ID: <2c99c46e0710091157s1cf1a231o90a92895591246ab@mail.gmail.com> Ryan,Can you get a confirmation on that? Apple specifically requested that I reply with more information. On 10/9/07, Ryan Williams wrote: > > Michael Miller wrote: > > Right, Apple said to remove the lines and the project will open(I > > haven't had a chance to try this yet.) The question, and what Apple > > wants to know, is why it got broken. This is likely the real > > bug(unless the project was hand-edited by a person). If anyone knows > > why this happened, please reply; Apple needs to fix this bug. > > > We edit the xcode file with a script during the export process. That's > what Phoenix was alluding to in his previous email. I'm not too > familiar with the script, but from my vantage point, I would guess that > it's probably our bug and not Apple's. > > -RYaN > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071009/7853ee7e/attachment.htm From ettore_pasquini at 3dconnexion.com Tue Oct 9 13:02:43 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Tue Oct 9 13:02:39 2007 Subject: [sldev] [VWR] How to "commit" translations in Build mode? Message-ID: I added a method to LLSelectMgr to translate the selected objects by a given vector in Build mode. The motion per se happens correctly, but when I release the objects (i.e. unselect them) they bounce back to the original location. What's more puzzling is that rotations *are* "committed" correctly. I don't understand why translations would require a different treatment. How to "commit" them to the new position? This is my code (extracted and adapted from LLSelectMgr::sendListToRegions) : LLViewerRegion *last_region, *current_region; S32 objects_sent = 0, packets_sent = 0, objects_in_this_packet = 0; current_region = node->getObject()->getRegion(); // prepare first bulk message gMessageSystem->newMessage("MultipleObjectUpdate"); packAgentAndSessionID(&update_type); for (LLViewerObject *obj; node; node = mSelectedObjects->getNextRootNode()) { obj = node->getObject(); if (update_position) obj->setPosition(obj->getPositionEdit() + displ_global); if (update_rotation) obj->setRotation(obj->getRotationEdit() * new_rot); if (obj->mDrawable.notNull()) gPipeline.markMoved(obj->mDrawable, TRUE); // remember the last region, look up the current one last_region = current_region; current_region = obj->getRegion(); // if to same simulator and message not too big if ((current_region == last_region) && (! gMessageSystem->isSendFull(NULL)) && (objects_in_this_packet < MAX_OBJECTS_PER_PACKET)) { // add another instance of the body of the data packMultipleUpdate(node, &update_type); ++objects_sent; ++objects_in_this_packet; } else { // otherwise send current message and start new one gMessageSystem->sendReliable(last_region->getHost()); packets_sent++; objects_in_this_packet = 0; gMessageSystem->newMessage("MultipleObjectUpdate"); packAgentAndSessionID(&update_type); } } Thanks, Ettore From monkowsk at watson.ibm.com Tue Oct 9 13:09:27 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Oct 9 13:10:27 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470BCE44.80401@dzonux.net> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> <470BCE44.80401@dzonux.net> Message-ID: <470BDFF7.8050408@watson.ibm.com> Dzonatas wrote: > People will start to ask, > why can't the graphics card just use the main memory, so then I can just > buy main memory and make it all useful for even non graphical apps?!?!? Intel chipsets do that, but unfortunately, Intel is way behind on graphics capabilities. Mike From dale at daleglass.net Tue Oct 9 14:47:53 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Oct 9 14:48:09 2007 Subject: [sldev] [VWR] How to "commit" translations in Build mode? In-Reply-To: References: Message-ID: <200710092348.03505.dale@daleglass.net> On Tuesday 09 October 2007 22:02:43 Ettore Pasquini wrote: > I added a method to LLSelectMgr to translate the selected objects by a > given vector in Build mode. The motion per se happens correctly, but > when I release the objects (i.e. unselect them) they bounce back to the > original location. What's more puzzling is that rotations *are* > "committed" correctly. I don't understand why translations would require > a different treatment. How to "commit" them to the new position? > This is my code (extracted and adapted from > LLSelectMgr::sendListToRegions) Ok, at first glance: You're packing multiple updates in one packet. If you reach the limit, or change simulator, you send the current packet and start a new one. Except, you don't send whatever remains buffered after the loop ends. If for example you have only one update queued then it gets added to the message system, loop ends, and message doesn't get sent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/d1c570b2/attachment.pgp From seg at haxxed.com Tue Oct 9 15:03:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Oct 9 15:03:29 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470BDFF7.8050408@watson.ibm.com> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> <470BCE44.80401@dzonux.net> <470BDFF7.8050408@watson.ibm.com> Message-ID: <1191967391.29582.101.camel@localhost> On Tue, 2007-10-09 at 16:09 -0400, Mike Monkowski wrote: > Dzonatas wrote: > > People will start to ask, > > why can't the graphics card just use the main memory, so then I can just > > buy main memory and make it all useful for even non graphical apps?!?!? > > Intel chipsets do that, but unfortunately, Intel is way behind on > graphics capabilities. Actually, their chipsets seem to be keeping up rather well as far as feature set. They seem to be the reason Mesa supports OpenGL 2.x. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/1311ede0/attachment.pgp From agrimes at speakeasy.net Tue Oct 9 15:45:07 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Tue Oct 9 15:45:13 2007 Subject: [sldev] WTF happened to my texture? Message-ID: <470C0473.7060301@speakeasy.net> SL has a problem with text. You can't work with it affordably in-world. You have to pay to upload each one and then to read it, you have to sit and wait for 20 minutes (okay 5..) for the damn thing to rez before you can read it. The simpleton's solution to that is to upload a single texture, a codepage, and then create letters by mapping different parts of that codepage to prims. -- too obvious, huh? Alright, I fired up my old DOS computer. (Yes, I have a DOS computer) and snagged myself my favorite font library. I then wrote a program to extract the code page I wanted. 437 FOREVER!!! It produced a nice little bmp file, 4158 bytes to be exact... SL didn't like that so I made a PNG of it so that it wouldn't get corrupted, 3193 bytes. -- pretty nice, huh? =P (see attached, have a look at it and then tell me 437 isn't the best codepage ever!!!). (image specs: 128 x 256 x 1 bit) The whole point is to make an in-world font system that will be __FAST__, I mean rez as much text as you like in microseconds!!! I was thinking oh boy, this'll make me a fortune in lindens!!! -- ignoring the fact that the linden is devaluing right along with the dollar. =( Then I PAID LINDENS TO UPLOAD IT!!!! =| You see, this scheme only works if the font can be uploaded and relayed to the client in a lossless way. -- being only 3kb, this didn't seem like an unreasonable demand... But what I got back seemed to be 256x512, and then downsized to the origional... It also seems to have been converted to 24 bit, -- an unspeakable waste for this application, and finally, some kind of smoothing operation was performed!!!! -- It may just be that the GL_LINEAR texture filter was left on... =\ The final result is totally unusable as a font system. =( When I cough up L$10 to upload a texture I damn well expect that what I get back is what I uploaded!! =\ BTW, Ron Paul has an in-world pavilion. -- Buy Ron Paul's Money! =) http://www.libertydollar.org/ld/ronpauldollar Soundest investment on the planet! -------------- next part -------------- A non-text attachment was scrubbed... Name: iso437.png Type: image/png Size: 3193 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/62c05c71/iso437.png From gigstaggart at gmail.com Tue Oct 9 15:58:12 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Oct 9 15:58:09 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <470C0473.7060301@speakeasy.net> References: <470C0473.7060301@speakeasy.net> Message-ID: <470C0784.20302@gmail.com> Alan Grimes wrote: > SL has a problem with text. You know about XyText and XyzzyText... right? Anyway, your problem was you need to resize the image to 512x512 before uploading it. You can use it at whatever aspect ratio you want later by setting the texture repeats parameter of the prim face. Right now it always rounds down to the next power of two. It probably should go for the closer power of 2 isntead of always rounding down, but that's a minor issue. From dzonatas at dzonux.net Tue Oct 9 15:59:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Oct 9 15:59:40 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470B7730.9000202@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> Message-ID: <470C07D4.6010809@dzonux.net> dirk husemann wrote: > i'm still struggling with the master copy concept: is the scenario that > you take some object with you to a "foreign" domain (i.e., you copy it > I'm familiar with the concepts, but I tend to put new words to them because the older terms just confuse. I don't blame you to nail these down! Side note to all: One scheme I use a lot is to add standard prefixes and suffixes to words. Some have complained like "but but that [new] word is not in the dictionary," but technically it is not new and the dictionary would be humongous if it listed every possible combination of prefixes and suffixes onto root words. One pet peeve I have is not to use "parent" or "child" unless one is truly refers to a human bonded relationship. Also, I don't use the word "container" to describe objects being inside or outside one another. The confusion starts when ones starts to refer a "parent" object of another "object" that is actually "contained" in another object. Those kind of relationships can be simplified with "intra-" and "inter-". For example, "intrassets" and "interassets". You can probably see already how that saves some discussion on where assets are and how they are referenced or copied. One I combination I have used a lot is "intramodule" and "intermodule". Those simply show how modules communicate with each other. Of course, there always could be "extramodular" communication. Those are pretty simple, I'll save for now my really in-depth created names that probably only mean something to me, like intratomization which is like rezzing and interatomorphics which is like polymorphed code being compile-time or run-time linked. -- Power to Change the Void From josh at lindenlab.com Tue Oct 9 16:43:00 2007 From: josh at lindenlab.com (Joshua Bell) Date: Tue Oct 9 16:45:11 2007 Subject: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.) In-Reply-To: <4705CAB9.4080401@zurich.ibm.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> <4705CAB9.4080401@zurich.ibm.com> Message-ID: <470C1204.9040500@lindenlab.com> Felix Wakmann posted some brainstorms about a "robots.txt" for SL here: http://www.your2ndplace.com/node/417 in the context of allowing parcel owners to communicate with the SLBrowser spider bots to limit what is searched, just as robots.txt does for the web. That link was pointed out to me during a panel discussion on in-world search, and might be a good place to start. We were discussing it in the guise of search (i.e. classic robots.txt) where the idea is to limit content indexing, and thus not limited to bots but also to spidering tools that may work through (or as) APIs (e.g. the ones we're working on as part of the search project to expose content as HTML). dirk husemann wrote: > how about introducing a "bots.txt" file? currently we have no way of > telling a bot whether he is allow on a property (or what he is allowed > to do). this is not going to deter "ill-behaving" bots from just > ignoring whatever "bots.txt" tells them to do (or not do) --- but at > least a parcel owner can cleary express her wishes & rules. > > this could go into the parcel properties stuff and consist of a couple > of rules: > > * bots (not) allowed on this parcel > o bots (not) allowed above XXXm > o bots (not) allowed below XXXm > * bots (not) allowed to collect information > o items for sale > o texture information > o prim information > o avatars present > > well-behaving bots (e.g., bots owned by well-known companies) would > honor those settings. > > cheers, > dirk aka dr scofield > -- > dr dirk husemann, pervasive computing, ibm zurich research lab > --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Tue Oct 9 17:34:25 2007 From: soft at lindenlab.com (Soft) Date: Tue Oct 9 17:34:27 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: <470BC052.9080103@lindenlab.com> References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> <470BC052.9080103@lindenlab.com> Message-ID: On 10/9/07, Ryan Williams wrote: > Michael Miller wrote: > > Right, Apple said to remove the lines and the project will open(I > > haven't had a chance to try this yet.) The question, and what Apple > > wants to know, is why it got broken. This is likely the real > > bug(unless the project was hand-edited by a person). If anyone knows > > why this happened, please reply; Apple needs to fix this bug. > > > We edit the xcode file with a script during the export process. That's > what Phoenix was alluding to in his previous email. I'm not too > familiar with the script, but from my vantage point, I would guess that > it's probably our bug and not Apple's. This looks like an XCode bug to me. XCode drops valid target sections after the lldku target section, once the llkdu target section comes up with no available files. From soft at lindenlab.com Tue Oct 9 17:36:04 2007 From: soft at lindenlab.com (Soft) Date: Tue Oct 9 17:36:06 2007 Subject: [sldev] XCode bug - please help figure out why In-Reply-To: References: <2c99c46e0710081300v1f377479x992c350e4f801436@mail.gmail.com> <2c99c46e0710090952y6ef5bce7lef400ea336f983e2@mail.gmail.com> <470BC052.9080103@lindenlab.com> Message-ID: On 10/9/07, Soft wrote: > On 10/9/07, Ryan Williams wrote: > > Michael Miller wrote: > > > Right, Apple said to remove the lines and the project will open(I > > > haven't had a chance to try this yet.) The question, and what Apple > > > wants to know, is why it got broken. This is likely the real > > > bug(unless the project was hand-edited by a person). If anyone knows > > > why this happened, please reply; Apple needs to fix this bug. > > > > > We edit the xcode file with a script during the export process. That's > > what Phoenix was alluding to in his previous email. I'm not too > > familiar with the script, but from my vantage point, I would guess that > > it's probably our bug and not Apple's. > > This looks like an XCode bug to me. XCode drops valid target sections > after the lldku target section, once the llkdu target section comes up > with no available files. btw - save a freshly checked-out project file, load and exit XCode without making any changes to the project, then compare the resulting project file to see the damage. From lenglish5 at cox.net Tue Oct 9 15:36:42 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Oct 9 19:43:55 2007 Subject: [sldev] [VWR] How to "commit" translations in Build mode? In-Reply-To: <200710092348.03505.dale@daleglass.net> References: <200710092348.03505.dale@daleglass.net> Message-ID: <470C027A.1060109@cox.net> Dale Glass wrote: > On Tuesday 09 October 2007 22:02:43 Ettore Pasquini wrote: > >> I added a method to LLSelectMgr to translate the selected objects by a >> given vector in Build mode. The motion per se happens correctly, but >> when I release the objects (i.e. unselect them) they bounce back to the >> original location. What's more puzzling is that rotations *are* >> "committed" correctly. I don't understand why translations would require >> a different treatment. How to "commit" them to the new position? >> This is my code (extracted and adapted from >> LLSelectMgr::sendListToRegions) >> > Ok, at first glance: > > You're packing multiple updates in one packet. If you reach the limit, or > change simulator, you send the current packet and start a new one. > > Except, you don't send whatever remains buffered after the loop ends. If > for example you have only one update queued then it gets added to the > message system, loop ends, and message doesn't get sent. > This ties in with the jira request for the ability to "build" particle effects. Is there a similar way to update particle effects before the building process ends? L. From seg at haxxed.com Tue Oct 9 20:28:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Oct 9 20:28:29 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> Message-ID: <1191986888.29582.112.camel@localhost> On Tue, 2007-10-09 at 09:30 -0500, Argent Stonecutter wrote: > It can apply to stuff you never even rez in that domain. You might > make a change to something in your inventory in a domain that has the > same trust level as the original domain, you don't want those changes > lost when you return. I don't know what you're even on about here. Your inventory lives in the *Agent* domain, its not moving anywhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071009/455dafde/attachment.pgp From jhurliman at wsu.edu Tue Oct 9 21:17:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Oct 9 21:17:44 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <470C0784.20302@gmail.com> References: <470C0473.7060301@speakeasy.net> <470C0784.20302@gmail.com> Message-ID: <470C525E.5050603@wsu.edu> Jason Giglio wrote: > Alan Grimes wrote: >> SL has a problem with text. > > You know about XyText and XyzzyText... right? > > Anyway, your problem was you need to resize the image to 512x512 > before uploading it. You can use it at whatever aspect ratio you want > later by setting the texture repeats parameter of the prim face. > > Right now it always rounds down to the next power of two. It probably > should go for the closer power of 2 isntead of always rounding down, > but that's a minor issue. You could also use SLImageUpload and upload lossless for something like that where you don't want the client to download four different quality levels or so of the image. From agrimes at speakeasy.net Tue Oct 9 21:49:43 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Tue Oct 9 21:49:57 2007 Subject: [sldev] OMG, my image was de-rezed!!! Message-ID: <470C59E7.9080309@speakeasy.net> After I wrote my last e-mail, I wandered around, when I got back my text test prim had been de-rezed to 128x128 from 256x256 !!!!!!! W H A T !!!!!!! My image that was posted at origonal size was de-rezed to 64x128, no wonder it is illegable, it has half the pixels it needs... In the background is one of my ron-paul yard posters which looks crystal clear... What gives? I pay L$10 to upload a 1.3kb file and your server decides it can't handle 1.3kb and crops it down to half the resolution??? WHAT THE ....!!!!!! Oh well, while I'm pissing away lindens, I'll make a 256x512 version... =\ =P Looks like I tricked it into working. The big smiley face looks a bit blurry but that's what you get when you put an 8x16 sub-texture on a 5x10 prim face. =P Suggested new policy: L$1/killobyte and the server keeps a lossless copy. -- Buy Ron Paul's Money! =) http://www.libertydollar.org/ld/ronpauldollar Soundest investment on the planet! From sl at phoca.com Tue Oct 9 23:02:20 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Oct 9 23:02:34 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <470C525E.5050603@wsu.edu> References: <470C0473.7060301@speakeasy.net> <470C0784.20302@gmail.com> <470C525E.5050603@wsu.edu> Message-ID: <71D362098B64405794AEF54BBB6B1828@SanMiguel> Except that that would be MUCH larger a file with much more info to DL than even the 4 LODs since that file probably gets a good 10:1 compression. It would take at least 5x as long to DL the uncompressed image vs even the 4 LOD compressed versions. Uploading large uncompressed textures to SL is not a good idea... almost (if not completely) ever. Farallon ----- Original Message ----- From: "John Hurliman" To: Sent: Tuesday, October 09, 2007 9:17 PM Subject: Re: [sldev] WTF happened to my texture? > Jason Giglio wrote: >> Alan Grimes wrote: >>> SL has a problem with text. >> >> You know about XyText and XyzzyText... right? >> >> Anyway, your problem was you need to resize the image to 512x512 before >> uploading it. You can use it at whatever aspect ratio you want later by >> setting the texture repeats parameter of the prim face. >> >> Right now it always rounds down to the next power of two. It probably >> should go for the closer power of 2 isntead of always rounding down, but >> that's a minor issue. > > You could also use SLImageUpload and upload lossless for something like > that where you don't want the client to download four different quality > levels or so of the image. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From hud at zurich.ibm.com Tue Oct 9 23:07:06 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Oct 9 23:07:11 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> Message-ID: <470C6C0A.2090502@zurich.ibm.com> Argent Stonecutter wrote: > On 09-Oct-2007, at 07:42, dirk husemann wrote: >> even if it's no-transfer? > > Sure, what does that have to do with it? you wrote: > * Permissions are inherently advisory between domains. > * Some metadata, like owner and group, can always be modified even if > the object is no-mod. > if yo change owner & group, doesn't that constitute a transfer? with a no-transfer asset you'd go against the wishes of the creator then. >> i'm still struggling with the master copy concept: is the scenario that >> you take some object with you to a "foreign" domain (i.e., you copy it >> to the foreign domain), you modify the metadata of that object in that >> foreign domain and then want to have those changes reflected back to >> your native domain? > > Sure. OK. > >> i can see where i'd want this for stuff i wear. what about stuff i leave >> behind? or is this only applicable to worn objects? > > It can apply to stuff you never even rez in that domain. You might > make a change to something in your inventory in a domain that has the > same trust level as the original domain, you don't want those changes > lost when you return. stuff i leave behind: that is in my view like dropping a snap-shot. it's not coming back with me. i would not expect changes that i inflict on it in the other domain to have repercussions on the original asset. inventory changes: that raises the interesting question of whether my inventory is modulated by the domain i'm in? in other words, will my inventory change depending on where i am or will i always see my full inventory, i just won't be able to rez some items in certain domains? again, i'd expect to always see the full inventory in my client, any changes that i make are relayed back to the asset server of the item. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From labrat.hb at gmail.com Tue Oct 9 23:51:49 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Oct 9 23:51:52 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <470C0473.7060301@speakeasy.net> References: <470C0473.7060301@speakeasy.net> Message-ID: I guess I should warn you now... doing text with a texture is NOT going to load up in "microseconds". Nor is it going to be light on prims. With the setup you have chosen the best you can possibly get is 5 characters per prim. On 10/9/07, Alan Grimes wrote: > > SL has a problem with text. > > You can't work with it affordably in-world. You have to pay to upload > each one and then to read it, you have to sit and wait for 20 minutes > (okay 5..) for the damn thing to rez before you can read it. > > The simpleton's solution to that is to upload a single texture, a > codepage, and then create letters by mapping different parts of that > codepage to prims. -- too obvious, huh? > > Alright, I fired up my old DOS computer. (Yes, I have a DOS computer) > and snagged myself my favorite font library. > > I then wrote a program to extract the code page I wanted. 437 FOREVER!!! > > It produced a nice little bmp file, 4158 bytes to be exact... > > SL didn't like that so I made a PNG of it so that it wouldn't get > corrupted, 3193 bytes. -- pretty nice, huh? =P (see attached, have a > look at it and then tell me 437 isn't the best codepage ever!!!). > > (image specs: 128 x 256 x 1 bit) > > The whole point is to make an in-world font system that will be > __FAST__, I mean rez as much text as you like in microseconds!!! > > I was thinking oh boy, this'll make me a fortune in lindens!!! -- > ignoring the fact that the linden is devaluing right along with the > dollar. =( > > Then I PAID LINDENS TO UPLOAD IT!!!! =| > > You see, this scheme only works if the font can be uploaded and relayed > to the client in a lossless way. -- being only 3kb, this didn't seem > like an unreasonable demand... > > But what I got back seemed to be 256x512, and then downsized to the > origional... It also seems to have been converted to 24 bit, -- an > unspeakable waste for this application, and finally, some kind of > smoothing operation was performed!!!! -- It may just be that the > GL_LINEAR texture filter was left on... =\ > > The final result is totally unusable as a font system. =( > > When I cough up L$10 to upload a texture I damn well expect that what I > get back is what I uploaded!! =\ > > BTW, Ron Paul has an in-world pavilion. > > > -- > Buy Ron Paul's Money! =) > http://www.libertydollar.org/ld/ronpauldollar > Soundest investment on the planet! > > > _______________________________________________ > 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/20071009/54b1b7b4/attachment-0001.htm From matthew.dowd at hotmail.co.uk Tue Oct 9 23:54:33 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Oct 9 23:54:35 2007 Subject: [sldev] OMG, my image was de-rezed!!! In-Reply-To: <470C59E7.9080309@speakeasy.net> References: <470C59E7.9080309@speakeasy.net> Message-ID: You can always do testing of textures (and sounds and animations for that matter), on the beta grid since L$ there are effectively free. Once you have something that works, upload it to the main grid. Matthew> Date: Wed, 10 Oct 2007 00:49:43 -0400> From: agrimes@speakeasy.net> To: sldev@lists.secondlife.com> Subject: [sldev] OMG, my image was de-rezed!!!> > After I wrote my last e-mail, I wandered around, when I got back my text> test prim had been de-rezed to 128x128 from 256x256> > !!!!!!! W H A T !!!!!!!> > My image that was posted at origonal size was de-rezed to 64x128, no> wonder it is illegable, it has half the pixels it needs...> > In the background is one of my ron-paul yard posters which looks crystal> clear...> > What gives? I pay L$10 to upload a 1.3kb file and your server decides it> can't handle 1.3kb and crops it down to half the resolution???> > WHAT THE ....!!!!!!> > Oh well, while I'm pissing away lindens, I'll make a 256x512 version... =\> > =P> > Looks like I tricked it into working.> > The big smiley face looks a bit blurry but that's what you get when you> put an 8x16 sub-texture on a 5x10 prim face. =P> > Suggested new policy: L$1/killobyte and the server keeps a lossless copy.> > -- > Buy Ron Paul's Money! =)> http://www.libertydollar.org/ld/ronpauldollar> Soundest investment on the planet!> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071010/f0462e4e/attachment.htm From robin.cornelius at gmail.com Wed Oct 10 01:02:06 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Oct 10 01:02:08 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Message-ID: On 10/9/07, Argent Stonecutter wrote: > On 09-Oct-2007, at 09:19, Matthew Wiggins wrote: > > As you've rightly pointed out, there is a significant amount of non- > > changing data between releases so we should be able to cut the size > > of updates by a large amount. As Bushing Spatula has found on that > > VVR-603, getting to a 12MB delta is easily achievable. The main > > challenge is producing a system that works on all three platforms > > in a pleasing way for the user, and plays nicely with our > > versioning process. > > You could use rsync. :) > > Actually, only half :). > > It might work. > Seems like a pretty good idea, librsync can be wrapped up nicely (if required) and it should provide a pretty efficient method of update. Its cross platform and a standard technology. My only concern is that there must be a way of disabling it or perhapses running a custom script etc so if people are following nicholaz patch sets they don't suddenly get updated to a linden original etc. Although the update detector currently dosn't do this. But it may be nice if it could be redirected so that people running 3rd party builds can have there own update repository. It would save my upload bandwith. Robin From hud at zurich.ibm.com Wed Oct 10 02:09:45 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 10 02:09:49 2007 Subject: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.) In-Reply-To: <470C1204.9040500@lindenlab.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> <4705CAB9.4080401@zurich.ibm.com> <470C1204.9040500@lindenlab.com> Message-ID: <470C96D9.6060909@zurich.ibm.com> Joshua Bell wrote: > Felix Wakmann posted some brainstorms about a "robots.txt" for SL > here: http://www.your2ndplace.com/node/417 in the context of allowing > parcel owners to communicate with the SLBrowser spider bots to limit > what is searched, just as robots.txt does for the web. thx for that link! discussion on that post is very interesting --- i like the idea of the bot channel: that would be the quickest way of implementing a bot.txt feature. long term i think it should become part of the parcel/estate properties as that would make it easier. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From dale at daleglass.net Wed Oct 10 02:52:08 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 10 02:52:14 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Message-ID: <20071010095208.GA2922@bruno.sbruno> > My only concern is that there must be a way of disabling it or > perhapses running a custom script etc so if people are following > nicholaz patch sets they don't suddenly get updated to a linden > original etc. Although the update detector currently dosn't do this. > But it may be nice if it could be redirected so that people running > 3rd party builds can have there own update repository. It would save > my upload bandwith. That's not a problem at all, I'd simply patch it to use my server instead of LL's (I've got a viewer of my own too) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071010/495f9a4d/attachment.pgp From dale at daleglass.net Wed Oct 10 03:01:42 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Oct 10 03:01:54 2007 Subject: [sldev] [VWR] How to "commit" translations in Build mode? In-Reply-To: <470C027A.1060109@cox.net> References: <200710092348.03505.dale@daleglass.net> <470C027A.1060109@cox.net> Message-ID: <20071010100142.GA6197@bruno.sbruno> On Tue, Oct 09, 2007 at 03:36:42PM -0700, Lawson English wrote: > This ties in with the jira request for the ability to "build" particle > effects. Is there a similar way to update particle effects before the > building process ends? I don't think this is related. This is simply an optimization to send several updates inside one packet instead of using several packets to do it. What do you mean by building process, btw? AFAIK (though I haven't looked at the specifics), the "building process" is a purely client-side state. The viewer could send prim updates without having to enter any sort of build mode if coded to do it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071010/59a6497c/attachment.pgp From scrosta at cisco.com Wed Oct 10 03:04:08 2007 From: scrosta at cisco.com (Stefano Crosta (scrosta)) Date: Wed Oct 10 03:04:12 2007 Subject: [sldev] Help compiling the Viewer (could not deduce template argument ... from 'LLMessageThrottleEntry') Message-ID: Hello, this is a *desperate* call for help. I am trying to compile the viewer on a new dev machine and, silly me, it's a Vista OS with Visual Studio 2008. I have been able to compile all the libs regardless of minor issues with the wiki doc, gone through mad issues with file permissions when using 7-zip (DON'T, on Vista), (and am willing to put more info on the wiki) but this one i really can't solve: 1>llmessagethrottle.cpp 1>c:\program files\development\microsoft visual studio 9.0\vc\include\algorithm(406) : error C2784: 'bool std::operator ==(const std::deque<_Ty,_Alloc> &,const std::deque<_Ty,_Alloc> &)' : could not deduce template argument for 'const std::deque<_Ty,_Alloc> &' from 'LLMessageThrottleEntry' 1> c:\program files\development\microsoft visual studio 9.0\vc\include\deque(1341) : see declaration of 'std::operator ==' 1> c:\program files\development\microsoft visual studio 9.0\vc\include\algorithm(435) : see reference to function template instantiation '_FwdIt1 std::_Search_n<_FwdIt1,_Diff2,_Ty,bool(__cdecl *)(LLMessageThrottleEntry,LLMessageThrottleEntry)>(_FwdIt1,_FwdIt1,_Diff2,const _Ty &,_Pr,std::random_access_iterator_tag)' being compiled 1> with 1> [ 1> _FwdIt1=LLMessageThrottle::message_list_iterator_t, 1> _Diff2=int, 1> _Ty=LLMessageThrottleEntry, 1> _Pr=bool (__cdecl *)(LLMessageThrottleEntry,LLMessageThrottleEntry) 1> ] 1> c:\sources\secondlife\lindenlabclient\indra\llmessage\llmessagethrottle.cpp(114) : see reference to function template instantiation '_FwdIt1 std::search_n(_FwdIt1,_FwdIt1,_Diff2,const _Ty &,_Pr)' being compiled 1> with 1> [ 1> _FwdIt1=LLMessageThrottle::message_list_iterator_t, 1> _Diff2=int, 1> _Ty=LLMessageThrottleEntry, 1> _Pr=bool (__cdecl *)(LLMessageThrottleEntry,LLMessageThrottleEntry) 1> ] (when compiling llmessage) After this, i get hundred of errors all related to: > could not deduce template argument for 'SOMETHING' from 'LLMessageThrottleEntry' Any idea of why? I could not find any evidence of the VS 9 compiler to have changed, but that seems to be the case. I guess some explicit argument template declaration would do the trick... but i can't figure out where! Any help would be more than welcome... before i spend 3 days re-installing XP and an older VS version :( thanks Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071010/03a76f4e/attachment.htm From matthew.dowd at hotmail.co.uk Wed Oct 10 03:14:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Oct 10 03:14:19 2007 Subject: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.) In-Reply-To: <470C96D9.6060909@zurich.ibm.com> References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> <4705CAB9.4080401@zurich.ibm.com> <470C1204.9040500@lindenlab.com> <470C96D9.6060909@zurich.ibm.com> Message-ID: There's been a lot of discussion about adding arbitrary custom attributes to prims for use by open source applications etc. Is this moving into a need to something similar for parcels/estates? Matthew > Date: Wed, 10 Oct 2007 11:09:45 +0200> From: hud@zurich.ibm.com> To: josh@lindenlab.com> Subject: Re: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.)> CC: sldev@lists.secondlife.com> > Joshua Bell wrote:> > Felix Wakmann posted some brainstorms about a "robots.txt" for SL> > here: http://www.your2ndplace.com/node/417 in the context of allowing> > parcel owners to communicate with the SLBrowser spider bots to limit> > what is searched, just as robots.txt does for the web.> thx for that link! discussion on that post is very interesting --- i> like the idea of the bot channel: that would be the quickest way of> implementing a bot.txt feature. long term i think it should become part> of the parcel/estate properties as that would make it easier.> > cheers,> dirk> > -- > dr dirk husemann, pervasive computing, ibm zurich research lab> --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield> > _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071010/cdf98604/attachment-0001.htm From secret.argent at gmail.com Wed Oct 10 04:19:37 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 04:19:47 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <470BCE44.80401@dzonux.net> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> <470BCE44.80401@dzonux.net> Message-ID: <42D6F0D2-27F3-4D5E-8EA6-4F161BEFDD41@gmail.com> On 09-Oct-2007, at 13:53, Dzonatas wrote: > One way to increase loading time is to get rid of the graphic card > bandwidth bottleneck, and go with RT models on the main CPU where > memory can be dynamically accessed faster. On the other hand, even fairly low power RT-specific hardware can outperform much faster CPUs at raytracing. Raytracing is a problem that is both extremely well adapted to hardware acceleration (much more so than rasterization) and "embarrassingly parallelizable" - meaning that it scales up supremely well. Google for SaarCOR. From secret.argent at gmail.com Wed Oct 10 04:26:25 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 04:26:33 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <1191986888.29582.112.camel@localhost> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> Message-ID: <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> On 09-Oct-2007, at 22:28, Callum Lerwick wrote: > On Tue, 2007-10-09 at 09:30 -0500, Argent Stonecutter wrote: >> It can apply to stuff you never even rez in that domain. You might >> make a change to something in your inventory in a domain that has the >> same trust level as the original domain, you don't want those changes >> lost when you return. > I don't know what you're even on about here. Your inventory lives > in the > *Agent* domain, its not moving anywhere. Your inventory contains assets. You change an asset in your inventory, changing its name or permissions, where does that happen? If it happens in the agent server, then you've already answered the original question - the master copy is the instance of the inventory object in that server. If it happens in the asset server, then the asset server it happens in has to trust the domain that you're making the change from. From secret.argent at gmail.com Wed Oct 10 04:42:25 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 04:42:31 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470C6C0A.2090502@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <470C6C0A.2090502@zurich.ibm.com> Message-ID: <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> On 10-Oct-2007, at 01:07, dirk husemann wrote: > if yo change owner & group, doesn't that constitute a transfer? with a > no-transfer asset you'd go against the wishes of the creator then. Owner, yes. Group no. But more to the point, *permissions are inherently advisory between domains operated by different organizations*. >> It can apply to stuff you never even rez in that domain. You might >> make a change to something in your inventory in a domain that has the >> same trust level as the original domain, you don't want those changes >> lost when you return. > stuff i leave behind: that is in my view like dropping a snap-shot. > it's > not coming back with me. i would not expect changes that i inflict > on it > in the other domain to have repercussions on the original asset. I'm sorry, I just said that I'm not talking about stuff you leave behind. I was clarifying what stuff you DON'T leave behind could include. > inventory changes: that raises the interesting question of whether my > inventory is modulated by the domain i'm in? in other words, will my > inventory change depending on where i am or will i always see my full > inventory, i just won't be able to rez some items in certain domains? OK, I'm not just talking about the list of objects in my inventory, I'm talking about the assets themselves. When you go from one domain to another, and go into your inventory, and bring up the properties of an object in your inventory, where is the asset that you are bringing up the properties on? The trust relationship between the domain the asset is in and the domain you're in should determine if you can bring up the properties at all, and *separately* whether you can get at the content of the asset itself. That is, you bring up "fred's cool shirt" in domain-fred-doesn't- trust and you see the name, owner, description, rights, and so on. But you still can't wear the shirt. What I'm envisioning here is that *in that domain* that shirt is represented by a placeholder copy of the asset that's a reference back to the original. From secret.argent at gmail.com Wed Oct 10 04:54:10 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 04:54:15 2007 Subject: [sldev] Packaging the viewer for Linux distributions References: <2C601DB0-5A53-4523-82F2-28B8345984E6@gmail.com> Message-ID: <2B17F1DD-BB83-4114-9D40-7D3156ABB58A@gmail.com> On 10-Oct-2007, at 03:02, Robin Cornelius wrote: > My only concern is that there must be a way of disabling it or > perhapses running a custom script etc so if people are following > nicholaz patch sets they don't suddenly get updated to a linden > original etc. I would assume the guy making the patch set would put the base rsync URL of *his* server in the patched client. :) In fact, the way to do it would be to have in some XML file in the client... http://example.com/thingy/whatzit/osx.xml And that would then return... mirror1.example.com::updates/osx/MacOS mirror1.example.com::updates/20071101/character ... Then you could have it return a different mirror on every request. > From nicholaz at blueflash.cc Wed Oct 10 05:02:01 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Oct 10 05:02:06 2007 Subject: [sldev] [ANN] Will be offline from the list for a while Message-ID: <470CBF39.5000501@blueflash.cc> Sorry for spamming the list with something utterly off-topic, but I'll be offline from the list for at least three weeks (going on vacation, yay! :-)), so if someone needs to reach me, please email. See you on the other side ... Nick From robin.cornelius at gmail.com Wed Oct 10 05:39:16 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Oct 10 05:39:18 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <2B17F1DD-BB83-4114-9D40-7D3156ABB58A@gmail.com> References: <2C601DB0-5A53-4523-82F2-28B8345984E6@gmail.com> <2B17F1DD-BB83-4114-9D40-7D3156ABB58A@gmail.com> Message-ID: On 10/10/07, Argent Stonecutter wrote: > On 10-Oct-2007, at 03:02, Robin Cornelius wrote: > > My only concern is that there must be a way of disabling it or > > perhapses running a custom script etc so if people are following > > nicholaz patch sets they don't suddenly get updated to a linden > > original etc. > > I would assume the guy making the patch set would put the base rsync > URL of *his* server in the patched client. :) > > In fact, the way to do it would be to have in some XML file in the > client... > > http://example.com/thingy/whatzit/osx.xml > > And that would then return... > > mirror1.example.com::updates/osx/MacOS > type="optional">mirror1.example.com::updates/20071101/character > ... > > Then you could have it return a different mirror on every request. > > I really like the sound of this whole approach using rsync etc for both homebrew distributions and official linden ones. It solves the linux autoupdating issues (eg not having a updater). It could (in theory) unify the linux/mac/windows update mechanism therefor easier to maintain.It reduces overall bandwidth consumption and users time to get an update and it provides a mechanism to distribute homebrew viewers in the same way as the official one. Still would need an installer for windows (and mac?) for first time install but nothing that complex is needed for an updater. Another question, is there an easy way to check for homebrew version updates. I notice from the llstatup.cpp code that it running the update code based on a reply message to the login attempt. Great for official linden versions but for homebrew versions where we might have more releases than the lindens do with various patches being tested often etc, we need a way to say there is an update available. I presume I would have to add a hack in there to do some kind of http look up against a php page on my server that reported if an update was available or not (or at least what the current version on the server is) and from that kick the update_app() code as required? any thoughts on this? Robin From soft at lindenlab.com Wed Oct 10 06:02:08 2007 From: soft at lindenlab.com (Soft) Date: Wed Oct 10 06:02:10 2007 Subject: [sldev] [META] Anyone want to take over SLDev-Traffic? Message-ID: Each week (approximately), I create a summary of SLDev mailing list traffic and link it here: https://wiki.secondlife.com/wiki/SLDev_Traffic I'm trying to free up some of my sldev-budgeted time for other sldev work, and want to see if anyone would be interested in volunteering to take this over. I started this before I began working for Linden Lab - no insider angle or voice of authority is needed to write -traffic. My approach in writing -traffic has been to review each week's list traffic, to capture a summary of the major discussions of interest to developers, and to note the names associated with the discussions. The goal is to provide a pointer to new faces readers should know about, or to people who might be useful contacts for resolving bugs or getting multiple views on hot issues. It's helpful to write on a weekly basis, and to put off summarizing still-live discussions, only pointing to their current existence. I usually do this by only summarizing threads with no posts in two days. Reply here if you're interested - it's a great way to make sure you're on top of current issues, and a great way to meet Lindens. It was great having a number of people who already knew who I was when I decided to interview at Linden Lab. From soft at lindenlab.com Wed Oct 10 06:16:46 2007 From: soft at lindenlab.com (Soft) Date: Wed Oct 10 06:16:49 2007 Subject: [sldev] Help compiling the Viewer (could not deduce template argument ... from 'LLMessageThrottleEntry') In-Reply-To: References: Message-ID: On 10/10/07, Stefano Crosta (scrosta) wrote: > > this is a *desperate* call for help. I am trying to compile the viewer on a > new dev machine and, silly me, it's a Vista OS with Visual Studio 2008. I > have been able to compile all the libs regardless of minor issues with the > wiki doc, gone through mad issues with file permissions when using 7-zip > (DON'T, on Vista), (and am willing to put more info on the wiki) but this > one i really can't solve: > > > 1>llmessagethrottle.cpp > 1>c:\program files\development\microsoft visual studio > 9.0\vc\include\algorithm(406) : error C2784: 'bool std::operator ==(const > std::deque<_Ty,_Alloc> &,const std::deque<_Ty,_Alloc> &)' : could not deduce > template argument for 'const std::deque<_Ty,_Alloc> &' from > 'LLMessageThrottleEntry' > 1> c:\program files\development\microsoft visual studio > 9.0\vc\include\deque(1341) : see declaration of 'std::operator ==' > 1> c:\program files\development\microsoft visual studio > 9.0\vc\include\algorithm(435) : see reference to function template > instantiation '_FwdIt1 > std::_Search_n<_FwdIt1,_Diff2,_Ty,bool(__cdecl > *)(LLMessageThrottleEntry,LLMessageThrottleEntry)>(_FwdIt1,_FwdIt1,_Diff2,const > _Ty &,_Pr,std::random_access_iterator_tag)' being compiled > 1> with > 1> [ > 1> > _FwdIt1=LLMessageThrottle::message_list_iterator_t, > 1> _Diff2=int, > 1> _Ty=LLMessageThrottleEntry, > 1> _Pr=bool (__cdecl > *)(LLMessageThrottleEntry,LLMessageThrottleEntry) > 1> ] > 1> > c:\sources\secondlife\lindenlabclient\indra\llmessage\llmessagethrottle.cpp(114) > : see reference to function template instantiation '_FwdIt1 > std::search_n *)(LLMessageThrottleEntry,LLMessageThrottleEntry)>(_FwdIt1,_FwdIt1,_Diff2,const > _Ty &,_Pr)' being compiled > 1> with > 1> [ > 1> > _FwdIt1=LLMessageThrottle::message_list_iterator_t, > 1> _Diff2=int, > 1> _Ty=LLMessageThrottleEntry, > 1> _Pr=bool (__cdecl > *)(LLMessageThrottleEntry,LLMessageThrottleEntry) > 1> ] > > (when compiling llmessage) > > After this, i get hundred of errors all related to: > > could not deduce template argument for 'SOMETHING' from > 'LLMessageThrottleEntry' > > Any idea of why? I could not find any evidence of the VS 9 compiler to have > changed, but that seems to be the case. I guess some explicit argument > template declaration would do the trick... but i can't figure out where! It would help to post the surrounding lines from the llmessagethrottle.cpp source in the version of the source you're using. Also, it's not uncommon that some of the changes aren't documented until after the compiler is out of beta. You may well be experiencing changes before the Visual Studio team is aware of them. > Any help would be more than welcome... before i spend 3 days re-installing > XP and an older VS version :( You shouldn't need to install XP. Many people are using the free express version of Visual Studio 2005 with success. There's a JIRA that carries current versions of the project files, which should be referenced from the build instruction page. From alissa_sabre at yahoo.co.jp Wed Oct 10 02:12:35 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Oct 10 06:42:04 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> References: <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Message-ID: <1Loadt4kw5dY4n796oz5v.alissa_sabre@yahoo.co.jp> Thank you, Matthew, for sharing your activity with the community. > Regarding a patching updater > The main > challenge is producing a system that works on all three platforms in > a pleasing way for the user, and plays nicely with our versioning > process. Sounds good, but I want to make several comments: - There are several community build viewers today, and they are supposed to be growing. I hope the new patch updator does not interfere them. I'm not saying you must support community builds in your updator, but it should not make using community build unpractical. Of course it's nice if the new updator is easily adaptable to non official viewers. - Supporting the official three platforms (MacOS, 32 bit Windows, and i686 Linux) is fine. Please don't forget, however, that there are more platforms, e.g., x64 Windows, PPC Linux, or SPARC Solaris. - We've told that LL runs "Skinning Project" internally, and it will support drop-in replacement of look-and-feel or UI language through user-supplied XML files. I hope the patch updator does not break those custom skin users, too. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From alexander.treptow at zweitgeist.com Wed Oct 10 06:45:50 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Wed Oct 10 06:46:08 2007 Subject: [sldev] [Question] TCP/UDP Sim connection Message-ID: <470CD78E.3080003@zweitgeist.com> I connected successfully to the login server and got the xml with my charakters position, simip, simport and so on. now i want to connect to the sim i send an udp packet with 40 00 00 00 01 00 FF FF 00 10 as first bytes in hex like its mentioned in the wiki. behind this data follows the sessionuuid and the agenduuid as raw data. so the packet size is 46 byte. the port is the simulator port 12035. but i got no response from the server. i think its because there is no tcp connection to the sim. but i found no function in the viewer that establish a tcp connection to the sim. does anybody know what this tcp connection is for and where i can find the function doing this stuff or what else i ve to do to send needed files to the sim to get my avatar data (sceleton, textures, etc.) greets Alex From secret.argent at gmail.com Wed Oct 10 07:27:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 07:27:29 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <2C601DB0-5A53-4523-82F2-28B8345984E6@gmail.com> <2B17F1DD-BB83-4114-9D40-7D3156ABB58A@gmail.com> Message-ID: <8BEFC0D2-981A-4D06-86F5-280F174A9170@gmail.com> On 10-Oct-2007, at 07:39, Robin Cornelius wrote: > Still would need an > installer for windows (and mac?) for first time install but nothing > that complex is needed for an updater. Mac doesn't need an installer, it uses the NeXTSTeP "bundle" scheme. GNUStep apps on other UNIX (Linux,BSD,Solaris,...) are set up the same way. It's really convenient... the top level directory is shown as a file rather than a directory in the Finder (or the old NeXTSTeP file manager and I assume in whatever file manager the GNUStep folks use), until you select "Show Contents" from the contextual menu. I'll go into more detail in a separate message because looking at the layout made me think of a couple of other comments that are kinda orthogonal. > Another question, is there an easy way to check for homebrew version > updates. I notice from the llstatup.cpp code that it running the > update code based on a reply message to the login attempt. Great for > official linden versions but for homebrew versions where we might have > more releases than the lindens do with various patches being tested > often etc, we need a way to say there is an update available. That was the intent of the "update-server" entry, which would be in something like ... the update could be checked on a schedule, or when the program started, and would be independent of login. You'd pull down the file from the and compare the tags against the tags in your copy, and if they didn't match it could then do an rsync against the files in the s. Using rsync argument formats would allow you to specify a local file or a file on a local network share. You'd probably want to have something like ssh -2 tags or an rsync_cmd="env RSYNC_RSH='ssh -2' Resources/rsync -abc -xyz $1" attribute for special cases. From secret.argent at gmail.com Wed Oct 10 07:31:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 07:31:21 2007 Subject: [sldev] [META] Packages and bundles and XML, oh my In-Reply-To: References: <2C601DB0-5A53-4523-82F2-28B8345984E6@gmail.com> <2B17F1DD-BB83-4114-9D40-7D3156ABB58A@gmail.com> Message-ID: <67153FAC-C743-40F1-ACD9-486BB48DEE68@gmail.com> (was Re: [sldev] Packaging the viewer for Linux distributions) On 10-Oct-2007, at 07:39, Robin Cornelius wrote: > Still would need an > installer for windows (and mac?) for first time install but nothing > that complex is needed for an updater. Mac doesn't need an installer, it uses the NeXTSTeP "bundle" scheme. GNUStep apps on other UNIX (Linux,BSD,Solaris,...) are set up the same way. It's really convenient... the top level directory is shown as a file rather than a directory in the Finder (or the old NeXTSTeP file manager and I assume in whatever file manager the GNUStep folks use), until you select "Show Contents" from the contextual menu. Here's the layout of the latest version: Second Life.app Contents PkgInfo -- 8 bytes "APPL????" - equivalent to the old Apple 'Finder Info' - type and creator Info.plist -- XML file describing the application's requirements, what URL and file types it handles, etc... MacOS Second Life -- executable (MachO UNIX executable) *.dylib -- bundled shared libraries, seem to be the ones for gecko chrome, plugins, etc... -- gecko support files, same as any other SL install Resources -- equivalent of old Apple 'Resource Fork' secondlife.icns -- desktop icon SecondLife.nib -- Window and menu layouts for the top level window (non-XUI), standard Cocoa/Carbon file. *.lproj -- localized strings, windows, etc for English InfoPlist.strings language.txt arguments.txt -- default command line app_settings -- xml, shaders, like in any other SL install AutoUpdater.app -- app bundle for AutoUpdater, same layout inside *.app -- ditto for other bundled apps *.dylib -- rest of the bundled shared libraries skins, releasenotes.txt, lsl_guide.html, etc... Normally you'd expect something like Gecko and its support files to be under Contents/Frameworks rather than under Contents/MacOS, but I assume LL had some reason for doing things that way. (any comment from the LL folks?) By the way, the XML property list format is almost the same as the llsd format that someone else brought up: Info.plist CFBundleDevelopmentRegion English [...] CFBundleURLTypes CFBundleURLName Second Life URL [...] plywoodcube.xml 401346943 phantom 0 [...] The biggest difference is vs . If this isn't set in stone, it would be really nice if the Apple (and I assume GNUstep) tools for handling property lists could be used on these files. What's the scoop here? From dzonatas at dzonux.net Wed Oct 10 08:29:44 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Oct 10 08:29:38 2007 Subject: [sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking In-Reply-To: <42D6F0D2-27F3-4D5E-8EA6-4F161BEFDD41@gmail.com> References: <46FD501B.5080501@lindenlab.com> <1191895700.29582.5.camel@localhost> <63028FE9-8616-401C-BC97-9D00C722F802@gmail.com> <470B1A80.9020703@gmail.com> <470BCE44.80401@dzonux.net> <42D6F0D2-27F3-4D5E-8EA6-4F161BEFDD41@gmail.com> Message-ID: <470CEFE8.9020308@dzonux.net> Argent Stonecutter wrote: > ...and "embarrassingly parallelizable" - meaning that it scales up > supremely well. Right. > > Google for SaarCOR. It has already been taken into consideration. Please search the Intel website for its terascale design, and you'll notice special functionality cores among the general programmable cores. As for the previous question about LOD, we could use 4 bits from the alpha channel to map significant points for LOD. MIP maps are about 8 levels, so 4 bits can provide similar feature. I little remesh can be done. That's enough to show that the extra load overhead for billboard (or regular mip maps) are not needed for sculpties. -- Power to Change the Void From tateru.nino at gmail.com Wed Oct 10 08:46:05 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Oct 10 08:46:09 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470CD78E.3080003@zweitgeist.com> References: <470CD78E.3080003@zweitgeist.com> Message-ID: <470CF3BD.1030407@gmail.com> alexander treptow wrote: > I connected successfully to the login server and got the xml with my > charakters position, simip, simport and so on. now i want to connect > to the sim i send an udp packet with > 40 00 00 00 01 00 FF FF 00 10 as first bytes in hex like its mentioned > in the wiki. > behind this data follows the sessionuuid and the agenduuid as raw > data. so the packet size is 46 byte. the port is the simulator port > 12035. I could be wrong, but shouldn't that be FF FF 00 03 (UseCircuitCode)? -- Tateru Nino http://dwellonit.blogspot.com/ From scrosta at cisco.com Wed Oct 10 08:55:51 2007 From: scrosta at cisco.com (Stefano Crosta (scrosta)) Date: Wed Oct 10 08:56:04 2007 Subject: [sldev] Help compiling the Viewer (could not deduce template argument ... from 'LLMessageThrottleEntry') In-Reply-To: References: Message-ID: Brian, thanks for answering. I set up a page: https://wiki.secondlife.com/wiki/Compiling_Issues_with_Vista/MSVS2008 with the whole copy of the error and my version of llmessagethrottle.cpp. In case that helps... Thanks, Stefano > -----Original Message----- > From: brian@brianm.org [mailto:brian@brianm.org] On Behalf Of Soft > Sent: Wednesday, October 10, 2007 3:17 PM > To: Stefano Crosta (scrosta) > Cc: SLDev@lists.secondlife.com > Subject: Re: [sldev] Help compiling the Viewer (could not > deduce template argument ... from 'LLMessageThrottleEntry') > > On 10/10/07, Stefano Crosta (scrosta) wrote: > > > > this is a *desperate* call for help. I am trying to compile the > > viewer on a new dev machine and, silly me, it's a Vista OS > with Visual > > Studio 2008. I have been able to compile all the libs regardless of > > minor issues with the wiki doc, gone through mad issues with file > > permissions when using 7-zip (DON'T, on Vista), (and am > willing to put > > more info on the wiki) but this one i really can't solve: > > > > > > 1>llmessagethrottle.cpp > > 1>c:\program files\development\microsoft visual studio > > 9.0\vc\include\algorithm(406) : error C2784: 'bool std::operator > > ==(const std::deque<_Ty,_Alloc> &,const > std::deque<_Ty,_Alloc> &)' : > > could not deduce template argument for 'const > std::deque<_Ty,_Alloc> > > &' from 'LLMessageThrottleEntry' > > 1> c:\program files\development\microsoft visual studio > > 9.0\vc\include\deque(1341) : see declaration of 'std::operator ==' > > 1> c:\program files\development\microsoft visual studio > > 9.0\vc\include\algorithm(435) : see reference to function template > > instantiation '_FwdIt1 > std::_Search_n<_FwdIt1,_Diff2,_Ty,bool(__cdecl > > > *)(LLMessageThrottleEntry,LLMessageThrottleEntry)>(_FwdIt1,_FwdIt1,_Di > > ff2,const _Ty &,_Pr,std::random_access_iterator_tag)' being compiled > > [..removed check the link!.] > > > > After this, i get hundred of errors all related to: > > > could not deduce template argument for 'SOMETHING' from > > 'LLMessageThrottleEntry' > > > > Any idea of why? I could not find any evidence of the VS 9 > compiler > > to have changed, but that seems to be the case. I guess > some explicit > > argument template declaration would do the trick... but i > can't figure out where! > > It would help to post the surrounding lines from the > llmessagethrottle.cpp source in the version of the source > you're using. > > Also, it's not uncommon that some of the changes aren't > documented until after the compiler is out of beta. You may > well be experiencing changes before the Visual Studio team is > aware of them. > > > > Any help would be more than welcome... before i spend 3 days > > re-installing XP and an older VS version :( > > You shouldn't need to install XP. Many people are using the > free express version of Visual Studio 2005 with success. > There's a JIRA that carries current versions of the project > files, which should be referenced from the build instruction page. > From mark.burhop at gmail.com Wed Oct 10 09:49:52 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Wed Oct 10 09:49:54 2007 Subject: [sldev] AWG: Good time to clean up or update the Wiki Message-ID: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> Saw this on CNN's site: IBM and Linden Lab Launch Collaboration to Further Advance the 3D Internet http://money.cnn.com/news/newsfeeds/articles/marketwire/0313677.htm Interesting news but beyond that, it has a direct link to the Architecture Working Group Wiki. This might be a good time for us to to clean up and update content. http://wiki.secondlife.com/wiki/Architecture_Working_Group -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071010/7e7b14fd/attachment-0001.htm From sl at phoca.com Wed Oct 10 10:38:21 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Wed Oct 10 10:38:29 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: References: <470C0473.7060301@speakeasy.net> Message-ID: Using texture offset you can get every character on every prim, you just need one prim per character being displayed. ----- Original Message ----- From: Harold Brown To: Alan Grimes Cc: sldev@lists.secondlife.com Sent: Tuesday, October 09, 2007 11:51 PM Subject: Re: [sldev] WTF happened to my texture? I guess I should warn you now... doing text with a texture is NOT going to load up in "microseconds". Nor is it going to be light on prims. With the setup you have chosen the best you can possibly get is 5 characters per prim. On 10/9/07, Alan Grimes wrote: SL has a problem with text. You can't work with it affordably in-world. You have to pay to upload each one and then to read it, you have to sit and wait for 20 minutes (okay 5..) for the damn thing to rez before you can read it. The simpleton's solution to that is to upload a single texture, a codepage, and then create letters by mapping different parts of that codepage to prims. -- too obvious, huh? Alright, I fired up my old DOS computer. (Yes, I have a DOS computer) and snagged myself my favorite font library. I then wrote a program to extract the code page I wanted. 437 FOREVER!!! It produced a nice little bmp file, 4158 bytes to be exact... SL didn't like that so I made a PNG of it so that it wouldn't get corrupted, 3193 bytes. -- pretty nice, huh? =P (see attached, have a look at it and then tell me 437 isn't the best codepage ever!!!). (image specs: 128 x 256 x 1 bit) The whole point is to make an in-world font system that will be __FAST__, I mean rez as much text as you like in microseconds!!! I was thinking oh boy, this'll make me a fortune in lindens!!! -- ignoring the fact that the linden is devaluing right along with the dollar. =( Then I PAID LINDENS TO UPLOAD IT!!!! =| You see, this scheme only works if the font can be uploaded and relayed to the client in a lossless way. -- being only 3kb, this didn't seem like an unreasonable demand... But what I got back seemed to be 256x512, and then downsized to the origional... It also seems to have been converted to 24 bit, -- an unspeakable waste for this application, and finally, some kind of smoothing operation was performed!!!! -- It may just be that the GL_LINEAR texture filter was left on... =\ The final result is totally unusable as a font system. =( When I cough up L$10 to upload a texture I damn well expect that what I get back is what I uploaded!! =\ BTW, Ron Paul has an in-world pavilion. -- Buy Ron Paul's Money! =) http://www.libertydollar.org/ld/ronpauldollar Soundest investment on the planet! _______________________________________________ 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 liana at lindenlab.com Wed Oct 10 11:01:51 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Wed Oct 10 11:01:56 2007 Subject: [sldev] [AWG]: Good time to clean up or update the Wiki In-Reply-To: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> References: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> Message-ID: <470D138F.1050105@lindenlab.com> Thanks for the nudge, Mark. I added a link to the AWG homepage from the open source portal Participation box -- for those who don't come to us via a direct link -- and threw in a few minor edits here and there. Mark Burhop wrote: > Saw this on CNN's site: > > IBM and Linden Lab Launch Collaboration to Further Advance the 3D Internet > http://money.cnn.com/news/newsfeeds/articles/marketwire/0313677.htm > > Interesting news but beyond that, it has a direct link to the > Architecture Working Group Wiki. This might be a good time for us to > to clean up and update content. > > http://wiki.secondlife.com/wiki/Architecture_Working_Group > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20071010/422c3adb/attachment.htm From wiggo at lindenlab.com Wed Oct 10 11:36:01 2007 From: wiggo at lindenlab.com (Matthew Wiggins) Date: Wed Oct 10 11:36:09 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: <1Loadt4kw5dY4n796oz5v.alissa_sabre@yahoo.co.jp> References: <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> <1Loadt4kw5dY4n796oz5v.alissa_sabre@yahoo.co.jp> Message-ID: Thanks for your feedback. Just to let you know that Which Linden (who has spent time thinking about this problem) and I will be following up with this discussion, and using the wiki where possible to document progress. And of course we want to make sure that, if we do progress with the patcher soon, it integrates as smoothly as possible with existing systems. Matthew (Wiggo Linden). On 10 Oct 2007, at 10:12, Alissa Sabre wrote: > Thank you, Matthew, for sharing your activity with the community. > >> Regarding a patching updater > >> The main >> challenge is producing a system that works on all three platforms in >> a pleasing way for the user, and plays nicely with our versioning >> process. > > Sounds good, but I want to make several comments: > > - There are several community build viewers today, and they are > supposed to be growing. I hope the new patch updator does not > interfere them. I'm not saying you must support community builds > in your updator, but it should not make using community build > unpractical. Of course it's nice if the new updator is easily > adaptable to non official viewers. > > - Supporting the official three platforms (MacOS, 32 bit Windows, and > i686 Linux) is fine. Please don't forget, however, that there are > more platforms, e.g., x64 Windows, PPC Linux, or SPARC Solaris. > > - We've told that LL runs "Skinning Project" internally, and it will > support drop-in replacement of look-and-feel or UI language through > user-supplied XML files. I hope the patch updator does not break > those custom skin users, too. > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From labrat.hb at gmail.com Wed Oct 10 11:36:34 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Oct 10 11:36:37 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: References: <470C0473.7060301@speakeasy.net> Message-ID: You misunderstood what I was saying. Using 1 prim per character any decent display will exceed the link limits by a large margin. An 80x25 display (DOS screen anyone) is 2000 characters that's 2000 prims or roughly 8 individual linksets. Using a 5-face prim will reduce that down to 400 prims, still 2 individual linksets. Using the 5-face prim with the 2-char XyText font will bring that down to 200 prims. A much more manageable size. And then how are you going to control the texture offset in each prim? A script in each prim? Master / Slave scripts in the root prim? It's still not going to change and display text in microseconds... you're talking something that will take 1-3 seconds to change and fully render. On 10/10/07, SL - Farallon Greyskin wrote: > > Using texture offset you can get every character on every prim, you just > need one prim per character being displayed. > > ----- Original Message ----- > From: Harold Brown > To: Alan Grimes > Cc: sldev@lists.secondlife.com > Sent: Tuesday, October 09, 2007 11:51 PM > Subject: Re: [sldev] WTF happened to my texture? > > > I guess I should warn you now... doing text with a texture is NOT going > to > load up in "microseconds". Nor is it going to be light on prims. With > the > setup you have chosen the best you can possibly get is 5 characters per > prim. > > > On 10/9/07, Alan Grimes wrote: > SL has a problem with text. > > You can't work with it affordably in-world. You have to pay to upload > each one and then to read it, you have to sit and wait for 20 minutes > (okay 5..) for the damn thing to rez before you can read it. > > The simpleton's solution to that is to upload a single texture, a > codepage, and then create letters by mapping different parts of that > codepage to prims. -- too obvious, huh? > > Alright, I fired up my old DOS computer. (Yes, I have a DOS computer) > and snagged myself my favorite font library. > > I then wrote a program to extract the code page I wanted. 437 FOREVER!!! > > It produced a nice little bmp file, 4158 bytes to be exact... > > SL didn't like that so I made a PNG of it so that it wouldn't get > corrupted, 3193 bytes. -- pretty nice, huh? =P (see attached, have a > look at it and then tell me 437 isn't the best codepage ever!!!). > > (image specs: 128 x 256 x 1 bit) > > The whole point is to make an in-world font system that will be > __FAST__, I mean rez as much text as you like in microseconds!!! > > I was thinking oh boy, this'll make me a fortune in lindens!!! -- > ignoring the fact that the linden is devaluing right along with the > dollar. =( > > Then I PAID LINDENS TO UPLOAD IT!!!! =| > > You see, this scheme only works if the font can be uploaded and relayed > to the client in a lossless way. -- being only 3kb, this didn't seem > like an unreasonable demand... > > But what I got back seemed to be 256x512, and then downsized to the > origional... It also seems to have been converted to 24 bit, -- an > unspeakable waste for this application, and finally, some kind of > smoothing operation was performed!!!! -- It may just be that the > GL_LINEAR texture filter was left on... =\ > > The final result is totally unusable as a font system. =( > > When I cough up L$10 to upload a texture I damn well expect that what I > get back is what I uploaded!! =\ > > BTW, Ron Paul has an in-world pavilion. > > > -- > Buy Ron Paul's Money! =) > http://www.libertydollar.org/ld/ronpauldollar > Soundest investment on the planet! > > > _______________________________________________ > 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/20071010/2edbc4ff/attachment.htm From lenglish5 at cox.net Wed Oct 10 13:45:08 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 10 13:45:11 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <470C6C0A.2090502@zurich.ibm.com> <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> Message-ID: <470D39D4.5070606@cox.net> Argent Stonecutter wrote: > > On 10-Oct-2007, at 01:07, dirk husemann wrote: >> if yo change owner & group, doesn't that constitute a transfer? with a >> no-transfer asset you'd go against the wishes of the creator then. > > Owner, yes. Group no. But more to the point, *permissions are > inherently advisory between domains operated by different organizations*. > >>> It can apply to stuff you never even rez in that domain. You might >>> make a change to something in your inventory in a domain that has the >>> same trust level as the original domain, you don't want those changes >>> lost when you return. > >> stuff i leave behind: that is in my view like dropping a snap-shot. it's >> not coming back with me. i would not expect changes that i inflict on it >> in the other domain to have repercussions on the original asset. > > I'm sorry, I just said that I'm not talking about stuff you leave > behind. I was clarifying what stuff you DON'T leave behind could include. > >> inventory changes: that raises the interesting question of whether my >> inventory is modulated by the domain i'm in? in other words, will my >> inventory change depending on where i am or will i always see my full >> inventory, i just won't be able to rez some items in certain domains? > > OK, I'm not just talking about the list of objects in my inventory, > I'm talking about the assets themselves. When you go from one domain > to another, and go into your inventory, and bring up the properties of > an object in your inventory, where is the asset that you are bringing > up the properties on? The trust relationship between the domain the > asset is in and the domain you're in should determine if you can bring > up the properties at all, and *separately* whether you can get at the > content of the asset itself. > > That is, you bring up "fred's cool shirt" in domain-fred-doesn't-trust > and you see the name, owner, description, rights, and so on. But you > still can't wear the shirt. > > What I'm envisioning here is that *in that domain* that shirt is > represented by a placeholder copy of the asset that's a reference back > to the original. > _______________________________________________ I think that things might even become MORE complicated. As I said, distributed object systems have to deal with many of these issues. I believe that the one that dealt with them most like what we're talking about here is the old OpenDoc compound document system. Certainly, OD went further in its discussion of the issues than OLE ever did: http://www.mactech.com/articles/mactech/Vol.13/13.06/LinksinOpenDocParts/index.html From seg at haxxed.com Wed Oct 10 14:21:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Oct 10 14:21:51 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: References: <470C0473.7060301@speakeasy.net> Message-ID: <1192051292.29582.137.camel@localhost> On Wed, 2007-10-10 at 11:36 -0700, Harold Brown wrote: > And then how are you going to control the texture offset in each prim? > A script in each prim? Master / Slave scripts in the root prim? It's > still not going to change and display text in microseconds... you're > talking something that will take 1-3 seconds to change and fully > render. A fundamental architectural problem in SL that I really hope gets addressed someday. Mind you, text on a prim really ought to be done with SVG. But the inability to have synchronous updates among a large number of prims is a major deficiency IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071010/44a9d906/attachment.pgp From dzonatas at dzonux.net Wed Oct 10 14:53:13 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Oct 10 14:53:08 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <1192051292.29582.137.camel@localhost> References: <470C0473.7060301@speakeasy.net> <1192051292.29582.137.camel@localhost> Message-ID: <470D49C9.5070909@dzonux.net> Callum Lerwick wrote: > Mind you, text on a prim really ought to be done with SVG. > I agree with SVG! It can be set to be very strict and still have HTML embedded in it. The UI events of SVG could make programming interfaces much easier. -- Power to Change the Void From sl at phoca.com Wed Oct 10 16:16:10 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Wed Oct 10 16:16:26 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: References: <470C0473.7060301@speakeasy.net> Message-ID: <52786548A4BD43EA91269A528C610FF9@SanMiguel> Ah, yes of course, I was thinking more along the lines of a 20 character display or something where it is possible to be very very fast and not overly script burdensome, but an 80x25 display is completely different :D Basic drawing/font rendering on a prim is definitely a utility of great signifigence, however it's done. Hopefully we can see that done sooner rather than later and I too like the idea of a drawing api rather than html at this time. In fact if it were done completely as an add on for the Open Source viewers, and assuming it was done in a reasonable way. Maybe it would be more likely that it would get migrated to the main client sooner rather than later? :) Farallon ----- Original Message ----- From: Harold Brown To: SL - Farallon Greyskin Cc: sldev@lists.secondlife.com Sent: Wednesday, October 10, 2007 11:36 AM Subject: Re: [sldev] WTF happened to my texture? You misunderstood what I was saying. Using 1 prim per character any decent display will exceed the link limits by a large margin. An 80x25 display (DOS screen anyone) is 2000 characters that's 2000 prims or roughly 8 individual linksets. Using a 5-face prim will reduce that down to 400 prims, still 2 individual linksets. Using the 5-face prim with the 2-char XyText font will bring that down to 200 prims. A much more manageable size. And then how are you going to control the texture offset in each prim? A script in each prim? Master / Slave scripts in the root prim? It's still not going to change and display text in microseconds... you're talking something that will take 1-3 seconds to change and fully render. On 10/10/07, SL - Farallon Greyskin wrote: Using texture offset you can get every character on every prim, you just need one prim per character being displayed. ----- Original Message ----- From: Harold Brown To: Alan Grimes Cc: sldev@lists.secondlife.com Sent: Tuesday, October 09, 2007 11:51 PM Subject: Re: [sldev] WTF happened to my texture? I guess I should warn you now... doing text with a texture is NOT going to load up in "microseconds". Nor is it going to be light on prims. With the setup you have chosen the best you can possibly get is 5 characters per prim. On 10/9/07, Alan Grimes wrote: SL has a problem with text. You can't work with it affordably in-world. You have to pay to upload each one and then to read it, you have to sit and wait for 20 minutes (okay 5..) for the damn thing to rez before you can read it. The simpleton's solution to that is to upload a single texture, a codepage, and then create letters by mapping different parts of that codepage to prims. -- too obvious, huh? Alright, I fired up my old DOS computer. (Yes, I have a DOS computer) and snagged myself my favorite font library. I then wrote a program to extract the code page I wanted. 437 FOREVER!!! It produced a nice little bmp file, 4158 bytes to be exact... SL didn't like that so I made a PNG of it so that it wouldn't get corrupted, 3193 bytes. -- pretty nice, huh? =P (see attached, have a look at it and then tell me 437 isn't the best codepage ever!!!). (image specs: 128 x 256 x 1 bit) The whole point is to make an in-world font system that will be __FAST__, I mean rez as much text as you like in microseconds!!! I was thinking oh boy, this'll make me a fortune in lindens!!! -- ignoring the fact that the linden is devaluing right along with the dollar. =( Then I PAID LINDENS TO UPLOAD IT!!!! =| You see, this scheme only works if the font can be uploaded and relayed to the client in a lossless way. -- being only 3kb, this didn't seem like an unreasonable demand... But what I got back seemed to be 256x512, and then downsized to the origional... It also seems to have been converted to 24 bit, -- an unspeakable waste for this application, and finally, some kind of smoothing operation was performed!!!! -- It may just be that the GL_LINEAR texture filter was left on... =\ The final result is totally unusable as a font system. =( When I cough up L$10 to upload a texture I damn well expect that what I get back is what I uploaded!! =\ BTW, Ron Paul has an in-world pavilion. -- Buy Ron Paul's Money! =) http://www.libertydollar.org/ld/ronpauldollar Soundest investment on the planet! _______________________________________________ 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/20071010/5fcbdf5d/attachment.htm From secret.argent at gmail.com Wed Oct 10 16:35:12 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 10 16:35:18 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <470D49C9.5070909@dzonux.net> References: <470C0473.7060301@speakeasy.net> <1192051292.29582.137.camel@localhost> <470D49C9.5070909@dzonux.net> Message-ID: <57B25690-620E-471E-943F-6A245B2DF822@gmail.com> On 10-Oct-2007, at 16:53, Dzonatas wrote: > I agree with SVG! It can be set to be very strict and still have > HTML embedded in it. I'd rather not have HTML embedded in it, thanks. (there's not much HTML in it) (what have you got without HTML then?) (well, there's SVG) (and there's no HTML in it?) (we've got SVG and HTML, and SVG and HTML and HTML, and HTML on toast) (Forget it, I'll take the spam) From rdw at lindenlab.com Wed Oct 10 19:21:23 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Oct 10 19:21:49 2007 Subject: [sldev] Packaging the viewer for Linux distributions In-Reply-To: References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <8718DEAD-2A97-4D8F-95DA-3D882285B82D@lindenlab.com> Message-ID: <470D88A3.7070105@lindenlab.com> One thing I noticed in my studies of this problem was that for all platforms the viewer consists of two parts: - the secondlife executable (~50%) - everything else (~50%) It's cool to come up with a scheme to cut out the everything else, but you can get much bigger wins by doing a binary delta on the executable. Most versions change 10% or less of the executable from the previous version. I was able to get diffs as small as 1 megabyte by simply binary diff-ing between two trees using bsdiff. That's how Firefox does it, and I love the way their updater is completely unobtrusive and fast. You get the patch from a web service, so simply change the url for that in your custom viewer and set up your own patch service, and you're golden. -RYaN Robin Cornelius wrote: > On 10/9/07, Argent Stonecutter wrote: > >> On 09-Oct-2007, at 09:19, Matthew Wiggins wrote: >> >>> As you've rightly pointed out, there is a significant amount of non- >>> changing data between releases so we should be able to cut the size >>> of updates by a large amount. As Bushing Spatula has found on that >>> VVR-603, getting to a 12MB delta is easily achievable. The main >>> challenge is producing a system that works on all three platforms >>> in a pleasing way for the user, and plays nicely with our >>> versioning process. >>> >> You could use rsync. :) >> >> Actually, only half :). >> >> It might work. >> >> > > Seems like a pretty good idea, librsync can be wrapped up nicely (if > required) and it should provide a pretty efficient method of update. > Its cross platform and a standard technology. > > My only concern is that there must be a way of disabling it or > perhapses running a custom script etc so if people are following > nicholaz patch sets they don't suddenly get updated to a linden > original etc. Although the update detector currently dosn't do this. > But it may be nice if it could be redirected so that people running > 3rd party builds can have there own update repository. It would save > my upload bandwith. > > Robin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From ettore_pasquini at 3dconnexion.com Wed Oct 10 19:31:05 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Wed Oct 10 19:31:07 2007 Subject: [sldev] [VWR] How to "commit" translations in Build mode? In-Reply-To: <200710092348.03505.dale@daleglass.net> Message-ID: On 10/9/07 2:47 PM, "Dale Glass" wrote: > On Tuesday 09 October 2007 22:02:43 Ettore Pasquini wrote: >> I added a method to LLSelectMgr to translate the selected objects by a >> given vector in Build mode. The motion per se happens correctly, but >> when I release the objects (i.e. unselect them) they bounce back to the >> original location. What's more puzzling is that rotations *are* >> "committed" correctly. I don't understand why translations would require >> a different treatment. How to "commit" them to the new position? >> This is my code (extracted and adapted from >> LLSelectMgr::sendListToRegions) > Ok, at first glance: > > You're packing multiple updates in one packet. If you reach the limit, or > change simulator, you send the current packet and start a new one. > > Except, you don't send whatever remains buffered after the loop ends. Thanks Dale, that was it! E From gigstaggart at gmail.com Wed Oct 10 22:12:44 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Oct 10 22:12:40 2007 Subject: [sldev] WTF happened to my texture? In-Reply-To: <52786548A4BD43EA91269A528C610FF9@SanMiguel> References: <470C0473.7060301@speakeasy.net> <52786548A4BD43EA91269A528C610FF9@SanMiguel> Message-ID: <470DB0CC.8090109@gmail.com> We are kinda waiting for extensible prim attributes before we can do this. If we got extensible prim attributes that could carry a decent payload (a few hundred bytes) then it would be pretty easy. -Jason SL - Farallon Greyskin wrote: > Basic drawing/font rendering on a prim is definitely a utility of great > signifigence, however it's done. Hopefully we can see that done sooner > rather than later and I too like the idea of a drawing api rather than > html at this time. In fact if it were done completely as an add on for > the Open Source viewers, and assuming it was done in a reasonable way. > Maybe it would be more likely that it would get migrated to the main > client sooner rather than later? :) > > Farallon From hud at zurich.ibm.com Wed Oct 10 22:07:08 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 10 23:25:34 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> Message-ID: <470DAF7C.3020501@zurich.ibm.com> Argent Stonecutter wrote: > On 09-Oct-2007, at 22:28, Callum Lerwick wrote: >> On Tue, 2007-10-09 at 09:30 -0500, Argent Stonecutter wrote: >>> It can apply to stuff you never even rez in that domain. You might >>> make a change to something in your inventory in a domain that has the >>> same trust level as the original domain, you don't want those changes >>> lost when you return. > >> I don't know what you're even on about here. Your inventory lives in the >> *Agent* domain, its not moving anywhere. > > Your inventory contains assets. > > You change an asset in your inventory, changing its name or > permissions, where does that happen? > > If it happens in the agent server, then you've already answered the > original question - the master copy is the instance of the inventory > object in that server. > > If it happens in the asset server, then the asset server it happens in > has to trust the domain that you're making the change from. i would have thought that it has to trust the client? -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Wed Oct 10 22:24:22 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 10 23:25:37 2007 Subject: [sldev] AWG: Good time to clean up or update the Wiki In-Reply-To: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> References: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> Message-ID: <470DB386.3080103@zurich.ibm.com> Mark Burhop wrote: > Saw this on CNN's site: > > IBM and Linden Lab Launch Collaboration to Further Advance the 3D Internet > http://money.cnn.com/news/newsfeeds/articles/marketwire/0313677.htm > > Interesting news but beyond that, it has a direct link to the > Architecture Working Group Wiki. This might be a good time for us to > to clean up and update content. > > http://wiki.secondlife.com/wiki/Architecture_Working_Group :-) yes. cheers, dirk / dr scofield (who has to get the glossary page started) -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071011/a16a6173/attachment.htm From hud at zurich.ibm.com Wed Oct 10 22:19:03 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 10 23:25:39 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <470C6C0A.2090502@zurich.ibm.com> <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> Message-ID: <470DB247.8000106@zurich.ibm.com> Argent Stonecutter wrote: > > On 10-Oct-2007, at 01:07, dirk husemann wrote: >> if yo change owner & group, doesn't that constitute a transfer? with a >> no-transfer asset you'd go against the wishes of the creator then. > > Owner, yes. Group no. But more to the point, *permissions are > inherently advisory between domains operated by different organizations*. i know. we worked that out. my thinking though was that we assume permissions to be binding and not explicitly spec that they are just a bunch of bits that we can ignore. what's your thinking on that? > >>> It can apply to stuff you never even rez in that domain. You might >>> make a change to something in your inventory in a domain that has the >>> same trust level as the original domain, you don't want those changes >>> lost when you return. > >> stuff i leave behind: that is in my view like dropping a snap-shot. it's >> not coming back with me. i would not expect changes that i inflict on it >> in the other domain to have repercussions on the original asset. > > I'm sorry, I just said that I'm not talking about stuff you leave > behind. I was clarifying what stuff you DON'T leave behind could include. sorry, i misunderstood you then, thought you were including "stuff you leave behind" in your answer. > > >> inventory changes: that raises the interesting question of whether my >> inventory is modulated by the domain i'm in? in other words, will my >> inventory change depending on where i am or will i always see my full >> inventory, i just won't be able to rez some items in certain domains? > > OK, I'm not just talking about the list of objects in my inventory, > I'm talking about the assets themselves. When you go from one domain > to another, and go into your inventory, and bring up the properties of > an object in your inventory, where is the asset that you are bringing > up the properties on? The trust relationship between the domain the > asset is in and the domain you're in should determine if you can bring > up the properties at all, and *separately* whether you can get at the > content of the asset itself. bringing up an asset in my inventory is for me a client internal operation. as long as it's not rezz'ed i don't think we have to bother about which region domain i'm in. if i change a property of an asset in my inventory that should go back directly to the asset server of that object. still nothing to do with the region domain i'm in. it won't even notice that i did something with that object in my inventory. > > That is, you bring up "fred's cool shirt" in domain-fred-doesn't-trust > and you see the name, owner, description, rights, and so on. But you > still can't wear the shirt. agree. domain-fred-doesn't-trust doesn't even notice that i looked at "fred's cool shirt" in my inventory. > > What I'm envisioning here is that *in that domain* that shirt is > represented by a placeholder copy of the asset that's a reference back > to the original. why? you can't rez it there anyhow and you've not been wearing it when you entered that domain. i'd leave this entirely to the client: the client could have a fallback appearance (if you don't want to appear naked in that domain) to use when you enter domains where you cannot take clothing/stuff you are wearing with you. from an architecture point of view i don't care. cheers, dirk/dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Wed Oct 10 22:05:54 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Oct 10 23:25:41 2007 Subject: bots.txt (was Re: [sldev] CAPTCHA to validate land sales.) In-Reply-To: References: <50181.86.10.79.229.1191406262.squirrel@webmail.terminaldischarge.net> <20071003143915.GC29227@bruno.sbruno> <53D91F5E-9812-49C5-B35B-B261B95895BE@gmail.com> <200710031815.12231.dale@daleglass.net> <4705CAB9.4080401@zurich.ibm.com> <470C1204.9040500@lindenlab.com> <470C96D9.6060909@zurich.ibm.com> Message-ID: <470DAF32.80003@zurich.ibm.com> Matthew Dowd wrote: > > There's been a lot of discussion about adding arbitrary custom > attributes to prims for use by open source applications etc. Is this > moving into a need to something similar for parcels/estates? good question. i myself am not sure yet: after all this is just one additional feature, not yet a series of features (can't think that fast ;-) are you thinking of an annotation(s) URL for parcels/estates? cheers, dirk/dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071011/9b175cf5/attachment.htm From alexander.treptow at zweitgeist.com Thu Oct 11 00:15:20 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Oct 11 00:15:34 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470CF3BD.1030407@gmail.com> References: <470CD78E.3080003@zweitgeist.com> <470CF3BD.1030407@gmail.com> Message-ID: <470DCD88.1090801@zweitgeist.com> Tateru Nino schrieb: > I could be wrong, but shouldn't that be FF FF 00 03 (UseCircuitCode)? You are right, its FF FF 00 03 but sadly it doesnt solve the problem that i dont know how to and why keep a tcp-connection running on port 12043. From tateru.nino at gmail.com Thu Oct 11 01:15:34 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Oct 11 01:15:43 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470DCD88.1090801@zweitgeist.com> References: <470CD78E.3080003@zweitgeist.com> <470CF3BD.1030407@gmail.com> <470DCD88.1090801@zweitgeist.com> Message-ID: <470DDBA6.5020600@gmail.com> alexander treptow wrote: > Tateru Nino schrieb: >> I could be wrong, but shouldn't that be FF FF 00 03 (UseCircuitCode)? > You are right, its FF FF 00 03 but sadly it doesnt solve the problem > that i dont know how to and why keep a tcp-connection running on port > 12043. > tcp/12043 would be the CAPS request from the seed capability string provided by the login server. You shouldn't _need_ to make that connection unless you want data from the CAPS web services. Unless there's an extra requirement that I'm otherwise unaware of. -- Tateru Nino http://dwellonit.blogspot.com/ From lenglish5 at cox.net Thu Oct 11 01:32:28 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Oct 11 01:32:36 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DAF7C.3020501@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> Message-ID: <470DDF9C.6030107@cox.net> dirk husemann wrote: > Argent Stonecutter wrote: > >> On 09-Oct-2007, at 22:28, Callum Lerwick wrote: >> >>> On Tue, 2007-10-09 at 09:30 -0500, Argent Stonecutter wrote: >>> >>>> It can apply to stuff you never even rez in that domain. You might >>>> make a change to something in your inventory in a domain that has the >>>> same trust level as the original domain, you don't want those changes >>>> lost when you return. >>>> >>> I don't know what you're even on about here. Your inventory lives in the >>> *Agent* domain, its not moving anywhere. >>> >> Your inventory contains assets. >> >> You change an asset in your inventory, changing its name or >> permissions, where does that happen? >> >> If it happens in the agent server, then you've already answered the >> original question - the master copy is the instance of the inventory >> object in that server. >> >> If it happens in the asset server, then the asset server it happens in >> has to trust the domain that you're making the change from. >> > i would have thought that it has to trust the client? > > The client is completely untrustworthy. At most you can *hope* that a user isn't malicious. Lawson From alexander.treptow at zweitgeist.com Thu Oct 11 01:35:14 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Oct 11 01:35:28 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470DDBA6.5020600@gmail.com> References: <470CD78E.3080003@zweitgeist.com> <470CF3BD.1030407@gmail.com> <470DCD88.1090801@zweitgeist.com> <470DDBA6.5020600@gmail.com> Message-ID: <470DE042.8050502@zweitgeist.com> Tateru Nino schrieb: > alexander treptow wrote: > >> that i dont know how to and why keep a tcp-connection running on port 12043. >> > tcp/12043 would be the CAPS request from the seed capability string > provided by the login server. You shouldn't _need_ to make that > connection unless you want data from the CAPS web services. Unless > there's an extra requirement that I'm otherwise unaware of. > Ok thx, i think i dont need that data. But what else i've to do to get from the server the charakters skeleton, texture and all data i need to show the charakter. For the image requests i got some folder_id's from the login request, right? How can i get the sim to answer me? From hud at zurich.ibm.com Thu Oct 11 01:50:30 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 11 01:51:01 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DDF9C.6030107@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> Message-ID: <470DE3D6.5070608@zurich.ibm.com> Lawson English wrote: > dirk husemann wrote: [...] >> i would have thought that it has to trust the client? >> >> > The client is completely untrustworthy. > > At most you can *hope* that a user isn't malicious. yes, quite :-) the point was that it's a client side issue, not a region domain issue: inventory items are not rezz'd. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From lenglish5 at cox.net Thu Oct 11 02:27:24 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Oct 11 02:27:27 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DE3D6.5070608@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> Message-ID: <470DEC7C.9060602@cox.net> dirk husemann wrote: > Lawson English wrote: > >> dirk husemann wrote: >> > [...] > >>> i would have thought that it has to trust the client? >>> >>> >>> >> The client is completely untrustworthy. >> >> At most you can *hope* that a user isn't malicious. >> > yes, quite :-) the point was that it's a client side issue, not a region > domain issue: inventory items are not rezz'd. > > cheers, > dirk > > > Currently, the asset server learns about just about anything you've done to the asset in your inventory. I believe that includes renaming it. L. From tateru.nino at gmail.com Thu Oct 11 02:41:55 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Oct 11 02:42:07 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470DE042.8050502@zweitgeist.com> References: <470CD78E.3080003@zweitgeist.com> <470CF3BD.1030407@gmail.com> <470DCD88.1090801@zweitgeist.com> <470DDBA6.5020600@gmail.com> <470DE042.8050502@zweitgeist.com> Message-ID: <470DEFE3.2010400@gmail.com> alexander treptow wrote: > Tateru Nino schrieb: >> alexander treptow wrote: >> >>> that i dont know how to and why keep a tcp-connection running on >>> port 12043. >>> >> tcp/12043 would be the CAPS request from the seed capability string >> provided by the login server. You shouldn't _need_ to make that >> connection unless you want data from the CAPS web services. Unless >> there's an extra requirement that I'm otherwise unaware of. >> > Ok thx, i think i dont need that data. > But what else i've to do to get from the server the charakters > skeleton, texture and all data i need to show the charakter. > For the image requests i got some folder_id's from the login request, > right? > How can i get the sim to answer me? I'm not actually sure. I've gotten as far as you've gotten. Fling a UDP packet into the void and never get a reply. Obviously, something is missing. -- Tateru Nino http://dwellonit.blogspot.com/ From alexander.treptow at zweitgeist.com Thu Oct 11 03:16:52 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Oct 11 03:17:07 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470DEFE3.2010400@gmail.com> References: <470CD78E.3080003@zweitgeist.com> <470CF3BD.1030407@gmail.com> <470DCD88.1090801@zweitgeist.com> <470DDBA6.5020600@gmail.com> <470DE042.8050502@zweitgeist.com> <470DEFE3.2010400@gmail.com> Message-ID: <470DF814.7060806@zweitgeist.com> Tateru Nino schrieb: > I'm not actually sure. I've gotten as far as you've gotten. Fling a UDP > packet into the void and never get a reply. Obviously, something is missing. Ok i'll try it the other way around. I'll take the full Viewer and delete all whats not needed for viewing my Avatar. But there s a little problem too, first the message pop up that there are some files missing that the viewer needs and on startup with STATE_MISC on gesture loading next to line 2134 the viewer crashes in function llthread::lockdata() The os is a win xp with vc2003 From hud at zurich.ibm.com Thu Oct 11 03:22:51 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Oct 11 03:23:58 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DEC7C.9060602@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> <470DEC7C.9060602@cox.net> Message-ID: <470DF97B.4040509@zurich.ibm.com> Lawson English wrote: > dirk husemann wrote: >> Lawson English wrote: >> >>> dirk husemann wrote: >>> >> [...] >> >>>> i would have thought that it has to trust the client? >>>> >>>> >>> The client is completely untrustworthy. >>> >>> At most you can *hope* that a user isn't malicious. >>> >> yes, quite :-) the point was that it's a client side issue, not a region >> domain issue: inventory items are not rezz'd. >> cheers, >> dirk >> >> >> > > Currently, the asset server learns about just about anything you've > done to the asset in your inventory. I believe that includes renaming it. which fits exactly what i'm proposing :-) dirk/dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From alissa_sabre at yahoo.co.jp Wed Oct 10 16:46:48 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Oct 11 05:43:12 2007 Subject: [sldev] Help compiling the Viewer (could not deduce template argument ... from 'LLMessageThrottleEntry') In-Reply-To: References: Message-ID: <1ds7G34kwids4dsodsafo.alissa_sabre@yahoo.co.jp> > I set up a page: > https://wiki.secondlife.com/wiki/Compiling_Issues_with_Vista/MSVS2008 Sorry for disturbing you, but can you avoid using a slash (/) in the wiki page title? I believe you put a slash between "Vista" and "MSVS2008" to mean something like "a combination of the two." In MediaWki, a slash in a page title has a special function. It makes a page grouping called "subpages". It just works as a directory in a filesystem. What you actually did is creating an empty page of title "Compiling Issues with Vista" and putting a subpage of title "MSVS2008" in it... # You don't need to type the same content again; you can just "move" the page. It is the preferred way, since "move" preserves the edit history of the page (like "svn rename".) -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From mark.burhop at gmail.com Thu Oct 11 06:52:35 2007 From: mark.burhop at gmail.com (Mark Burhop) Date: Thu Oct 11 06:52:42 2007 Subject: [sldev] AWG: Good time to clean up or update the Wiki In-Reply-To: <470DB386.3080103@zurich.ibm.com> References: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> <470DB386.3080103@zurich.ibm.com> Message-ID: <773a33dc0710110652y763d164elc3dd2302a759bd3e@mail.gmail.com> > > > http://wiki.secondlife.com/wiki/Architecture_Working_Group > > > :-) yes. > > cheers, > dirk / dr scofield (who has to get the glossary page started) > Great! I tried to expand out a few use cases for fire walls and security last night. I'm strugling a bit with the exact meaning of some terms so a glossary will help. http://wiki.secondlife.com/wiki/Use_Cases#Firewall_related_Use_Cases If anyone wants to add some comments to the discussion page for these use cases, have at it. Some iteration is needed to make sure I'm capturing the right things. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071011/14531da9/attachment-0001.htm From secret.argent at gmail.com Thu Oct 11 07:09:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 11 07:09:15 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DB247.8000106@zurich.ibm.com> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <470C6C0A.2090502@zurich.ibm.com> <2850E6BA-136E-4AC0-81CD-3D9E3FB8D354@gmail.com> <470DB247.8000106@zurich.ibm.com> Message-ID: <82027944-5A53-4803-8C9C-25EE51FBC2FE@gmail.com> On 11-Oct-2007, at 00:19, dirk husemann wrote: > Argent Stonecutter wrote: >> On 10-Oct-2007, at 01:07, dirk husemann wrote: >>> if yo change owner & group, doesn't that constitute a transfer? >>> with a >>> no-transfer asset you'd go against the wishes of the creator then. >> Owner, yes. Group no. But more to the point, *permissions are >> inherently advisory between domains operated by different >> organizations*. > i know. we worked that out. my thinking though was that we assume > permissions to be binding and not explicitly spec that they are just a > bunch of bits that we can ignore. what's your thinking on that? I think that we need to define how domains manage trust. I think we need to pay a lot more attention to that than I've seen happening. >>> inventory changes: that raises the interesting question of >>> whether my >>> inventory is modulated by the domain i'm in? in other words, will my >>> inventory change depending on where i am or will i always see my >>> full >>> inventory, i just won't be able to rez some items in certain >>> domains? >> OK, I'm not just talking about the list of objects in my inventory, >> I'm talking about the assets themselves. When you go from one domain >> to another, and go into your inventory, and bring up the >> properties of >> an object in your inventory, where is the asset that you are bringing >> up the properties on? The trust relationship between the domain the >> asset is in and the domain you're in should determine if you can >> bring >> up the properties at all, and *separately* whether you can get at the >> content of the asset itself. > bringing up an asset in my inventory is for me a client internal > operation. It's an operation between the client and the asset server and the agent server, all of which are part of the architecture. Plus, the inventory exists in multiple domains, no? Or is there some master agent domain that owns all the agents in all domains? > as long as it's not rezz'ed i don't think we have to bother > about which region domain i'm in. It depends on what agent domain you're in, no? > if i change a property of an asset in > my inventory that should go back directly to the asset server of that > object. Even ignoring an asset that exists in multiple inventories, you can have an asset twice in your inventory with different permissions. You can't copy assets every time you make a copy in your inventory or even every time you give someone a copy, there's no point, you only need to copy the properties and leave a reference to the original. The copy in your inventory doesn't even need to exist on any asset server until it gets rezzed into a region domain. Then it shows up as a reference on that domain's asset server pointing to the data on the original server. You're wearing that copy, it's in your inventory, but it's a reference to the original until you create a new asset. From secret.argent at gmail.com Thu Oct 11 07:23:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 11 07:24:11 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <470DEC7C.9060602@cox.net> References: <4706AEB1.7050601@cox.net> <470734AD.4080802@cox.net> <89C984C5-1E13-4040-AED0-2D564E690038@gmail.com> <920d7d850710060915y7166e5b2n1b4201003742af05@mail.gmail.com> <1191703325.26663.98.camel@localhost> <222BAE4E-4EFB-4E84-9C08-5D92D5051673@gmail.com> <47098475.9060100@wsu.edu> <4709F5AA.6010704@zurich.ibm.com> <1191900602.29582.33.camel@localhost> <6A5EF4D6-E16A-4B42-9C1B-A489DA257684@gmail.com> <470B26A0.2070704@zurich.ibm.com> <6C496C94-A5C3-44D6-A49C-2AE63C456931@gmail.com> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> <470DEC7C.9060602@cox.net> Message-ID: <6CADF786-0940-4DDA-A2E2-DE19E75EE275@gmail.com> On 11-Oct-2007, at 04:27, Lawson English wrote: > Currently, the asset server learns about just about anything you've > done to the asset in your inventory. I believe that includes > renaming it. Does it actually create a new asset when you copy a texture? I thought they didn't create a new asset until you modified the actual data, and for assets like textures that never happened. I'm pretty sure that creating a new copy of an asset doesn't create a new asset, otherwise they wouldn't be so big on the whole "scripts can't create assets so they can't edit notecards" things... because then a script would beat up on the asset server every time it rezzed something in world. When you have multiple domains you want to be able to defer hitting the asset server even more than you do now. Which is the whole point to this separation of data and properties that I'm talking about. Oh, and Dirk, when you go from region A to region B your T-shirt won't vanish, because your T-shirt is part of your baked texture, and that will just be uploaded to the new region from the client. In fact, since baking textures is between the client and the asset server, I'm not sure that it would need to involve the region at all. From scrosta at cisco.com Thu Oct 11 07:46:21 2007 From: scrosta at cisco.com (Stefano Crosta (scrosta)) Date: Thu Oct 11 07:46:38 2007 Subject: [sldev] Help compiling the Viewer (could not deduce In-Reply-To: <20071011135246.7634E41B3A1@stupor.lindenlab.com> References: <20071011135246.7634E41B3A1@stupor.lindenlab.com> Message-ID: No problem. In this case the difference is subtle. If there's enough people using Vista and having issues building under Vista it might make sense to actually just create the https://wiki.secondlife.com/wiki/Compiling_Issues_with_Vista and have specific sub-pages for MSVS9,8,7,6 etc. (and keep the actual one where it is). Any interest in that? Otherwise I'll just move the page to Compiling_Issues_with_Vista_and_MSVS2008. Please let me know. Unicast will do if you don't want to have this conversation on SLDEV. Concerning the issue, I'm really clueless, all I could understand is the page on the wiki; the compiler gets lost in a template resolution for the operator == comparing the two iterator types which are a deque inside the search_n template-based function. I am now try re-compiling with the more supported VC8. stefano > Date: Thu, 11 Oct 2007 08:46:48 +0900 > From: alissa_sabre@yahoo.co.jp (Alissa Sabre) > Subject: RE: [sldev] Help compiling the Viewer (could not deduce > template argument ... from 'LLMessageThrottleEntry') > To: sldev@lists.secondlife.com > Message-ID: <1ds7G34kwids4dsodsafo.alissa_sabre@yahoo.co.jp> > Content-Type: text/plain; charset=US-ASCII > > > I set up a page: > > > https://wiki.secondlife.com/wiki/Compiling_Issues_with_Vista/MSVS2008 > > Sorry for disturbing you, but can you avoid using a slash (/) in the > wiki page title? I believe you put a slash between "Vista" and > "MSVS2008" to mean something like "a combination of the two." > > In MediaWki, a slash in a page title has a special function. It makes > a page grouping called "subpages". It just works as a directory in a > filesystem. What you actually did is creating an empty page of title > "Compiling Issues with Vista" and putting a subpage of title > "MSVS2008" in it... > > # You don't need to type the same content again; you can just "move" > the page. It is the preferred way, since "move" preserves the edit > history of the page (like "svn rename".) > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ From roamingryozu at gmail.com Thu Oct 11 07:49:05 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Thu Oct 11 07:57:33 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <6CADF786-0940-4DDA-A2E2-DE19E75EE275@gmail.com> References: <4706AEB1.7050601@cox.net> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> <470DEC7C.9060602@cox.net> <6CADF786-0940-4DDA-A2E2-DE19E75EE275@gmail.com> Message-ID: <5eff6d3b0710110749k61e302b9qc6ecfaa36ab757a@mail.gmail.com> On 10/11/07, Argent Stonecutter wrote: > On 11-Oct-2007, at 04:27, Lawson English wrote: > > Currently, the asset server learns about just about anything you've > > done to the asset in your inventory. I believe that includes > > renaming it. > > Does it actually create a new asset when you copy a texture? > > I thought they didn't create a new asset until you modified the > actual data, and for assets like textures that never happened. > Right, except properties such as Modify/Copy/Transfer, Owner, Etc. Currently, copying a texture or changing these values does not give a new Asset ID, however. > I'm pretty sure that creating a new copy of an asset doesn't create a > new asset, otherwise they wouldn't be so big on the whole "scripts > can't create assets so they can't edit notecards" things... because > then a script would beat up on the asset server every time it rezzed > something in world. Actually, rezzing prim objects in world does give each new object a new Asset ID. Guns DO beat up on the asset server. > > When you have multiple domains you want to be able to defer hitting > the asset server even more than you do now. > > Which is the whole point to this separation of data and properties > that I'm talking about. > Seems that's the way it already is more or less. > Oh, and Dirk, when you go from region A to region B your T-shirt > won't vanish, because your T-shirt is part of your baked texture, and > that will just be uploaded to the new region from the client. In > fact, since baking textures is between the client and the asset > server, I'm not sure that it would need to involve the region at all. Baked textures should inherit the permissions of the assets it was baked from. There's no point otherwise in any of this region restriction. Honestly, I think region to region asset management is as simple as identity management. Your inventory is very much a part of your identity. Identity servers may allow/restrict logging into 3rd party regions. In such a case, your avatar would be defined by whatever identity you did log into a region with. Sparing that, you become could use a default fallback appearance (Ruth anyone?) From secret.argent at gmail.com Thu Oct 11 08:21:28 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 11 08:21:39 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <5eff6d3b0710110749k61e302b9qc6ecfaa36ab757a@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> <470DEC7C.9060602@cox.net> <6CADF786-0940-4DDA-A2E2-DE19E75EE275@gmail.com> <5eff6d3b0710110749k61e302b9qc6ecfaa36ab757a@mail.gmail.com> Message-ID: <1A746EC1-EBF7-423B-96AC-B51F28F07D80@gmail.com> On 11-Oct-2007, at 09:49, Andre Roche wrote: > On 10/11/07, Argent Stonecutter wrote: >> I'm pretty sure that creating a new copy of an asset doesn't create a >> new asset, otherwise they wouldn't be so big on the whole "scripts >> can't create assets so they can't edit notecards" things... because >> then a script would beat up on the asset server every time it rezzed >> something in world. > Actually, rezzing prim objects in world does give each new object a > new Asset ID. I thought the UUID for prim objects in world was generated by the region, and the "asset server" for prims was the region. > Guns DO beat up on the asset server. Even if I'm wrong, that shouldn't be necessary. In any case, my mental model here that I'm working with is the model of an efficient architecture... perhaps we could design one that doesn't require the asset server to know about all this scurf, whether a particular instance of the WWVW (world wide virtual world) takes advantage of the optimizations possible or not. It should be possible to change the name of an object in your inventory without bothering the asset server. It should be possible to do that while that particular asset server is down, and have it resynced when it comes back up again, and use a cached copy of the asset data that's already been transferred with the asset server's approval if there happens to be one in the domain you're in. Remember, with multiple domains and asset servers it's going > Baked textures should inherit the permissions of the assets it was > baked from. Except the baked texture belongs to the client. The client isn't trusted. The client currently caches baked textures and I'm pretty sure it doesn't keep track of permissions on them. > Honestly, I think region to region asset management is as simple as > identity management. What I'm describing isn't complex, and it's going to happen anyway in a bunch of different variations with different and inconsistent rules once people realize that it sucks to have stuff vanish or go "unknown texture" when some host for Joe's Grid And Bait Shop goes down. It's simpler to get it right now rather than just letting it evolve. From phoenix at secondlife.com Thu Oct 11 08:56:36 2007 From: phoenix at secondlife.com (Phoenix) Date: Thu Oct 11 08:56:55 2007 Subject: [sldev] Help compiling the Viewer (could not deduce template argument ... from 'LLMessageThrottleEntry') In-Reply-To: <1ds7G34kwids4dsodsafo.alissa_sabre@yahoo.co.jp> References: <1ds7G34kwids4dsodsafo.alissa_sabre@yahoo.co.jp> Message-ID: On 2007-10-10, at 16:46, Alissa Sabre wrote: >> I set up a page: >> https://wiki.secondlife.com/wiki/Compiling_Issues_with_Vista/MSVS2008 > > Sorry for disturbing you, but can you avoid using a slash (/) in the > wiki page title? I believe you put a slash between "Vista" and > "MSVS2008" to mean something like "a combination of the two." agreed. https://wiki.secondlife.com/wiki/ Compiling_Issues_with_Vista_and_MSVS2008 -------------- 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/20071011/7832aee8/PGP-0001.pgp From tillie at xp2.de Thu Oct 11 09:27:12 2007 From: tillie at xp2.de (Tillie Ariantho) Date: Thu Oct 11 09:27:59 2007 Subject: [sldev] Open Source Meeting - Agenda draft In-Reply-To: <470D138F.1050105@lindenlab.com> References: <773a33dc0710100949i668988e5j9993f3abe90a1c7a@mail.gmail.com> <470D138F.1050105@lindenlab.com> Message-ID: <470E4EE0.6@xp2.de> Hello there, have a look at https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Some topics already have been crossed out again because they were probably already talked about or better for one of the Office Hours. I added the 3 viewer feature requests as they are a) quite old already and with no decision made for them b) the ones with the most votes c) I see some great benefit in all three them. If you have any interesting / important things you want to see in there, tell me. 4 1/2 hours to the OSM. :) Tillie From makosoft at googlemail.com Thu Oct 11 11:03:13 2007 From: makosoft at googlemail.com (Aidan Thornton) Date: Thu Oct 11 11:03:15 2007 Subject: [sldev] [Question] TCP/UDP Sim connection In-Reply-To: <470CD78E.3080003@zweitgeist.com> References: <470CD78E.3080003@zweitgeist.com> Message-ID: On 10/10/07, alexander treptow wrote: > I connected successfully to the login server and got the xml with my > charakters position, simip, simport and so on. now i want to connect to > the sim i send an udp packet with > 40 00 00 00 01 00 FF FF 00 10 as first bytes in hex like its mentioned > in the wiki. > behind this data follows the sessionuuid and the agenduuid as raw data. > so the packet size is 46 byte. the port is the simulator port 12035. > > but i got no response from the server. Hi, Did you remember to put in the circuit code? I assume you did, since the message size matches, but you don't mention it. If you didn't, it's in the login server response, and I think it should go before the session ID as a little-endian 32-bit signed int - I still don't know why LL couldn't just pick one endianness and stick to it, but that's Second Life. Aidan From ettore_pasquini at 3dconnexion.com Thu Oct 11 11:59:42 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Thu Oct 11 11:59:43 2007 Subject: [sldev] [VWR] How to determine Build mode status reliably? Message-ID: What's the right method to detect that we are in Build mode? I thought LLToolMgr::inEdit() was the one, as its usage is accompanied with comments like "see if we're in build mode" in the code. However, I found out that the method returns "true" (i.e. "yes, we are in build mode") everytime I am in Mouselook mode. Is this intended? If so I fail to understand the logic behind it, and in any case inEdit() is not the right one for my problem. I have found an alternative condition to determine Build mode status, but I'm not sure how stable this is: (gToolMgr->getCurrentToolset()->getSelectedTool() == gToolCreate) It seems to work so far, but can that be used reliably? What should I use instead? Thanks, Ettore From secret.argent at gmail.com Thu Oct 11 12:06:28 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 11 12:06:37 2007 Subject: [sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007 In-Reply-To: <5eff6d3b0710110749k61e302b9qc6ecfaa36ab757a@mail.gmail.com> References: <4706AEB1.7050601@cox.net> <470B7730.9000202@zurich.ibm.com> <25F0E815-B61F-4C35-88B8-F8B56E2BC331@gmail.com> <1191986888.29582.112.camel@localhost> <26EEDC61-C6A8-4232-B992-B031B641FE67@gmail.com> <470DAF7C.3020501@zurich.ibm.com> <470DDF9C.6030107@cox.net> <470DE3D6.5070608@zurich.ibm.com> <470DEC7C.9060602@cox.net> <6CADF786-0940-4DDA-A2E2-DE19E75EE275@gmail.com> <5eff6d3b0710110749k61e302b9qc6ecfaa36ab757a@mail.gmail.com> Message-ID: <79C7506B-40C7-49AB-B1A6-32EF91433625@gmail.com> Here's part of a message that I was going to forward to the list, and I was waiting on an OK from the recipient before forwarding the whole thing. They haven't responded, so I've stripped out the first part because i think this might explain where I'm coming from a bit better... Talking about the inventory... [...] The assets stored in it includes assets belonging to this domain, and copies of assets belonging to other domains. It may not be necessary to actually copy those assets from the other domain when only references to them are being transferred when (for example) an agent moves from one domain to another. The agent server, or the asset server, contains copies of assets in user inventories. These copies may have different properties than the originals, these properties must be maintained, but there is no reason to retain a copy of the actual asset data in each copy. The region hosts, or the asset server, contain copies of assets that exist in regions. These copies may have different properties than the originals, these properties must be maintained, but there is no reason to retain a copy of the actual asset data in each copy. The region hosts in this domain may have cached instances of assets stored in this domain's asset server, and assets stored in other domains asset servers. These do not have distinct properties, but it is useful to treat them the same way as copies. Different domains may have different properties that they need to track on an asset. These properties need to be maintained by whatever asset server the asset is maintained on. These properties need to be copied in copies of the asset. These properties are subject to different policies in different domains... a domain may not allow certain properties to be changed except from certain domains. The architecture includes asset servers, region hosts, agent hosts or servers, and so on. However this is designed, all the states I listed must be able to be modeled in the design, efficiently. Transitions between these states must be possible. And that is where the architecture comes in... the architecture must be explicitly able to represent assets where the data is a reference to another asset, and to properties that are unknown to the asset server. The identifiers for properties must be unique, even for domain-specific properties. For example, a texture may look like this (using a pseudo-RFC822 style for compactness only, this isn't HTTP headers): Owner: http://example.com/agents/uuid Creator: http://example.com/agents/uuid Name: Snapshot_001 Date:... ... Body-length: 102567 jpeg-2000 image file Or it may look like this: Owner: http://example.com/agents/uuid Creator: http://example.com/agents/uuid Name: Snapshot_001 Date:... ... Location: http://example.com/something/filename.j2c Body-length: 0 That's a reference. It may be a cached instance that hasn't been fetched yet, it may be a copy. Or it may look like this: Owner: http://example.com/agents/uuid Creator: http://example.com/agents/uuid Name: Snapshot_001 Date:... ... Location: http://example.com/something/filename.j2c Unknown-001: domain=http://raytrace-vr.example.com render-priority=26 Unknown-002: domain=http://ferengi.example.com resale-royalty='35 %' Body-length: 102567 jpeg-2000 image file That's a reference with domain-specific properties and a local copy of the data. The *architecture* has to explicitly ensure that (a) assets can refer to other assets, and (b) properties that the asset server doesn't know about are handled. From cnd at knowprose.com Thu Oct 11 15:18:58 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Thu Oct 11 13:23:01 2007 Subject: [sldev] OMG, my image was de-rezed!!! In-Reply-To: References: <470C59E7.9080309@speakeasy.net> Message-ID: <470EA152.5040803@knowprose.com> Hrm. I've never seen the beta grid as a solution, or even a good workaround. It's a testing grid, and because it is a testing grid we should probably assume that the beta grid won't act like the normal grid... So testing stuff on the beta grid like that does not guarantee that it will actually work on the real grid... And having seen my share of 10 L hiccoughs, well - life blows on. I mean goes on. Well. Maybe. Matthew Dowd wrote: > You can always do testing of textures (and sounds and animations for > that matter), on the beta grid since L$ there are effectively free. > > Once you have something that works, upload it to the main grid. > > Matthew > > > Date: Wed, 10 Oct 2007 00:49:43 -0400 > > From: agrimes@speakeasy.net > > To: sldev@lists.secondlife.com > > Subject: [sldev] OMG, my image was de-rezed!!! > > > > After I wrote my last e-mail, I wandered around, when I got back my text > > test prim had been de-rezed to 128x128 from 256x256 > > > > !!!!!!! W H A T !!!!!!! > > > > My image that was posted at origonal size was de-rezed to 64x128, no > > wonder it is illegable, it has half the pixels it needs... > > > > In the background is one of my ron-paul yard posters which looks crystal > > clear... > > > > What gives? I pay L$10 to upload a 1.3kb file and your server decides it > > can't handle 1.3kb and crops it down to half the resolution??? > > > > WHAT THE ....!!!!!! > > > > Oh well, while I'm pissing away lindens, I'll make a 256x512 > version... =\ > > > > =P > > > > Looks like I tricked it into working. > > > > The big smiley face looks a bit blurry but that's what you get when you > > put an 8x16 sub-texture on a 5x10 prim face. =P > > > > Suggested new policy: L$1/killobyte and the server keeps a lossless > copy. > > > > -- > > Buy Ron Paul's Money! =) > > http://www.libertydollar.org/ld/ronpauldollar > > Soundest investment on the planet! > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > Are you the Quizmaster? Play BrainBattle with a friend now! > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Taran Rampersad Presently in: Paramaribo, Suriname cnd@knowprose.com http://www.knowprose.com http://www.your2ndplace.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From robla at lindenlab.com Thu Oct 11 13:32:19 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Oct 11 13:32:33 2007 Subject: Artwork (Re: [sldev] Packaging the viewer for Linux distributions) In-Reply-To: <1191620596.26663.34.camel@localhost> References: <46FD72A7.7040603@lindenlab.com> <1191017317.1456.7.camel@localhost> <47013253.5000301@lindenlab.com> <1191620596.26663.34.camel@localhost> Message-ID: <470E8853.30904@lindenlab.com> Hi all, Sorry for the delay in jumping into this conversation. This is on the agenda for this afternoon, but I wanted to make sure I got something on the list about this beforehand. On 10/5/07 2:43 PM, Callum Lerwick wrote: > Ah, something else on the to do list I've forgotten about. In Fedora, > we've been encouraging upstream projects to separate (arch-independent) > game data from source. This is advantageous for us, no only can we issue > updates to the binaries without everyone having to re-download a large > amount of game data, but the game data can be a "noarch" package, shared > across all architectures, reducing storage requirements on our mirrors. > > LL already separates the "artwork" from the viewer source, which is most > of the way there. What makes it much less useful to us is the fact that > a new artwork tarball comes out with every source release. Could LL > avoid releasing a new artwork tarball unless it has actually changed? I > haven't got around to diffing it and seeing how often it actually > changes, if it is changing, maybe it shouldn't. ;P > The problem is that the artwork releases are an automated process which is made much faster for us by the fact that we're blindly publishing. We could also publish some sort of file list difference, but I'm not sure we have much of an advantage in publishing that. The easiest way I can think of is to unpack the two tarballs that we publish the results of "diff -q" between the two trees to see the file changes. That's not something that is especially easier for us, which is why I'm not inclined to volunteer to do it (since there's plenty of other stuff that is much easier for Lindens than everyone else that would be just as useful). That said, I'm pretty eager to see the viewer make it into Linux distros, so if this is truly on the top of the list for things Linden Lab should do, then well, maybe we should figure something out. On 10/5/07 3:43 PM, Dale Glass wrote: > How about putting the artwork and libraries packages into SVN (or > whatever)? That'd allow to tell much more easily when it changes, and > updates would be less of a pain. > Maaaaybe. One big reason for the artwork being the way that it is that it's difficult to conspicuously mark the copyright associated with each file. This is exacerbated by the fact that the artwork isn't in its own place in our internal tree....it's intermixed with code we GPL (and code we haven't released yet). We could publish the code into a separate tree, but then, in order to build, you'd have to figure out how to overlay the artwork tree into the source tree. I'm not sure if svn:externals helps here, since I don't think its possible to pull two files in the same directory from different places. We do plan to shuffle our codebase around to remove some of this silliness, but we're not there yet. I'm not sure if this particular problem was a consideration, but I'll bring it up. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071011/82e1125d/signature.pgp From gigstaggart at gmail.com Thu Oct 11 14:50:22 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Oct 11 14:50:18 2007 Subject: [sldev] [ARCH] RFC: Viewpoint Advocacy Groups Message-ID: <470E9A9E.3000208@gmail.com> https://wiki.secondlife.com/wiki/Viewpoint_Advocacy_Groups Please review this. We've hashed this out in the in-world group, and it seems like the idea is viable. If anyone has any questions about what the role of these subgroups would be, (after reading the page), then ask. -Jason From kerdezixe at gmail.com Thu Oct 11 15:28:14 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Oct 11 15:28:16 2007 Subject: [sldev] [NOTAG] smoother and faster ?! Message-ID: <8a1bfe660710111528q4d1ded3u2a1599198c9ea8a8@mail.gmail.com> Friendly greetings ! i was away for a few days... i come back and notice that SL is a lot more faster and smoother than the past few... mmm... months. What happened ? smooth simcrossing, fast rezing, ... I'm not complaining of course, but i like to understand what's happening. What did you do ? -- kerunix Flan From labrat.hb at gmail.com Thu Oct 11 15:56:30 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Oct 11 15:56:33 2007 Subject: [sldev] [NOTAG] smoother and faster ?! In-Reply-To