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

[SignpostMarv Martin]

Dale Mahalko wrote:
> 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.
In order to get appease the pitchfork carrying mob, since textures are 
being fetched over HTTP (and one assumes other assets may be sent over 
HTTP ?), why not just have the remote tool that spits out the asset 
examine permissions and send appropriate caching headers ?

I'd not advocate borking the existing permissions system to figure out 
which headers to send, I'd prefer adding an additional "allow client 
caching" flag, where it sends appropriate Cache-Control headers ? 
http://www.mnot.net/cache_docs/#CACHE-CONTROL


~ Marv.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3249 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/5aebb865/smime.bin