Category talk:LSL Library

Rules for posting

Question was brought up: "Who enforces/decides the rules?

Anyone in the community may decide an article should be stripped but if a dispute arises it needs to be settled by the community at large or by a Linden who is arbitrating the debate (which would require the Linden to have been briefed by both sides). -- Strife Onizuka 06:29, 3 May 2007 (PDT)

I've removed some excessive (and slightly random) formatting bloat from the page. While I can appreciate the efforts made, not all contributors to these pages are active wiki editors, and it's VERY bad form to modify credited submissions, or their credits; Please, leave that to the individual users when credited. I also repaired a few links, and removed the links to named lindens (since company policy has removed their respective pages). if someone wants too try and confirm if the rest of the redlinks are either typos that need correction, or simply links to unsupported pages that need to be removed, that'd be great.
-- Void ^{(talk|contribs)} 15:06, 9 November 2012 (PST)

Discussions from Pre-Category era of this Talkpage

Category or normal page?

Shouldn't this be a category instead of a normal page?

The Wiki will automatically update the directory if it's a category.

Same with Examples. Gigs Taggart 15:23, 27 January 2007 (PST)

^^; didn't think of that before, lets use a catagory instead of a normal page then.Strife Onizuka 20:31, 27 January 2007 (PST)

Apparently Signpost didn't get the memo, and has moved everything into a subpage and turned this back into a normal page, that must be manually maintained. What he doesn't want to admit is moving everything into subpages breaks the category feature completely. Gigs Taggart 18:34, 19 February 2007 (PST)

If it was going to be a category-based setup, then why on earth was the author/description table still there if the prime claim of category-fu was

The Wiki will automatically update the directory if it's a category.

Same with Examples. Gigs Taggart 15:23, 27 January 2007 (PST)

It seemed to me, that in practice nobody really cared about the automatic updates.

SignpostMarv Martin

The table was still there because I left it there until ALL of the items that were listed on it had been created and tagged with the category, nor did I have the time right then to write up a new header since, at the moment the Library page was of much lower concern then the functions. But yet again you take it upon yourself to restructure things however you please, without discussion. And as another aside... We went to all the trouble of Removeing the "LSL_Library_" from all those pages because the complaint was that the "Psuedo-Namespace" would make it hard for linking, violated the whole "Simple Links" rule of the wiki etc. And what do you do? You put it back as "LSL_Library/". Thraxis Epsilon 00:22, 20 February 2007 (PST)

All the items listed in the table had been created and tagged with the category. Since the article was not in a sandbox, it was inappropriate to link to articles that did not exist.
LSL_Library is not a pseudo-namespace.

1. Residents are automatically alerted when an article is edited. (RSS/ATOM)
2. Residents are not automatically alerted when an article is added to a category. (unless I missed something)
The LSL Library is intended to be a repository of LSL2 code that can be used freely by all.
By not using the automatic updates feature of the categorisation system, other Residents are more likely to look over new additions to the library, check it for errors and malicious behaviour.
1. The table provides more useful information than the category ever will.
2. Since the description of a script cannot and should not be embedded into page titles, the table is more suited to new comers to LSL who wouldn't be able to guess what a script does based on the name.
3. Nobody seems to have paid attention to this in the "memo" which I, as you point out, wasn't aware of.

SignpostMarv Martin 06:57, 20 February 2007 (PST)

Since when is it "inappropriate to link to articles that did not exist"? "the table is more suited to new comers"... the table isn't mutually exclusive with using the category the way it was meant to be used. The only thing that is incompatible with the category is your fucked up idea of moving them all into subpages. Gigs Taggart 09:36, 20 February 2007 (PST)

It confuses Residents.
It encourages people to commit copyvio- library scripts that are not yet up should be placed on a to-do list in the talk page, not in the article.
Duplicating data is bad.
1. the subpages are not incompatible with categorisation.
2. Having the table on the same page as the category listing would make a big mess as the Library expanded
  - See above point of "duplicating data is bad"
  - You'd be forcing people to load a page that was heavier than it needed to be.
3. I'm not seeing any arguments that "the table sucks, get rid of it".

SignpostMarv Martin 10:11, 20 February 2007 (PST)

