[sldev] AppendedAcks

Ambrosia chaosstar at gmail.com
Fri Apr 3 00:30:21 PDT 2009


> There's been much discussion on the MMOX mailing list about LLSD vs google
> protocol buffers.
>
> I'm not sure that the rejection was concerning that particular form of
> serialization or merely concerns
> about insisting that we use that particular way of describing the
> on-the-wire protocol.

Sounds to me like a 'We're not sure if we want to use this, or if
there is something better. We can't quite tell why, so better not
change it.' thing ;P

Seriously, compared to current LLSD I don't see a single disadvantage
in the protocol buffers. It's less static, smaller, more flexible. All
in all..more modern.

I'm not sure how easily the EBML language that Thomas mentioned would
be to implement. it certainly seems like an even bigger
data/traffic-saver. The question is, how easily implementable it is,
and how it fares in regards to unompression/decompression/translation
time.

> I see no reason whatsoever to not increase the cache
> (with the above changes) to 10 GB. Why 1 GB is the
> *maximum* that is possible is beyond me.

The 1GB are the maximum that gets stored on hdd between restarts of
the client. I think the limit was much higher once (10gb or so),
before there was a notice about texture corruption, and it has been
since lowered to those 1GB. I've not found any real issues with having
it higher.

As for files that are -not- stored (normally) on hdd between reboots,
but get wiped...uncompressed sound files, prim data, etc. the limit is
actually way higher than 1 GB. There, basically, is none. I've my
client set up to keep the uncompressed sound files that normally get
tossed out, and the cache folder is at around 15gb by now. Makes sound
loading ALOT faster, but eats your hdd like popcorn.


>I'm sure I have my cache not a single byte smaller than most
>people (I have the slider all the way to the max, 1 GB), but
>everytime I go to a new sim and then return home, everything
>is gray and apparently has to be re-downloaded.

If this is really the case, then there definitely is a bug somewhere.
It shouldn't purge textures from cache on TP immediately. Download new
ones, sure, but not purge others from the hdd cache and re-download if
it hasn't hit the 1 GB limit.

> I frequent maybe 10 or so sims a lot - some more than
> others. And the textures that are in those sims have to
> be downloaded, again and again and again.

This really surprises me. The viewer should not purge those textures
completely from the cache unless it hits that 1 GB cap. If it does,
something is rather..wrong.


More information about the SLDev mailing list