Huh. Curious. I have a client launcher (for SL among other things) called 'vwrap'.
On 19/03/2010 4:23 AM, Morgaine wrote: > Carlo, you're missing something very important in your write-up. > > The issue that you haven't covered is that Snowglobe is intended for > interoperation with other worlds as well, not just with SL. Our work > in VWRAP > <http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html> has > the goal of allowing a single client to work with any virtual world > that can speak the protocol, and this applies very directly to > Snowglobe. Pixel has added new OGP functionality in this direction > already as you know, and it is reasonable to expect that this code > will be evolving further until Snowglobe speaks full VWRAP. > > What this means is that Snowglobe is not merely an SL viewer, but will > allow any VWRAP compatible world to be visited --- Lindens themselves > agree on this direction. You might like to read the article that > three of us wrote recently for IEEE Internet Computing about the > expected future of VWRAP, for which a Linden was co-author. The > article is available at: VWRAP for Virtual Worlds Interoperability > <http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf>. > > Needless to say, if virtual world travellers are to use Snowglobe in > multiple VWs, then the viewer is going to have to do more than just > handle the SL subset of functionality. In other words, features for > working with other worlds will also be appropriate in Snowglobe. I > confirmed that features for interoperability would be acceptable in > Snowglobe /in principle/, back when Rob Linden was handling the > Hippotropolis meetings. I assume that this is still the case, since > Linden support of VWRAP remains as strong as ever. > > This doesn't mean that everything will go in of course, but it does > mean that there will be features proposed which Linden Lab may not > wish to merge back into their own SL viewer --- that would be > perfectly normal. Snowglobe developers who travel in virtual worlds > will undoubtedly want to have a strong say in this, and even Lindens > are quite likely to want to cherry-pick among such additional features > for possible inclusion in the vendor branch. After all, it's > reasonable to assume that LL doesn't want its main client to be left > behind once we have interoperability. > > So the situation is rather more flexible than you suggest. Snowglobe > isn't only about working with SL, at least not until LL issues a > restrictive policy which would make Snowglobe unpalatable for general > VWRAP use. I see no sign of that. > > Just to be sure that we're all on the same page, perhaps Merov would > like to reaffirm Rob's statement regarding features that support > interoperability in Snowglobe? Since we don't actually have any > particular features in mind at this time, it's more a general > statement of principle and intent that matters at this stage. > > > Morgaine. > > > > > > > > ============================== > > On Thu, Mar 18, 2010 at 12:02 PM, Carlo Wood <ca...@alinoe.com > <mailto:ca...@alinoe.com>> wrote: > > Here is some food for thought: > > -- Question: Who determines what is added to the viewer and what not? > > I propose (to be decided by Lindens, not others) the following: > > There are two different categories of things that can be added > to the viewer: > > Category 1: Bug fixes; intended behavior is not as expected. > Category 2: Features; intended behavior is changed (added). > > Category 1 > ---------- > > These are handled the same as category 2, but without the need > to decide at the user-experience level if the patch is wanted. > Thus, for *accepted* feature AND bug fix: > > A committer writes the patch. > The patch is reviewed by other committers. > No committer can stop a patch entirely, but they can request > patches to be taken back to the drawing board based on: > > * CPU usage (FPS drop) > * Memory usage > * Coding style > * Maintainability (how easy it is to make changes without > breaking it) > * Robustness (chance it breaks accidently by changes elsewhere) > > Committer are expected to work together and respect eachother, > but especially the original committer needs to be prepared to > spend another week or two to address each and every comment > made by other committers (for which the jira is used). > > When all other committers involved, with a minimum of one other > committer, are satisfied; the patch may be committed. > > Category 2 > ---------- > > In the case of a new feature, the new feature should really > first be discussed on this list, before being implemented. > > What is being discussed are the effects on the users, not > the technical effects like CPU usage etc. Non-committers > can (politely) provide insight and feedback, but do not > have any vote on whether or not a new feature will be added. > > In fact, nobody has a vote: in the end it's the call of > Linden Lab, where we assume that if any Linden speaks his/her > decision on the list that that is the internal decision of > Linden Lab (and another Linden will not suddenly oppose). > > Each feature must be carried by a committer. That is, someone > must step forward and offer to write it, test it and be > prepared to through the hassle of Catergory 1 above. In most > cases this will be a committer whose own idea the feauture > is, that is the advantage of putting time into actually > writing (good) patches. It is not a bad thing that committers > have this priveledge. Of course, it is also possible that > a committer decides to backup an idea of someone else. > [There is no reason he cannot be paid for that, but I expect > that in general this will not be the case]. > > Linden Lab will take the following into account when making > their decision about a new feature: > > * This is about Snowglobe ONLY; whether or not it's also > added to the official viewer is a separate issue. > * They will NOT take maintainability into account, that > is the responsibility of the open source community. > * If the new feature has no last impact on the user > base, which can always be achieved by making it optional > and/or not the default, they will let themselves strongly > be influenced by the consensus of the list discussion. > * The opinion of committers is taking more into account > than the opinion of non-committers, because it's the > committers who have to maintain the code. > * The decision is made in a timely manner (ie, within > two weeks after the discussion on this list dies out). > If no decision is communicated within a reasonable > time, they right to a final decision forfeits and the > feature may be added (all with gentlemen agreement of > course). > > For example, the Life Cycle of a new feature might be > the following: > > * User thinks of new feature and adds it to the jira. > * Several people find it and vote for it. > * Feature comes to the attention of someone on this > list and brings it under the attention of a committer. > * Committer commits himself (haha) and post to the list > with implementation detail ideas. > * Everyone has their say in a civil and polite way. > * The design (on "paper") goes through a few cycles > until the committer that committed himself doesn't > want to make more changes. > * Linden Lab gives the red or green light. > * In case of a green light, the committer writes a > patch and tests it. Then attaches it to the jira. > * At least one other committer tests it and makes > comments about implementation details. > * Original committer rewrites the patch and/or > fixes bugs, until all other committers that want > to spend time on reviewing are satidfied. > * The patch is committed. > > -- > Carlo Wood <ca...@alinoe.com <mailto:ca...@alinoe.com>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
