- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 3 Oct 2014 10:40:04 -0700
- To: "eberhard speer jr." <seshat@ducis.net>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, WHAT Working Group <whatwg@whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>
On Fri, Oct 3, 2014 at 5:09 AM, eberhard speer jr. <seshat@ducis.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/10/2014 09:38, Jonas Sicking wrote: >> On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. >> <seshat@ducis.net> wrote: >>> If you are interested in the intricacies of "UA-sniffing", client >>> and server-side, the use-cases, the esoterica etc I'll gladly >>> contribute what I can. >> >> I guess the question at hand is: >> >> What are the client-side situations when people need to do look up >> device capabilities using "UA-sniffing" and DeviceMap? I.e. when >> can't they use JS code and the APIs exposed through the DOM to >> detect what capabilities are available, and instead they have to >> look up these capabilities in DeviceMap? >> >> For server-side UA sniffing these situations are much more clear >> since the server has information to *much* less information. I.e. >> the server only has access to the headers that the browser sent. >> >> However JS code running in a browser has access to a much richer >> amount of information. So when does it need to use DeviceMap? >> >> / Jonas >> > Hi, > > I fear you greatly oversimplify matters. > For starters, 'responsive design' is not the only use case and > secondly it is not the case that the server is at a disadvantage > information wise, as a matter of fact, once a device is linked to a > known UA-profile the opposite is very much the case. > I must say I'm somewhat taken aback by this dismissive attitude. I fear that you must have somehow misread my email above. I did intend to focus only on responsive design. In fact, I did not mention responsive design at all. I instead tried to ask broadly for use cases where people use DeviceMap since you graciously offered to help with providing them. It was also not my intent to be dismissive of anything. Neither people, use cases, software stacks, requirements or opinions. I'm not sure what it is that you feel that I was dismissive of but I apologize and can only assure you that that was not my intent at all. I did however want to specifically focus the discussion about client side practices and use cases. The reason for this is not that I feel like server side practices and use cases are not important, but rather that the topic of this thread is whether to add a clicent-side property specifically to make it easier for people that use things like DeviceMap on the client side. It still does seem to me that client side logic running in a browser has access to a richer set of information about that browser than server side logic which received a network request from that browser. Simply because the client side logic has access to the same information about the browser as the server side does. But in addition it can use JS and the DOM to check for existence or non-existence of hundreds of APIs, as well as use a handful of APIs that were specifically designed to expose information about the browser. However I could very well be wrong about that. But that is simply due to being uninformed and had no origin in malice or uncaringness at all. I could see for example that server side logic has much more efficient access to databases such as DeviceMap. I had thought that client side logic could access the same type of databases using network requests, but perhaps that is often not practical due to performance constraints. So I definitely imagine that I could be wrong about which environment effectively has access to better information. But I'd rather not guess at where I made an error in logic and would instead appreciate if you point out where I'm making the wrong assumptions. / Jonas
Received on Friday, 3 October 2014 17:40:59 UTC