[sldev] Texture caching/bandwidth/performance how to proceed

Dale Mahalko dmahalko at gmail.com
Fri Jun 6 03:57:29 PDT 2008


Is there some particular reason the caching is limited to just
textures? It appears that most everything else also has the potential
to also be cached. Sounds, primitive shapes, notecards, linksets, and
the terrain shape should also apparently be locally cachable.

Regarding the angry pitchforks, I suppose you could do something fast
and stupid like (rot13 + some offset) on everything, and then slap the
DMCA against anyone who "decodes" that "encryption" system. Other than
that, it has been stated over and over that nothing can done to
absolutely protect any asset data from copying, other than server-side
compiled scripts.


I fully accept that there may be strong political views against
developing a robust and comprehensive local cache because that make it
easy to "rip" the sounds, images, and objects created by other people.
I see this as no defense against doing good local caching because
those with the programming skill to do so are already ripping content
from asset system using the client source code and wrappers.

And even if there is strong resistance to having a large and easily
rippable cache on the local user's machine, this should not stop the
development of a "commercial grade" proxy cache for use by an ISP,
school, or business which must support many users all trying to access
the same super-high bandwidth SL system.

The likelihood of someone at an ISP or university ripping someone's
skirt texture from their local 10 TB SL asset-proxy/cache is pretty
darn low, compared to the massive benefits of being able to taking the
asset download strain off their Internet bandwidth.

- Scalar Tardis / Dale Mahalko


On Fri, Jun 6, 2008 at 4:38 AM, Robin Cornelius
<robin.cornelius at gmail.com> wrote:
> What i propose is that we firstly try to subdivide these issues and
> although they are related there seems to be some funtimental top level
> categories that are :-
>
> * Performance
> * Amount of downloaded data


More information about the SLDev mailing list