Just because you put something in a numbered list doesn't make it true. The table does suck, it's manually maintained and sure to get out of date, and like you said, is basically a duplication of the category listing. That is beside the point of moving the articles into subpages though. Gigs Taggart 17:52, 20 February 2007 (PST)

I put things in numbered lists so I don't ramble. Would you rather read through a numbered list or figure out what the hell I'm talking about ? :-P

Actually, it's integral to the sub-pages concept

Manual editing, as said before encourages peer review of code.
The table is a more descriptive index of the library than the category is, since you can't "encode" descriptive "data" into the article name without it being more "butt ugly" than it currently is.

In a cost/benefit analysis, providing the most helpful information manually far outweighs providing the least information automatically. Unless you're willing to write, design, and advocate all templates, data formats and Wiki-bot code necessary to have the helpful information built semi-automatically based on new additions to the category.

By not using the descriptive table, you're forcing the Residents to click through every single script in the library to see what each one does, but by using it, you help speed up browsing considerably, as they can skim over the table looking for what they want in the description column- offsetting some of the queries in SoSL for "does anyone have a script which does this".

SignpostMarv Martin 21:17, 20 February 2007 (PST)

Regardless of your personal opinion on how the wiki should be structured, the move to use a Category was proposed, it was seconded and carried out without any dissent. Your change however was never officially proposed, nor was it seconded, nor has it gained any approval other then your own rhetoric about how much better it is. Thraxis Epsilon 23:45, 20 February 2007 (PST)

I haven't read everything here and I don't agreed with everything I've read, but I'm like minded with Thraxis. My thoughts are these: Having both a table and category listing allows for ease of adding pages to the category, provides a link at the bottom of all pages back to the script library, and nice and the table can be updated as people feel the need. All the categories should be designed as such IMO. Having the category tells you what should be in the table. As to the prefix/namespace, I'm neither here nor there though a proposal would have been nice. If i didn't know better i'd say we were having an edit war. Strife Onizuka 00:27, 21 February 2007 (PST)

Meh. I screwed up :-D

Suggestion: Do both, but keep the table on a separate article, linking to it in the category description.

SignpostMarv Martin 02:27, 21 February 2007 (PST)

Nesting Breaker

Numbered lists make things look credible!

It's not an edit war, no one is reverting it back and forth. We are discussing it.
I think the table has drawbacks, like I said above, but I'm fine with the idea of table in the category page, like it was.
I deleted a similar table from the function category page, because that had all the same drawbacks and none of the benefits.
We should move the pages back out of subpages, because it breaks category sorting unless you use hacky stuff
I still don't see any real benefit to subpages.

Gigs Taggart 07:47, 21 February 2007 (PST)

re point 4. That's perfectly fine unless you want to:

sort articles by what they do, not how they're titled. Basic Encryption Modules should be sorted under E for Encryption, not B for Basic.
prevent people from gaming MediaWiki by naming creating an alt called Aardvark and titling all their scripts "Aardvark's script what I done learnt in class today". Or something along those lines :-P

SignpostMarv Martin 08:02, 21 February 2007 (PST)

These are non-issues to me. Gigs Taggart 10:32, 21 February 2007 (PST)

No matter what system you design, it can be gamed. Best to make a system that can be gamed in a reasonable manner. A little hacking with sort orders is ok, but should be kept as simple as possible IMHO.Strife Onizuka 11:23, 21 February 2007 (PST)

So.... you'd rather let an automated system waste peeps time by making them look through the entire list for something, rather than reviewing each script on a case-by-case basis and editing the sort order accordingly....

"Best to make a system that can be gamed in a reasonable manner" o_O

SignpostMarv Martin 18:09, 21 February 2007 (PST)

Issue with alphabetic ordering (to-do)

I just realised that the alphabetic ordering is broken.

Well... it has been broken for a long time, sure. I thought it was just a question of fixing some whitespace or something simple. It isn't.

The problem is that the first column (for the page links) can take (at least) two forms...

1. A regular wiki page (where alphabetic ordering will work); 2. A user page, under the user's namespace (breaks alphabetic ordering).

Now, user pages have been (and I supposed that they continue to be) encouraged, in general. For scripts, they have the additional advantage that the namespace itself provides the credits.

