I think I will revise the model of how adaption works.
This is adaption:
- Bad: 5 different type of input, 5 different UAs to cater for. That’s ummm 25 mappings. With combinations it can get really wild.
- Good: Simpler stuff like caching and compression can help a lot
- Bad: Caching might cause unpredicatable problems
- Example: Squid and… Kannel? (nah)
- Bad: Really complex
- Bad: Must be updated for different content types and UAs…
- Bad: How do you figure out the limitations of the UA? UA Profiles are useless.
Below is not adaption. The proxy and the client working closely together to provide the total UA.
- Bad: Proxy “adaption” code is UA dependent. And then just usually one specific UA…
- The (client/device) UA is dependent on the proxy. What happens if the proxy fails??
- Good: When it works, it works well with 65% savings
- Bad: Might not scale (can one proxy serve hundreds of the same UA?)
- Bad: Where is the proxy setup and located? If it’s far away it will be slow…
- Bad: Who controls the proxy? The UA vendor? Your network operator? Politics
- Bad: How long will it be maintained? Differing inputs and outputs over time!
- Bad: The UA on the client can’t be updated easily. Proxy stands a better chance, but then “so what?”
- Bad: It is still complex and it is difficult to distinguish itself from an ordinary caching/compressing proxy
- Example : Power Browser and Opera