Agreed. LL REALLY needs to fix this. I disagree that this is "purely a technical issue" as this is by far IMHO the biggest sink they have. SL is based on content creation, and this is a tax on that. I do agree with the fact that it also helps keep down the asset server growth rate, but I don't think that was originally the point. It may have been a factor, but not the primary reason --Jesse
On 7/9/06, Adam Frisby <[EMAIL PROTECTED]> wrote:
I think it's best we defer this one onto LL for a decision. The upload fee isnt for sink purposes - it's to limit the number of assets on the asset system. The fee itself has no real relation to the economy side of SL - it's purely a technical issue. Last I heard, the asset DB was 13TB and growing at 1.5% per *day*. The upload fee is there to make sure that doesnt rise to 5% per day. Yes people can disable the limit - but if by default it's enforced, then at least it's like putting a big red warning sign over the function 'Don't abuse this!'. LL has been helpful in regards to assisting with this project - but this is one of those points where LL really doesnt want to go ahead with this. LL may verywell ban libsl from doing automated asset uploads if it's abused. I agree with Timeless that if LL isnt doing this serverside, they should strongly consider it. But until such a time, it's the clients responsibility to pay upload fees - and if we are building 'to spec', then it's out responsibility too. Whether or not it can be easily bypassed is completely irrelevant. It's there for a good reason. -Adam Jesse Nesbitt wrote: > I disagree. I think that compiling in the upload sink doesn't fit. > Something tells me that this might force a fork in the codebase (and I > do not want to see that) > As for your XChat refrence, there are MANY people that provide free > XChat builds for windows. > Just by 2.5 cents. > --Jesse > > On 7/9/06, Adam Frisby <[EMAIL PROTECTED]> wrote: > >> Weighing in here - sure it's possible to compile out the upload fees - >> but the default should be to enforce them. >> >> People are going to get around things to avoid paying - that's a fact of >> life, but as the library developers we do have some obligation to make >> sure our client behaves with SL. >> >> To bring up an example - the windows version of X-Chat has a $15 >> registration fee? Count the number of people who have been bothered to >> actually compile that out. Most just dont bother, pay the fee and be >> done with it. (or avoid using it) >> >> Until LL starts enforcing these serverside themselves, I think we have >> the obligation to make sure something we are at least partially >> responsible for doesnt kill the asset system, and at the end of the day, >> on the technical side, it should be fairly trivial to implement. >> >> -Adam >> >> Alondria LeFay wrote: >> >> > I think LL would be much more concerned with us having the programmatic >> > way of creating assets than whether we are enforcing their money sink >> > within it. Historically, they have held fast to not allowing LSL to >> > create assets due to the fear that someone could bring the asset server >> > to its knees. My fear is somewhat that when we do implement this, >> > someone will end up taking out the asset server. Likewise, if someone >> > makes a "free upload program" it could throw our economy on SL more out >> > of wack. >> > >> > >> > >> > I think the end result is we really need to think this one through and >> > perhaps we should talk to LL about the situation and what can be >> done to >> > ensure libsl sill not cause more harm than good. >> > >> > >> > >> > Thus, I somewhat disagree – I think we do have some responsibility to >> > ensure what we do is for the common good and seriously think about the >> > possible fallout of what we do. I also believe if we cause too much >> > negative effects to SL and LL, LL will change their opinion and start >> > inhibiting libSL's development. >> > >> > >> > >> > But – I haven't had my morning coffee yet…. >> > >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > *From:* [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED] *On Behalf Of *Tom Wilson >> > *Sent:* Sunday, July 09, 2006 8:49 AM >> > *To:* Development list for libsecondlife >> > *Subject:* Re: [libsecondlife-dev] Inventory Upload & Fees >> > >> > >> > >> > I'm sorry, but it just doesn't make sense to enforce upload payments in >> > libSL. >> > >> > lilbSecondLife is open source, and unless you close the source (and >> > obfsucate it and use a language that's NOT C#), everybody who wants to >> > cheat and upload for free would simply modify the upload routine and >> rip >> > out the payment code anyway. If you closed certain modules to prevent >> > that, you're going against the very idea of open source. It is not our >> > job to make policy, and we are also not in the business of enforcing >> > LL's policies. >> > >> > Also, just from a pure technical perspective, payments and uploads >> > really have nothing to do with each other. It would be bad design to >> > build payments in to the texture upload function. However, if payments >> > and uploads happen together frequently (as they would with texture >> > uploads), then it would be smart to either introduce a second, >> > overloaded function or a new function that allows the user to specify >> > the payment amount as a parameter. The function would return an error >> > condition if there wasn't enough money in the person's account. >> > >> > IMO, paying for uploads should have been a server-side function all >> > along, and I don't doubt that LL *will* implement that server side as >> > soon as they figure out that people are adding assets to the server >> > without paying to do it. (To do otherwise is simply bad design from a >> > security standpoint.) I assume that you're already talking to a Linden >> > once in a while: I'd suggest e-mailing that contact and commenting on >> > this. I have a feeling that we'd see a change in the .12 release. >> > >> > I have no doubt that as people start leveraging libSL in their programs >> > that LL will have their hands full trying to keep up with the things >> > people have figured out how to do. Free uploads are just the tip of the >> > iceberg. Now that LL's official position is "we encourage beneficial >> > reverse-engineering", Let LL worry about the bugs and security holes in >> > their protocol and fix it. It's not our job. :-) >> > >> > On 7/9/06, *Adam Frisby* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >> wrote: >> > >> > Since inventory upload (aka automated asset creation) has been made >> > possible via the CRC discovery, I think it might be the time to raise >> > some important questions. >> > >> > 1. Upload fees are handled clientside, while I dont think this is the >> > best approach for LL to take - it is something we need to deal with. Do >> > we implement this? (Personally, I think there's a responsibility to >> > implement them.) >> > >> > 2. Automated uploads is now possible for more than just textures - >> > eventually someone's going to think it might be a great idea to share >> > files by uploading them as base64 encoded notecards - again I >> suggest we >> > implement a charge, L$2-10/asset fair? >> > >> > 3. Given the above, has anyone started implementing the code for >> > handling asset creation? >> > >> > -Adam >> > >> > _______________________________________________ >> > libsecondlife-dev mailing list >> > libsecondlife-dev@gna.org <mailto:libsecondlife-dev@gna.org> >> > https://mail.gna.org/listinfo/libsecondlife-dev >> > >> > >> > >> > >> > -- >> > Tom Wilson >> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> > KI6ABZ >> > >> > -- >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: >> 7/7/2006 >> > >> > >> > -- >> > No virus found in this outgoing message. >> > Checked by AVG Free Edition. >> > Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: >> 7/7/2006 >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > libsecondlife-dev mailing list >> > libsecondlife-dev@gna.org >> > https://mail.gna.org/listinfo/libsecondlife-dev >> >> >> _______________________________________________ >> libsecondlife-dev mailing list >> libsecondlife-dev@gna.org >> https://mail.gna.org/listinfo/libsecondlife-dev >> > > _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
-- --Jesse _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
