|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 08/Jun/07 11:55 AM
I dunno... I think these all belong in SVC, categorized under Scripting. I don't think that Scripting is a wide enough category to warrant its own top-level tag. Also, I'm not even sure what VWR/Scripting is intended to encompass, because we can't script the viewer.
There's only a few issues that validly involve the viewer and scripting and they have to do with things like display of text, and other stuff the client does. However, a huge portion of the SVC+MISC stuff would be scripting related if all the various scripting related issues were combined. Maybe it would be better to keep them under the SVC hierarchy, but at least half of them don't appear there for one reason or another. The hierarchy is (or should be) for OUR (the bug-reporters') convenience, not to satisfy a Dewy-Decimal-logic about what is the most logical place (from a librarian's perspective) to keep specific issues.
Right now, well over 100 issues (maybe over 200) are scattered in three different categories. Something is not working right. The easiest solution, from my perspective as a scripter, is to make scripting issues a separate report-category with sub-categories for various aspects of scripting, rather than assuming that everyone will automatically realize that "Service" applies to scripts. The SCRIPT=>llLink* sub-category alone would have perhaps 25 entries, for instance, many of them duplicates. BTW, a quick check of the SVC category shows that the scripting sub-category is not only the largest sub-category, but probably has more items than all the rest of the sub-categories combined. This means that we should remove the SVC category completely and make everything in it a sub-category of scripting...
I'm joking, but I'm trying to point out the issue with having one category that is larger than everything else under the parent. It is a sign of a flawed design, as far as categorization goes. Lindens: factor scripting out of SVC and VWR. This will facilitate bug/feature-tracking and make it easier to find duplicates and vote on important scripting-related issues. I strongly agree with Saijanai Kuhn's request. There are a very large number of LSL bugs and shortcomings. Searching the present Jira setup is hideous. Please add a LSL top level section and move the 100+ existing bugs there so we can find em, then support and add all the missing ones.
Suggest that we not call it "LSL" in light of Mono... 99.9% of the scripting bugs and feature requests are VM functionality, not language-specific anyway.
"Scripting", sure. A more general name is fine.
But don't plan on Mono any time soon. Eh, mono will happen shortly after the HetGrid is up and running, I suspect. HetGrid is the key to upgrading a LOT of SL.
Yes, definitely agreed. I always get a twinge of sadness when issues get closed for not being in the right scripting category. Poor feature requests; dead before they even had a chance.
The non-scriptor equivalent
I retitled the summary to make it less vague. Please amend as necessary.
LSL scripts and Viewer are totally independent of each other.
The Viewer is merely a passive display rendering (reconstructing) the data on your computer sent by Linden Lab's simulation database engine. Viewer does not alter the simulation environment, it merely "passively" display the information, even though it can change the display settings, it does not alter the simulator, except for the agent (avatar) and attachments (which are controlled by LSL scripts). On the contrary, LSL scripts, by its nature, do alter the simulation environment. It "actively" interacts with the simulation engine. So they are totally different beasts! Service, on the other hand, includes everything under the sun, if you may: Viewer is servicing the users, Web is servicing the users, Bug Reports are servicing the users, New Features are servicing the user, and LSL scripts are servicing the user. May I ask, what is not under the service category? @ Nicoladie: The viewer is also where LSL is compiled and then sent to the Servers as bytecode so there are plenty of compiling issues that would fall under the viewer category. Also, the viewer has to be modified to allow new LSL functions to be compiled so updates for feature requests would have a viewer component as well.
In the source code there is an subdirectory for scripting in the viewer (lscript) so I'm not sure how you can say that LSL scripts are totally independent of each other. When the scripts are executed on the server is only one point in the codes lifetime. Having to know the nuts and bolts of scripting implementation in Second Life (sim server? viewer?) makes no sense, in terms of being able to make a succinct and sensible bug report, or, for that matter, a feature suggestion. The people that need to decipher the problem and fix it, or decide whether and how to implement a new idea, can easily determine where to target their efforts. The end users should not be expected to do so - it just discourages wide participation in the jira and lends confusion to the jira data . Voted!
This is not something we see implementing in the near future.
I am in favor of this too (I would have voted for it, but voting is closed)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Critical
Add "Scripting" as a top-level project (like VWR, SVC, etc.)
