OK, thanks for the arguments on both options -- they're both valid. I'll
do both, with the query parameter being dominant over the Accept header.
On 12/8/2010 11:10 AM, dz wrote:
Aloha,
I thought the whole rationale behind the jp2 processing was that it
was the only library that promised "progressive" texture quality. The
claimed advantage was that viewers would have "something" to display
after an initial pass at the round robin of asset downloads. As
additional packets arrived, the quality of the texture would improve
for those observing it. I don't have the working experience to know
if that benefit was ever realized, and I seem to recall some
contentious posts in the viewer lists doubting it ever would.
In the case where users see no benefit to using jp2, and have existing
catalogs of textures in other formats, I also prefer the solution
described by (option A)... an extra parameter the user can specify,
with a default of the current jp2. I think Melanies point that
Accept headers sometimes can't be set or relied upon, combined with
the easier to debug EXPLICIT type declaration, make (A) the proper
design decision.
D
On Wed, Dec 8, 2010 at 9:09 AM, Diva Canto <[email protected]
<mailto:[email protected]>> wrote:
Then have your client do that. This doesn't affect the ability for
clients to do that in any way: simply omit the extra information.
Other clients benefit from the server doing the conversion, and
the result of that conversion being cached on the server side, so
that future requests get exactly what they need.
Technically, this conversion does not belong to the simulator; it
belongs to the GetTexture service associated with the simulator;
this service can execute anywhere.
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
