Re: [wmlprogramming] Re: no-transform and the role of W3C
> how do you mark it as not-to-be-transcoded?you don't. You let the application fail and let the operator take the wrap
The mobile web is hard enough as a platform. When we go out of our way to
fix problems others have caused, we are implicitly sending the message
that everyone can do what they want because they won't be accountable for
it. This has to end. Those who break adopted standards must be called
their names (assholes and fuckers, for example) and be publicly pointed at
as such on blogs and other public forums.
> OK, aside from are legal approaches (which, until there's a test case,
> we can't rely on given conflicting views of legality here); and
> presuming the transcoding industry doesn't spontaneously shut itself
> down rather than risk accidentally transcoding AJAX content ... what
> are our options?
> If you can't distinguish AJAX from regular web traffic, how do you
> mark it as not-to-be-transcoded (err aside from using the standard
> mechanism which has always been in HTTP to do this kinda thing of
> On 12 Dec 2008, at 18:34, Luca Passani wrote:
>> transcoding is an illegitimate activity. So, the right thing to do is
>> "do nothing". If transcoders break your app and constitute a large
>> enough part of your accesses, take whoever is running the transcoder
> Future Platforms Ltd
> e: Tom.Hume@...
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> company: www.futureplatforms.com
> personal: tomhume.org
> [Non-text portions of this message have been removed]
> As of July 14 2005, it's much easier to be banned from WMLProgramming!
> Please fail to read http://groups.yahoo.com/group/wmlprogramming/ before
> you post.Yahoo! Groups Links
- On 16 Dec 2008, at 12:52, Jose Alberto Fernandez wrote:
> minify. The idea is wonderful but it must be controlled at the source,I'm not sure about that. I mean, if it can be configured badly (as
> where they may have a QA team that can check that nothing gets
> broken. And not at some proxy somewhere around the world that can
> care less whether the result is good or a complete disaster.
this stuff can be - was it MS Live which uses InfoGin but recently
started transcoding over-aggressively?) then responsibility could lie
at the deployment. That seems to be where we're going with regular
> Now let's get back to the issue of how to classify transformations.If we're going to break them down, there might be a few other classes:
> Here is my take:
> 1) lossless: you can bet back exactly what you had originally, e.g.
> 2) reduce precision: you get something similar but not exactly the
> same, e.g. converting from one media-type to another with better
> compression but loosing accuracy: TIFF --> JPEG, 16bit --> 8bit color
> space, etc.
> 3) Syntactically equivalent: removing meaningless data. E.g. removing
> comments from a source file, removing meaningless spacing from an XML
> file, etc.
> 4) Semantically equivalent: rewriting the data or code to do exactly
> the same but in a more optimal fashion or less code. E.g. optimizers,
> obfuscators, etc.
> 5) Semantically different: rewriting the data or code to do something
> similar but not exactly the same.
Proxies that, say, strip viruses out (seems useful, but is it type 4
...or block access to certain content:
There's a good link with lots of info on using squid for content
> Well here they are. Opinions? Different categorizations?To me, with HTTP as it is today, I don't find it helpful to
distinguish these kinds of transcoding. I can see examples where each
is useful, and examples where they're unwanted. I personally struggle
to see general rules under which any of these activities can be
considered always OK or always wrong.
> BTW, apart from maybe hardware level compression, the no-transformYep, there's work to be done here I think - helping define how we can
> header disables everything. Whether we want it or not.
selectively apply transformations in future.
Future Platforms Ltd
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422