On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino <tateru.n...@gmail.com> wrote:
> Huh. Curious. I have a client launcher (for SL among other things) called 'vwrap'. I expect that before long, the prefix 'vw' will become as fashionable as 'e' and now 'i'. ;-) Morgaine. =========================================== On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino <tateru.n...@gmail.com> wrote: > 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> 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> >> _______________________________________________ >> 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 Ninohttp://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 >
_______________________________________________ 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
