Open sl-service-account opened 2 years ago
sl-service-account
commented
2 years ago Whirly Fizzle commented at 2022-02-19T16:54:46Z
It's a cool idea in theory but an absolute bloody nightmare for QA & support.
CoolVL Viewer has support for LUA plugins: http://sldev.free.fr/forum/viewtopic.php?f=6&t=1736 Firestorm discussed adding LUA support a while ago but decided against it; https://jira.firestormviewer.org/browse/FIRE-6582
sl-service-account
commented
2 years ago palisade.coronet commented at 2022-02-19T21:33:21Z, updated at 2022-02-20T07:11:04Z
I'm not suggesting LUA plugins, those would be second class citizens as an embedded language that would just have basic exposure to limited api calls. Which I suppose is one way of doing it, but not one that lets you rewrite the engine to become a lightweight broker to sophisticated extensions.
The feature suggestion listed here is entirely C++ based plugin architecture where the core viewer is stripped down to its basic necessities to login to the grid and display a scene. Then, all other features are added back in as C++ plugins in DLLs loaded at runtime. This encompasses features such as; voice, inventory, chat, audio, events, animations, landmarks, media, graphics, scripting, contacts, radar, currency, UI, camera, file system, region, url handling, etc.
This kind of architecture would also mean that in the future, LL could release a few DLLs that make corrections to only affected areas without making a full viewer release. e.g. Corrections were made this month to the graphics, scripting and chat system so only those 3 extension DLLs would need to be redownloaded and replaced by the viewer from the TPE repo.
Even the renderer could itself be considered a plugin. Which would allow for swapping in and out OpenGL, Vulcan, Direct3D, etc. at some point in the future. This allows expansion beyond what is currently possible with the viewer. In addition, it would make porting to other platforms, e.g. mobile, cleaner, with a lighter weight viewer able to add features back on as needed and also easily swap in a OpenGL ES api specific to mobile platforms for example.
An example of a C++ plugin system that is cross platform:
https://doc.qt.io/qt-6/plugins-howto.html
https://doc.qt.io/qt-6/qtwidgets-tools-plugandpaint-app-example.html
Advantages:
Using the meta-object system to do work across DLL boundaries using qobject_cast.
I know this would be a big undertaking but the advantage is a super lightweight viewer with the ability to be extended far beyond its original capabilities and the longevity to tackle all future hurdles the world throws at it.
The LUA plugins you mentioned could even become just another extension in the framework I've described here. One that is an optional TPE install by users who would like that functionality. Perhaps even maintained by the CoolVL viewer developers themselves. And, that's the magic of this system. Suddenly all viewer developers can work together on features that any viewer using this extension system can take advantage of.
Regarding Q&A and support:
sl-service-account
commented
2 years ago Vir Linden commented at 2022-02-23T19:11:49Z
Bringing this in for the "possible future improvements" bucket. Would obviously be a big project. Nice discussion of possible areas of application.
How would you like the feature to work?
The Second Life viewer can be considered to be like a 3D browser of a virtual metaverse. In many ways traditional web browsers share things in common with the SL Viewer, although they render their content and platforms a bit differently.
One thing that a browser has, however, that the Second Life viewer does not yet are Extensions aka Add-Ons.
This feature request suggests the creation of a pluggable system via an QT Plugin System that would allow extensions to the viewer listed on an approved Third Party Extensions (TPE) site hosted at LL much like the TPV list. These extensions could add interesting extra functionality to the viewer that adds features beyond what LL originally envisioned for the platform. These extensions could be made to the viewer without having to edit the viewer code or compile the viewer itself. The viewer could load these plugins via a searchable repository and be configured / enabled / disabled by users as desired.
AutoDesk Maya, Krita, Reallusion iClone, Daz Studio 3D, MeshLab, and MakeHuman all make use of Qt so it is possible to make highly performant cross platform rendering systems with clean modern user interfaces that can be both open source and in some cases proprietary as well and have a good plugin system; e.g. iClone and Maya. And, the SL viewer already makes use of this library so the jump to rewriting it to use the plugin loader should be more or less seamless. And, there's already tooling in the viewer for working with plugins, e.g. llplugininstance.cpp. The Viewer is already partially there due to integrating with QT and also providing the llplugininstance class for integrating with QuickTime and WebKit.
https://doc.qt.io/qt-6/plugins-howto.html
https://doc.qt.io/qt-6/qtwidgets-tools-echoplugin-example.html
https://doc.qt.io/qt-6/qtwidgets-tools-plugandpaint-app-example.html
Ideas like;
And, even more extensions than I or the team at LL could dream of. But, the users that are developers might.
Right now to implement any of those features a developer has to submit changes to a TPV. However, if a TPE existed they could implement the feature using a built-in standardized plugin API, used in TPV and the standard viewer, and then submit it for approval to the TPE repository. After being scanned for viruses and approved by the team that it meets community standards, it would end up on the TPE and could be installed by users to add the feature to the viewer if they desire that feature.
Functionality currently only found in for example Firestorm could be made available to the Second Life viewer if they had been implemented as extensions. For example; the updated Radar system, the built-in Animation Overrider (AO), the anti-spam features; blocking excess messages, load map URL spam, block left click sitting, quick preferences button, etc.
This would also reduce the weight of the viewer itself, because many extraneous features could be moved into extensions. The viewer itself would become lightweight and users could decide which features they desire the most. They could rate these extensions. And, the number of downloads of individual extensions could be kept track of to determine popularity. In addition they could comment on the extensions, donate to the extensions, get the github URL and contribute to the development of their favorite extensions.
Not all of the listed ideas above would have to be included. The approval of extension ideas could be gate-kept by LL via the TPE repository and restricted through the API. If some of these ideas are currently undesirable, don't let it overshadow the new feature suggestion itself. The feature will allow viewer breakthroughs that weren't previously possible or were made difficult by the current architecture. And, the viewer download size would by default become significantly smaller as extra features could be moved into extensions as needed.
Many free extensions would be provided by default especially any that are currently already enjoyed and considered the baseline experience for the platform. And, also some features could be purchased for a buck or two apiece with the majority of that revenue going to the extension developer and a smaller commission to the lab for hosting the submission. Extension developers could still provide their source code while obtaining revenue for continued development of the feature by users that appreciate the addition of these features. This would spawn an ecosystem of sophisticated enhancements coming to the viewer backed by financial incentives for any and all desired improvements by the userbase. Whereas some extensions might be free and see their revenue from other sources; e.g. the discounts for visiting stores extension.
The plugin system should be created with QT plugin loading system with a standardized way of adding plugins that have access to powerful features in a way that also balances protecting core features of the viewer. And, in a way that allows plugin developers to set a list of features they require to access in the API during compilation. This would be important when listing the feature on the TPE repo as the capabilities could be listed such as needing access to read chat, inventory, friends list, etc. Then users can decided whether they trust that extension to touch those parts of the API or not. The emoji extension would need the chat api, whereas the clothing management system would need inventory access, etc. It also helps reviewers at LL determine what an extension that is submitted to TPE is doing.
A new window inside the viewer could list the TPE repo, show what is currently installed and allow users to enable, disable, add and remove extensions as desired. This window would let the user see the extension's description, ratings, comments, github URL, license, price, and a list of its capabilities; e.g. needs access to the Inventory, needs access to the Friends list, etc. I've attached diagrams of the module loading system and mock ups of the user interface described here.
Why is this feature important to you? How would it benefit the community?
This feature suggestion would open the door to a whole new realm of innovation for the viewer. It would create a much lighter weight viewer where additional interesting features can be added on by users as needed. This feature breathes new life into the platform and provides developers with a new avenue for contributing to the success of Second Life. And, it would create a whole new economy of extensions and generate revenue. While at the same time providing innovative new features that extend the life and capabilities of the viewer in ways that users strongly desire.
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-231830 | | Summary | Viewer extension system | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Created at | 2022-02-19T10:24:04Z | | Updated at | 2022-02-23T19:11:48Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-02-19T10:54:45.651-0600', 'How would you like the feature to work?': "The Second Life viewer can be considered to be like a 3D browser of a virtual metaverse. In many ways traditional web browsers share things in common with the SL Viewer, although they render their content and platforms a bit differently.\r\n\r\nOne thing that a browser has, however, that the Second Life viewer does not yet are Extensions aka Add-Ons.\r\n\r\nThis feature request suggests the creation of a pluggable system via an Entity Framework that would allow extentions to the viewer listed on an approved Third Party Extentions (TPE) site hosted at LL much like the TPV list. These extensions could add interesting extra functionality to the viewer that adds features beyond what LL originally envisioned for the platform. These extensions could be made to the viewer without having to edit the viewer code or compile the viewer itself. The viewer could load these plugins via a searchable repository and be configured / enabled / disabled by users as desired.\r\n\r\nIdeas like;\r\n1. blockers (aka ublock/adblock) for radio streams, media streams, etc\r\n2. graphical emoji displays for the chat window when certain :triggers: are typed.\r\n3. translators for foreign natural languages\r\n4. dark reader mode for the script window\r\n5. syntax autocompletion and help lookup for script methods, maybe even AI integration\r\n6. cryptocurrency support, e.g. metamask-like functionality\r\n7. improved bookmarking and categorization system for landmarks\r\n8. improved inventory management systems\r\n9. note taking systems for visited sims (works like profile My Notes, but for landmarks).. perhaps even ones that could be shared with other users so users can make notes together with a permission\r\n10. screenshot operations for improving camera and visual taking of the best shots and filtering, etc.\r\n11. voice notes for taking audible notes\r\n12. displaying of graphs that can be used to track data, e.g. visitors and display other visual information, e.g. shots fired in a roleplay combat game\r\n13. a system for drawing on objects without using prims or particles\r\n14. cash back plugins for SL stores where store owners can provide discount incentives for visiting and making purchases\r\n15. a plugin that tells the user to take a break after too much usage\r\n16. cache cleaning plugins, auto-removing typed URLs or teleports, etc.\r\n17. pushing sms messages in response to certain events or actions\r\n18. block lists for regions for managing what can be visited\r\n19. built-in calendar scheduling system\r\n20. client-side hud games that wouldn't be possible with just SL scripts at the moment\r\n21. Text-to-speech features for accessibility\r\n22. Integration with services; like Pinterest, google docs, etc.\r\n23. Virtual weather monitors! Is your favorite region having a thunderstorm roll in? Is it snowing?\r\n24. Pinnable To Do lists / Web clippers\r\n25. Automatic inventory arrangers.\r\n26. Friends list management tools.\r\n27. Region management tools.\r\n28. Clothing management systems.\r\n29. SVG drawing support.\r\n30. SL virtual job search hunters.\r\n31. Math equation calculators and graphers.\r\n32. An addon that changes the login progress screen to display custom backgrounds; e.g. You're a fan of GoT? Have it display random GoT wallpapers each time it shows up.\r\n33. Integration with antivirus companies for checking links before they're clicked. Auto-strike-thru'ing links and disabling them in group / local chat / IMs that have malware.\r\n34. RSS feed readers.\r\n35. Pen and paper tools; e.g. AD&D\r\n36. Encyclopedia integrations.\r\n37. Controlling features via speech recognition\r\n38. Integrations for supporting charities.\r\n39. Enhanced audio channel settings.\r\n40. Script debuggers.\r\n...and so on...\r\n\r\nAnd, even more extensions than I or the team at LL could dream of. But, the users that are developers might.\r\n\r\nRight now to implement any of those features a developer has to submit changes to a TPV. However, if a TPE existed they could implement the feature using a built-in standardized plugin API (used in TPV and the standard viewer) and then submit it for approval to the TPE repository. After being scanned for viruses and approved by the team that it meets community standards, it would end up pin the TPE and could be installed by users to add the feature to the viewer if they desire that feature.\r\n\r\nFunctionality currently only found in for example Firestorm could be made available to the Second Life viewer if they had been implemented as extensions. For example; the updated Radar system, the built-in Animation Overrider (AO), the anti-spam features (blocking excess messages, load map url spam, block left click sitting, quick preferences button, etc.\r\n\r\nThis would also reduce the weight of the viewer itself, because many extraneous features could be moved into extensions. The viewer itself would become lightweight and users could decide which features they desire the most. They could rate these extensions. And, the # of downloads of individual extensions could be kept track of to determine popularity. In addition they could comment on the extensions, donate to the extensions, get the github url and contribute to the development of their favorite extensions.\r\n\r\nNot all of the listed ideas above would have to be included. The approval of extension ideas could be gate-kept by LL via the TPE repository and restricted through the API. If some of these ideas are currently undesirable, don't let it overshadow the new feature suggestion itself. The feature will allow viewer breakthroughs that weren't previously possible or were made me difficult by the current architecture. And, the viewer download size would by default become significantly smaller as extra features could be moved into extensions as needed.\r\n\r\nMany free extensions would be provided by default especially any that are currently already enjoyed and considered the baseline experience for the platform. And, also some features could be purchased for a buck or two apiece with the majority of that revenue going to the extension developer and a smaller commission to the lab for hosting the submission. Extension developers could still provide their source code while obtaining revenue for continued development of the feature by users that appreciate the addition of these features. This would spawn an ecosystem of sophisticated enhancements coming to the viewer backed by financial incentives for any and all desired improvements by the userbase. Whereas some extensions might be free and see their revenue from other sources; e.g. the discounts for visiting stores extension.\r\n\r\nThe plugin system should be created as an Entity Framework with a standardized way of adding plugins that have access to powerful features in a way that also balances protecting core features of the viewer. And, in a way that allows plugin developers to set a list of features they require to access in the API during compilation. This would be important when listing the feature on the TPE repo as the capabilities could be listed such as needing access to read chat, inventory, friends list, etc). Then users can decided whether they trust that extension to touch those parts of the API or not. It also helps reviwers at LL determine what an extension that is submitted to TPE is doing.\r\n\r\nA new window inside the viewer could list the TPE repo, show what is currently installed and allow users to enable, disable, add and remove extensions as desired. This window would let the user see the extension's description, ratings, comments, github url, license, price, and a list of its capabilities (e.g. needs access to the Inventory, needs access to the Friends list, etc).", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'This feature suggestion would open the door to a whole new realm of innovation for the viewer. It would create a much lighter weight viewer where additional interesting features can be added on by users as needed. This feature breathes new life into the platform and provides developers with a new avenue for contributing to the success of Second Life. And, it would create a whole new economy of extensions and generate revenue. While at the same time providing innovative new features that extend the life and capabilities of the viewer in ways that users strongly desire.', } ```