Re: transcoders bad

Sean,

I know you represent the transcoding side of things, but from my 
perspective this is such a no-brainer. Let's walk through it, shall we? 
I set the no-transform header, ok. That tells the transcoder to go away 
and leave me alone. (At that point, I'm totally ok with not knowing that 
I'm actually talking to a transcoder, if it agrees to pass all my 
traffic completely unchanged.)

But now, having done that, I have to parse an X-Device-User-Agent?  I 
have to change my existing implementation, retest, and so on, to 
facilitate an entity that historically has done nothing but hurt my 
business? For realz?

I'm representative of a whole class of developers. Any mobile developers 
who currently do content negotiation based on the user-agent (pretty 
much anyone who's trying to make money in mobile) now have to change our 
existing implementations because we should all want to hold hands with 
transcoders - entities whose existence is by definition opposite to what 
we do?  Where mistakes made by transcoders are borne by us, not them?

For those of us who are trying to run a business and make money by 
creating tailor-made mobile sites for mobile users, it's clear that the 
W3C proposal does not represent our interests.

Mobile developers should be given priority over transcoders. Transcoders 
have a valid role in the space of delivering mobile content from 
providers who don't create separate mobile sites. Therefore transcoding 
is, by definition, deferent to mobile development. They need to *get out 
of the way* in every sense, if we tell them to. That needs to be 
reflected in the W3C proposal. Otherwise, it's a joke.

Terren

Sean Owen wrote:
> I would love to hear a response to my response, since this is an
> important point and one you are passionate about:
> 
> 1) The guidelines specify that User-Agent's value is preserved in an
> X-Device-User-Agent header, if modified. I am not sure how this is not
> "preserved" then? Maybe you missed that part and this is good news.
> Because on that, we agree -- no reason the information should not be
> preserved.
> 
> 2) If you don't change the User-Agent, you're lying. The site is NOT
> talking to a mobile device! it's talking to a transcoder. It is
> important to tell the site, so that it can say "don't transcode" for
> example. Did you reverse your statement? why would I serve a
> no-transform directive if I *was* talking to a mobile phone directly?
> it's only if I knew I was talking to a transcoder that I would. So,
> preserving the User-Agent is harmful by this logic.
> 
> Sending back mobile-oriented content to a transcoder is likely worse
> than sending back desktop content too. What's your answer to that? I
> think it is a legitimate problem, from experience.
> 
> I do honestly look forward to understanding how you'd propose to avoid
> this problem, for developers like Terren for example.
> 
> On Tue, Aug 5, 2008 at 4:23 AM, Luca Passani <passani@eunet.no> wrote:
>>
>>>  Hi Terren,
>>> The CT Guidelines ensure that any mobile-aware content provider can have
>>> *total control* over whether transcoding is used or not on content, by
>>>  the use of standard HTTP features: See "4.2.2 Server Origination of
>>>  Cache-Control: no-transform".
>> It is not so, Brian. CT Guidelines do not demand that the User-Agent string
>> has to be preserved. This means that a transcoder can use a web browser UA
>> and a mobile site won't even know it is talking to a mobile device and will
>> not know it can serve a "no-trasform" header to the device.
>> More than that, even if the server served "No-trasform" headers
>> unconditionally, it would still be getting the wrong User-Agent.
>>
>> So, please do not mud the water.
>>
>> Luca
>>
>>
>>
>

Received on Tuesday, 5 August 2008 18:20:46 UTC