[Opensim-dev] Accessing textures via HTTP [bayes]

[Mystical Demina]

I also think that just because a texture comes off of HTTP doesn't mean
security can't be applied.

 

I can see scenarios to duplicate textures across multiple web servers to
improve downloading performance.

 

I kind of look forward to the day when I can apply URLs as textures and
manage all my textures like I to for a web site.

 

Regards,

Kevin Tweedy

 

 

 

  _____  

From: Diva Canto [mailto:diva at metaverseink.com] 
Sent: Wednesday, March 18, 2009 2:01 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Accessing textures via HTTP [bayes]

 

On the server-side, this can be made configurable, default to false. If
server admins want to serve jpgs, let's let them.
Since this work is being done within the Idealist viewer, a separate issue
is whether you want Idealist to assume the existence of jpgs on the server
or not. But that's a client-side decision.

Dahlia Trimble wrote: 

I don't think it's a goal of OpenSim  to serve texture assets to web
browsers, nor should it be. Such a move would open doors to texture piracy
and reduce any incentives for content creators to distribute their content
on any OpenSim based platform. Grid operators who would want to serve their
texture assets as jpeg files and make them available to web browsers could
write their own conversion programs to do so. 

 

Personally I would not upload any of my textures to any service that
distributes them as jpeg over http unless they were creative commons
textures.

 

On Wed, Mar 18, 2009 at 9:51 AM, Tommi Laukkanen
<tommi.s.e.laukkanen at gmail.com> wrote:

I think j2k is not really supported by any main stream web browser
software nor SDK APIs of different languages. Requiring opejpeg native
lib to be included in all clients is not a good design decission. It
would be much cleaner if you can operate with the nativate image
manipulation API like System.Drawing in .NET. The converted JPEG's can
be easily cached for now. It is only the SL viewers which require it
because of some odd design decission from Linden Lab. I would not be
surprised if in the future textures will be stored as png and
converted to j2k for sl protocol. In high quality virtual world
lossless texture format could be preferable. Odd codecs should not be
forced on other protocols and clients based on ll behaviour.
Especially if we are experimenting with new brand of client / protocol
stacks like IdealistViewer and MXP.

I truly hope metaverse is not stuck with openjepg and j2k. Those
native libs tend to be more trouble than they are worth unless you
absoletuly need them.

Using the accept headers sounds like a good idea to me and if it is ok
with the team I could implement region asset service as Diva suggested
in the patch notes and Accept header support. I can put in cache as
well to avoid performance bottleneck. About image quality: we will end
up transforming from j2k anyway to some image format the client
rendering engine supports. I can also convert from j2k to png instead
of jpg to avoid any degradation as png is lossless format.

One could also consider naming the class as proxy as it will proxy the
call to local or remote asset server. Doing local caching on proxy is
a pattern used in http proxies and it could work for us as well.
Caching assets on region would lower the load on the grid asset
database.

-Tommi

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

 





  _____  



 
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090318/b75ab765/attachment-0001.html>