On Tue, 18 Dec 2012 05:53:02 +0100, Latif Khalifa wrote:
> On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence)
>
> People who don't fancy themselves to be the infallible gods of system
> design often find it beneficial to hear the feedback, especially in
> opensource projects. It might even lead to (gasp) more reliable system
> and better customer satisfaction.
In fact, it was not just feedback: there has been a "feedforward"
from me, months ago (see the quoted emails below, exchanged with Oz
back in July).
> Whenever I relapse into using my time to help improve Linden Lab's
> products by doing testing, filing bug reports and repro cases, Oz
> Linden's attitude quickly convinces me that it's not worth it.
>
> (This email started as my feedback about some timing issue with
> network messages that could potentially cause bake fails, but then I
> saw all-knowing Oz dismiss any need for it)
I'd rather not judge "Oz, the man" because it is hard to tell whether
his actions are the only result of his own decisions and doings, or
are the materialization of LL's policy towards OpenSource and, if we
can judge from the resulting actions their policy would clearly be:
"take benefit of all the advantages OpenSource can bring to us (i.e.
free coding and debugging horsepower provided by volunteering
developers), and dismiss all the duties OpenSource cooperation
involves in return (such as providing clean diffs for changed we
made behind closed doors(*) before releasing them, but also providing
an *open* list of known bugs to developers)".
As far as I am concerned, while I am very sorry for the poor
implementation choice (and while I saw it coming and tried my best
to offer a smarter and yet easy alternative), I can live with it (in
35+ years of programming I've seen so many poor implementation
choices that I long lost the count and learned to make with them).
No, what bothers me most (and what I *can* and *do* judge) is that LL
(or Oz, or both), do(es)n't seem to (want to) understand what
OpenSource entails (as benefits, rights, but also *duties* !)...
Henri.
(*) This is one of the worst problems with LL's viewer development:
they modify stuff for months behind closed doors instead of doing
it in the open... That's *NOT* the OpenSource way of doing
things !!!
And here is the "feedforward" stuff:
---------------------------------------------------------------
Date: Tue, 17 Jul 2012 00:12:26 +0200
From: Henri Beauchamp <sl...@free.fr>
To: "Oz Linden (Scott Lawrence)" <o...@lindenlab.com>
Subject: Upcoming changes to the baking system and "current outfit" folder
Greetings,
Although I'm not invited to the TPV meetings (not that it would change
many things anyway, since those are performed on voice and I won't
understand half of what is said as a result), I was made aware that
you (LL) are planing to *impose* the use of the "current outfit" folder
to implement the future baking system...
I personally got many grudges against this "current outfit" folder
and the way the v2/3 viewers auto-create and auto-delete assets (be
them links for the COF or, for example, auto-re-creating calling
cards to mirror the friends list on login):
- It is totally useless from the user's point of view (especially
with viewers that provide a proper "Worn Items" tab, with full
folder/items list of worn items, like Snowglobe did) and it
therefore clobbers the inventory for nothing.
- It is incompatible with OpenSim grids which don't support
inventory links.
- It can cause inventory losses in case of asset server and/or sim
server issues; typical case: either the asset server got issues or
you just logged in/entered in a new RC channel sim, and you change
your outfit: the viewer messes up with the COF, deleting and creating
assets in it and bang ! your inventory gets corrupted (this is in
no way an hypothetical issue: it happened to me once while testing
viewer 3 on a RC channel on the main grid, to see if inventory
updates were also failing with LL's viewer on this particular RC
(which was indeed the case), and I lost my whole #RLV folder, a
folder that the "support" team was unable (unwilling ?) to recover
(they apparently have no backup or refuse to use them !!!).
When things go wrong with asset and/or sim servers, users are told
not to mess up with their inventory, but with viewer 2/3, the simple
fact of changing an outfit *does* cause automatic items creations/
deletions (and most users will be unaware of that)... This is BAD !
Because of the above issues, the Cool VL Viewer doesn't make use of
the current outfit folder (you may even delete that folder altogether
to keep your inventory lean and clean). Instead, it uses an XML/LLSD
file in the per-account settings directory (meaning there is one such
file for each avatar on each grid; they're even two for SL avatars: one
for the production grid and one for the beta grid).
The XML/LLSD is basically a list of inventory items UUIDs (one map for
attachments, one map for wearables, the latter listed in the proper
order so they are layered in the correct sequence on re-wear).
It works wonders while not having any of the COF inconvenients.
I would *really* prefer not to have to implement the COF stuff and I
wish to keep my method which I find way more elegant and indisputably
more reliable.
My guess is that the only use of the current outfit folder in the
future baking system will be to provide a list of inventory items
UUIDs (and in fact the UUIDs of the wearables only) together with their
layer info (in the links descriptions: what a dirty hack this, too !...)
so that the server knows what and how to bake them.
In this case, LL could provide an alternative method for viewers not
implementing the COF: a message could be sent by the viewer (via a
capability) that would hold all the said UUIDs in the proper order
(i.e. taking the layers into account). Basically, instead of sending
a "go for it, COF is populated, bake from it !" message to the server,
the viewer would send a "go for it, here is the list of the inventory
items UUIDs to bake !".
This would be dead easy to implement as a wrapper to what you (LL) are
probably already implementing...
Thank you in advance for considering this proposal.
Regards,
Henri.
--------------------------------------------------------------
Date: Wed, 18 Jul 2012 02:20:21 +0200
From: Henri Beauchamp <sl...@free.fr>
To: "Oz Linden (Scott Lawrence)" <o...@lindenlab.com>
Subject: Re: Upcoming changes to the baking system and "current outfit" folder
On Tue, 17 Jul 2012 12:18:12 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2012-07-16 18:12 , Henri Beauchamp wrote:
>
> > Greetings,
> >
> > .../... I was made aware that
> > you (LL) are planing to *impose* the use of the "current outfit" folder
> > to implement the future baking system...
>
> I was planning to contact you about this one, actually, but as expected
> you beat me to it.
>
> These changes are coming, but are not imminent, so there will be plenty
> of time to make any adjustments that you need to make...
I'm not worried about the time/delay: I can implement a minimum COF
support in just a few hours (testing and debugging included), and since
I provide weekly Cool VL Viewer releases, it is unlikely the viewer
would get outdated/incompatible...
It's just that I *really* don't want to implement a COF (I find this
design flawed, glitchy and useless, for the reasons I already
developed), especially since it would be very easy for LL to implement
a baking request message that would make the COF presence totally
optional (see at the end of this email to, for more ideas about it)...
> > I personally got many grudges against this "current outfit" folder
> > .../...
> >
> > - It is totally useless from the user's point of view (especially
> > with viewers that provide a proper "Worn Items" tab, with full
> > folder/items list of worn items, like Snowglobe did) and it
> > therefore clobbers the inventory for nothing.
>
> Whether or not you present the COF as a visible part of the Inventory
> display is entirely up to you; if you prefer to hide it, or present it
> in some form you think is better separately that's perfectly ok.
Oh, rest assured there would at least be one option to hide the COF
should I be forced to implement it, but it no less creates useless
items in the inventory...
> > - It is incompatible with OpenSim grids which don't support
> > inventory links.
>
> Compatibility with OpenSim isn't a design criteria for us
That's a very sad trend that has been going on since v2 is out... I
think you (LL) are (once more) committing a big mistake... I guess
it will be for me one more occasion to say "I told you..." in a few
months or years...
Fact is that soon, we (TPV developers) will have little choice but
to either drop support for a grid type (either SL or OpenSim), or
have to maintain two different viewers, which not every developer
will have enough time to dedicate for: I personally will not be
able to afford releasing up to 8 viewers each week (SL + OpenSim,
Linux + Windows, "stable" + "experimental" releases for each).
It's already quite an achievement to release up to 4 viewers each
week given the little free time I can spend on them (I'm a fast
coder, but there are limits to what I can do).
What people will do when their preferred viewer stops working in SL
is THE question... AFAIK, even now, Phoenix (which has been reusing
the backports and code I wrote for the Cool VL Viewer, i.e. inventory
links, multiple attachments, alpha and tattoo layers, mesh...) is
still the #1 viewer in SL... If you add the Cool VL Viewer,
Singularity and their forks, it makes a very large user base (and
moreover, a user base made of advanced users who are also the largest
contributors and creators in SL).
LL should really *think* about it and avoid compatibility breakage
as much as possible (and I will admit that so far, things have not
been bad on this aspect: "legacy" services are still working in SL
for now, and that's a *very* Good Thing: I would *hate* to loose the
legacy profiles or searches, for example).
> (and there's nothing about this that they could not support if they
> chose to).
Sure... But like all OpenSource developers, they do this for free and
on their free time (which is not unlimited).
If LL clearly shows off a will to break compatibility with OpenSim,
the developers of the latter could well decide to just take the next,
logical step and right out declare OpenSim will require separate
viewers.
There has been some synergy between SL and OpenSim (though, since
the closure of the Snowglobe v1 project, this synergy seems to be
history), and I think it was a good thing for all (SL, OpenSim and
their users).
> > - It can cause inventory losses .../...
>
> There is nothing about the use of Inventory for this or any other
> purpose that is intrinsically unreliable. Granted, at various times
> there have been bugs (it is software after all), some of which have had
> unfortunate consequences. At present, we think it's sufficiently
> reliable when used correctly to support this, and if that turns out not
> to be the case then we'll fix it or change our plans, but past bugs are
> not a reason to stop using Inventory.
And what will happen when the asset servers have glitches (which is very
common, especially on peak hours) ?... Avatars will stop baking grid-
wide because their COF will be unreadable by the servers or impossible
to update by the viewers... Granted, baking also fails now because of
asset server issues, but at least, residents who have a cached inventory
list and cached textures for what their avatar is wearing can still bake
properly.
> > My guess is that the only use of the current outfit folder in the
> > future baking system will be to provide a list of inventory items
> > UUIDs (and in fact the UUIDs of the wearables only) together with their
> > layer info (in the links descriptions: what a dirty hack this, too !...)
> > so that the server knows what and how to bake them.
> > In this case, LL could provide an alternative method for viewers not
> > implementing the COF: a message could be sent by the viewer (via a
> > capability) that would hold all the said UUIDs in the proper order
> > (i.e. taking the layers into account). Basically, instead of sending
> > a "go for it, COF is populated, bake from it !" message to the server,
> > the viewer would send a "go for it, here is the list of the inventory
> > items UUIDs to bake !".
> > This would be dead easy to implement as a wrapper to what you (LL) are
> > probably already implementing...
>
> I've forwarded this to the development team for consideration, and will
> let you know if they wish to explore it further.
In fact, instead of letting the server read directly from the COF on
recieval of a "go for it, COF is populated, bake from it !" message
from the viewer, the *standard* message for baking could be the one I
proposed ("go for it, here is the list of the inventory items UUIDs to
bake !"): this would work just as good for COF-based viewers (with just
a little more code to add to retrieve the wearables UUIDs), would
make the baking system *independent* from the inventory structure (in
case it is changed again in the future) and would let the
responsibility to the viewer (and its user) for how the inventory is
used and how the outfits are organized in it...
> In the mean time, you may want to consider what it would take for
> you to provide support for COF at least on the backend.
It would take me a *lot* of grumbling and cursing against Lindens and
their silly hacky ways of implementing simple, straightforward
things and making them into ugly pieces of intricate and unreliable
code (frankly... did you have a look at how the COF is implemented
in v2/3 viewers ?... It's so intricate and convoluted that it's
laughable !)... ;-P
> .../...
> Rest assured that I'll keep you informed on developments; even if it's
> not in our directory, Cool VL has more than enough users that I would
> rather not break it.
Thank you !... And on my side, rest assured I'll keep pestering each
time LL takes such steps as the COF-based baking. ;-)
Regards,
Henri.
_______________________________________________
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