However, because such links start differently from "regular" wiki pages, those who have opted to publish under their user namespace will be listed first — and unordered, too.

I have no idea if that is the kind of thing that is "fixable" using the current version of MediaWiki and the very limited set of extensions installed by LL.

One possibility would be to create a special template for all entries, which would somehow do some wiki-fu on the link names in order to allow them to be alphabetically ordered in a correct way. I'm afraid that I'm not quite sure how to accomplish that in "pure" wiki syntax...

Until then, all we can have is a broken ordering.

— Gwyneth Llewelyn (talk) 16:52, 5 December 2023 (PST)

How to decide if a script should be placed under the LSL Library category or the LSL Examples?

Putting the question in context:

On LSL Examples should be "small, possibly incomplete", while the LSL Library os for "full projects", often requiring a more complex setup and possibly having more than one script.

That's fine, of course, but "how small is small"? There are some very small scripts here on the LSL Library which are really small (but no less valuable in spite of their compact size!) But at some point, some human will need to (manually) validate if a "script" submission to either classification makes sense.

Actually, there is also a further classification — ultra-short scripts that only show how a single LSL function is used in practice. These are usually placed directly into the function's page. However, over the years, we have accumulated a few of those which grew in size to become more than worthy of featuring on their own page — at least on the LSL Examples category. At least, that would have been my choice!

Therefore, it would be great to list some of the more obvious criteria (at least the objective ones), so long as the community can agree to a few of them!

A few examples:

Less than 5 lines (not including default ... state_entry() lines, which are required keywords): can be featured on the LSL function's page. Anything larger than that should go into LSL Examples, into its own page.
More than one script: even if they're small, multiple scripts to demonstrate some functionality should always be placed under LSL Examples (even if linked from the LSL function page!). The theory is that a LSL function page is supposed to give a very short example of how to use the function in practice; anything with more than one script would "require some assembly" and is therefore "something more" than a mere demonstration on the correct usage of a function.
The same logic would apply to scripts requiring external notecards for configuration, unless, again, the point is just to show the idiom/pattern for reading notecards
Scripts with over 200 lines: clearly belonging to the LSL Library
Pages including other programming languages, demonstrating functionality to integrate with external web services: clearly to be moved into the LSL Library if the example is a bit more than a simple echo or "hello, world!" type of example; otherwise, it should be just another LSL Example (possibly non-working or incomplete and marked as such)
A fully working vendor system in a single script with less than 30 lines of code, with trivially simple instructions, and integrating with configuration notecards as well as a remote web server to store statistics and handle item redelivery. Well... this would be a prime candidate for the LSL Library and possibly worthy of an award of some sort :) (because the 3,000-line variant of the same concept would naturally fit into the LSL Library)

Even with these minimalistic guidelines, a lot of scripts would be shuffled around for consistency's sake. Many more would be picked based on subjective criteria. A functional, two-script HUD system with 50 lines of code each might be placed either on the Library or on the Examples... its classification wouldn't be 100% obvious.

Another thing that I've noticed — many users spontaneously contribute their own scripts (usually under their own user namespace) but don't add them to any category. Instead, they're sort of "abandoned links", which you might only find by chance, while trying to look for some specific keywords. When such examples are around a page long (on my screen!), I also tag them as being part of the LSL Examples category. One problem is that the actual page owner might not want to move it there. And that, in turn, leads to another problem... what if the page owner is not in SL anymore, does not respond to IMs and similar SL-specific notifications? According to the terms if submission content to the SL Wiki, we're fully allowed to shuffle pages around at will, without giving prior notice; and changes can easily be reversed anyway.

Last but not least — some Linden admins, having received a DMCA notice to remove some content (scripts published here without explicit written permission from the original owner(s)). Currently, the page got deleted with the DMCA given as an explanation. However, the link on the script table remains (as a red link), I don't think that makes sense; if a link is gone from the "SLsphere" (meaning any website outside of the SL Grid/Viewer environment), then it ought to be removed from the SL Wiki as well — or, at least, bear the information about why it was removed. What do you think?

Just a few random, scattered thoughts...

– Gwyneth Llewelyn (talk) 01:51, 6 December 2023 (PST)