You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Reza <re...@yahoo.com.INVALID> on 2014/07/30 03:18:19 UTC
Re: OS detection
We can definitely extend our desktop detection to do OS detection too.
So the reason that we have desktop detection is for backend responsive/adaptive web design. Desktop users have a mouse and a much larger viewing area. Phone users have a touch screen and a much smaller viewing area. That is an extremely important distinction to be made when you are serving a responsive/adaptive layout. So I would be careful when you say that desktopDevice is quite meaningless :)
Sure, there are other use cases for DeviceMap where you want to know more specific information about a desktop. So maybe we should step back and better understand who are our potential users and how they plan on using DeviceMap? Are they doing responsive/adaptive web design? Web analytics? Something else?
Just an FYI, I spend a *lot* of time working with frontends, responsive, and adaptive designs, so my opinion is always heavily steered towards this use case.
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Tuesday, July 29, 2014 8:59 PM
Subject: Re: Take stock
Based on initial OpenDDR (desktopDevice is not new btw. only got a few extra properties or screen "assumption" changed from 800x600 to 1600x900, whether that makes sense is another question) experience told us, that e.g. Apple devices of all kind, including MacBook, etc. had a more descriptive recognition based on "genericApple".
Hence it is dangerous and leads to missing even the most trivial information like the "Windows" string for the OS if the fallback is too generic.
There is a "genericLG" which could under certain circumstances act as the most common fallback for an LG phone with Firefox OS, but now there is a generic OS root, too.
W3C DDR and implementations like Open/DeviceMap DDR know at least 3 "aspects", if you want those are extensible, so having a fallback "hardware" or "OS" may conflict with each other, see the "desktop" which is quite meaningless and loses the information that this is a "Windows" desktop at the moment
Werner
On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com> wrote:
Well there are 2 aspects, one API, the "new/alternate" client may evolve, and putting those things in JIRA is not wrong.
>Whether the person responsible for a component (i.E. Reza for the Java client or yourself for .NET) just picks something or there is some sort of "voting process" (with a series of +1 or similar, see Eclipse, I also recall having heard about that somewhere here) that is probably worth considering.
>
>
>Even though design patterns are applied in most modern languages, not everything might be applied exactly the same way on the .NET side, so if you don't see the need of a "factory" for something there, just leave it.
>
>
>The data can use some care, not just for brand new platforms, and IMHO adding a reliable recognition of new families like Firefox OS, Blackberry 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a lot to do and no need to wait. We may rarely have JIRA tickets other than from actual committers now, but even on GitHub there are one or two ODDR either overlooked or did not consider a high priority including a fix for BlackBerry OS which we are probbly still missing in the current device-data.
>
>
>I'm afraid, the "desktopDevice" doesn't add that much value right now, given I see:
>model: browser
>ajax_support_getelementbyid: true
>marketing_name: -
>displayWidth: 1600
>id: desktopDevice
>device_os: -
>xhtml_format_as_attribute: false
>is_crawler: false
>dual_orientation: false
>nokia_series: 0
>device_os_version: -
>nokia_edition: 0
>vendor: desktop
>mobile_browser_version: -
>ajax_support_events: true
>is_desktop: true
>ajax_support_inner_html: true
>image_inlining: false
>mobile_browser: -
>ajax_support_event_listener: true
>ajax_manipulate_css: true
>displayHeight: 900
>is_tablet: false
>inputDevices: -
>ajax_support_javascript: true
>is_wireless_device: false
>ajax_manipulate_dom: true
>xhtml_format_as_css_property: false
>
>
>running the console demo or any comparable Java client app against a local Windows 7.
>So "is_crawler" or even a new "pixel_density" which might be of relevance to Retina screens, could be a nice extra gimick but a default display of 1600x900 is meaningless for a desktop and http://www.useragentstring.com/index.php tells me this
>
>
>Chrome 36.0.1985.125
>Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent, which is only true for Gecko browsers like Firefox and Netscape. For all other user agents it means 'Mozilla-compatible'. In modern browsers, this is only used for historical reasons. It has no real meaning anymore
>5.0 Mozilla version
>Windows NT 6.1 Operating System:
> Windows 7
>WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a 64-bit processor
>AppleWebKit The Web Kit provides a set of core classes to display web content in windows
>537.36 Web Kit build
>KHTML Open Source HTML layout engine developed by the KDE project
>like Gecko like Gecko...
>Chrome Name :
>Chrome
>36.0.1985.125 Chrome version
>Safari Based on Safari
>537.36
>
>
>based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
>
>
>So we are far from that I'm afraid,
>Whether it's the hierarchy, that is rather likely something not only to be fixed or introduced for Firefox OS.
>
>
>I added an initial "genericFirefoxOS", feel free to experiment with extensions to that. As of now I didn't add a child device that would detect say:
>Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
>
>
>
>Werner
>
>
>On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net> wrote:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Hey guys,
>>
>>can you please "hold your horses" for a minute ?
>>
>>I think we all agree a review of the Vocabulary is in order -- for
>>example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
>>file and mentioning it in JIRA does not strike me as proper.
>>
>>And I think the same goes for 'quickly' turning this, that and the
>>other into a "Factory" and adding a 'this' and a 'that' left, right
>>and center to the API.
>>
>>It seems to me that after the recent votes, we should take stock of
>>the situation, agree on what's next and *then* do the next thing.
>>
>>esjr
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v2.0.22 (MingW32)
>>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>>iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
>>iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
>>vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
>>4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
>>+wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
>>byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
>>=Fsfe
>>-----END PGP SIGNATURE-----
>>
>
Re: OS detection
Posted by Werner Keil <we...@gmail.com>.
Thanks, good to know. The dClass project seems primarily by Reza, but
unless some of his Java client work is inspired by the code there, it does
not seem subject to DeviceMap contribution[?]
If even a very simple PHP example could be written by a PHP-savy person it
would certainly be a good addition to demonstrate it for various languages
or platforms.
Regards,
Werner
On Wed, Jul 30, 2014 at 10:25 AM, Adam Leach <ad...@adders.eu> wrote:
> I'm currently using OpenDDR on a number of php sites to get the browser
> type (ie desktop, smartphone, bot, etc) and the browser name (ie Chrome,
> Firefox, etc) . These are then recorded for analytics and passed to the
> backend to allow for the detection for mobile sites.
>
> On the PHP side it has got a built-in feature
> (http://php.net/manual/en/function.get-browser.php) that uses a .ini
> file and regular expressions, however this is relatively slow and is
> reliant on the http://browscap.org/ project. Most of the frameworks
> have stopped integrating with the browser detection libraries as they
> are mainly commercial.
>
> I use https://github.com/TheWeatherChannel/dClass module built into
> Varnish for the detection and then set additional headers that are
> passed to the backend.
>
> Regards
>
> Adam
>
> On 30/07/2014 02:34, Werner Keil wrote:
> > Simply assuming every desktopDevice must now have 1600x900 pixel is
> > dangerous and does not add much value to layout or responsive design,
> etc.
> >
> > I spoke to a friend from the PHP camp who was also in Nürnberg as
> speaker,
> > and not only in this area he once again confirmed, a majority of users
> > probably would not use any of these repositories, neither Open Source
> (like
> > DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly
> > in PHP. A vast majority of "end users" or web designers rely on a
> framework
> > or content engine like Zend, Typo3, or WordPress and those engines have
> to
> > provide some level of device regognition.
> >
> > Similar for Java, the PoC (and if some of them work on the Apache site it
> > is nice to test it against a variety of devices before thinking to use
> it)
> > is OK as a demonstrator, but people would prefer to have the Spring
> Mobile,
> > or the JSF library of their choice use it where necessary, or Portal
> > servers like Liferay or Pluto.
> >
> > Werner
> >
> > On Wed, Jul 30, 2014 at 3:18 AM, Reza <re...@yahoo.com.invalid>
> > wrote:
> >
> >> We can definitely extend our desktop detection to do OS detection too.
> >>
> >> So the reason that we have desktop detection is for backend
> >> responsive/adaptive web design. Desktop users have a mouse and a much
> >> larger viewing area. Phone users have a touch screen and a much smaller
> >> viewing area. That is an extremely important distinction to be made when
> >> you are serving a responsive/adaptive layout. So I would be careful when
> >> you say that desktopDevice is quite meaningless :)
> >>
> >> Sure, there are other use cases for DeviceMap where you want to know
> more
> >> specific information about a desktop. So maybe we should step back and
> >> better understand who are our potential users and how they plan on using
> >> DeviceMap? Are they doing responsive/adaptive web design? Web analytics?
> >> Something else?
> >>
> >> Just an FYI, I spend a *lot* of time working with frontends, responsive,
> >> and adaptive designs, so my opinion is always heavily steered towards
> this
> >> use case.
> >>
> >>
> >> ________________________________
> >> From: Werner Keil <we...@gmail.com>
> >> To: "devicemap-dev@incubator.apache.org" <
> >> devicemap-dev@incubator.apache.org>
> >> Sent: Tuesday, July 29, 2014 8:59 PM
> >> Subject: Re: Take stock
> >>
> >>
> >>
> >> Based on initial OpenDDR (desktopDevice is not new btw. only got a few
> >> extra properties or screen "assumption" changed from 800x600 to
> 1600x900,
> >> whether that makes sense is another question) experience told us, that
> e.g.
> >> Apple devices of all kind, including MacBook, etc. had a more
> descriptive
> >> recognition based on "genericApple".
> >>
> >> Hence it is dangerous and leads to missing even the most trivial
> >> information like the "Windows" string for the OS if the fallback is too
> >> generic.
> >> There is a "genericLG" which could under certain circumstances act as
> the
> >> most common fallback for an LG phone with Firefox OS, but now there is a
> >> generic OS root, too.
> >>
> >> W3C DDR and implementations like Open/DeviceMap DDR know at least 3
> >> "aspects", if you want those are extensible, so having a fallback
> >> "hardware" or "OS" may conflict with each other, see the "desktop"
> which is
> >> quite meaningless and loses the information that this is a "Windows"
> >> desktop at the moment
> >>
> >> Werner
> >>
> >>
> >>
> >>
> >> On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com>
> >> wrote:
> >>
> >> Well there are 2 aspects, one API, the "new/alternate" client may
> evolve,
> >> and putting those things in JIRA is not wrong.
> >>> Whether the person responsible for a component (i.E. Reza for the Java
> >> client or yourself for .NET) just picks something or there is some sort
> of
> >> "voting process" (with a series of +1 or similar, see Eclipse, I also
> >> recall having heard about that somewhere here) that is probably worth
> >> considering.
> >>>
> >>> Even though design patterns are applied in most modern languages, not
> >> everything might be applied exactly the same way on the .NET side, so if
> >> you don't see the need of a "factory" for something there, just leave
> it.
> >>>
> >>> The data can use some care, not just for brand new platforms, and IMHO
> >> adding a reliable recognition of new families like Firefox OS,
> Blackberry
> >> 10 or Windows Phone 7 or 8, the certain age of the baseline means
> there's a
> >> lot to do and no need to wait. We may rarely have JIRA tickets other
> than
> >> from actual committers now, but even on GitHub there are one or two ODDR
> >> either overlooked or did not consider a high priority including a fix
> for
> >> BlackBerry OS which we are probbly still missing in the current
> device-data.
> >>>
> >>> I'm afraid, the "desktopDevice" doesn't add that much value right now,
> >> given I see:
> >>> model: browser
> >>> ajax_support_getelementbyid: true
> >>> marketing_name: -
> >>> displayWidth: 1600
> >>> id: desktopDevice
> >>> device_os: -
> >>> xhtml_format_as_attribute: false
> >>> is_crawler: false
> >>> dual_orientation: false
> >>> nokia_series: 0
> >>> device_os_version: -
> >>> nokia_edition: 0
> >>> vendor: desktop
> >>> mobile_browser_version: -
> >>> ajax_support_events: true
> >>> is_desktop: true
> >>> ajax_support_inner_html: true
> >>> image_inlining: false
> >>> mobile_browser: -
> >>> ajax_support_event_listener: true
> >>> ajax_manipulate_css: true
> >>> displayHeight: 900
> >>> is_tablet: false
> >>> inputDevices: -
> >>> ajax_support_javascript: true
> >>> is_wireless_device: false
> >>> ajax_manipulate_dom: true
> >>> xhtml_format_as_css_property: false
> >>>
> >>>
> >>> running the console demo or any comparable Java client app against a
> >> local Windows 7.
> >>> So "is_crawler" or even a new "pixel_density" which might be of
> relevance
> >> to Retina screens, could be a nice extra gimick but a default display of
> >> 1600x900 is meaningless for a desktop and
> >> http://www.useragentstring.com/index.php tells me this
> >>>
> >>> Chrome 36.0.1985.125
> >>> Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent,
> >> which is only true for Gecko browsers like Firefox and Netscape. For all
> >> other user agents it means 'Mozilla-compatible'. In modern browsers,
> this
> >> is only used for historical reasons. It has no real meaning anymore
> >>> 5.0 Mozilla version
> >>> Windows NT 6.1 Operating System:
> >>> Windows 7
> >>> WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a
> >> 64-bit processor
> >>> AppleWebKit The Web Kit provides a set of core classes to display web
> >> content in windows
> >>> 537.36 Web Kit build
> >>> KHTML Open Source HTML layout engine developed by the KDE project
> >>> like Gecko like Gecko...
> >>> Chrome Name :
> >>> Chrome
> >>> 36.0.1985.125 Chrome version
> >>> Safari Based on Safari
> >>> 537.36
> >>>
> >>>
> >>> based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64)
> >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125
> Safari/537.36
> >>>
> >>> So we are far from that I'm afraid,
> >>> Whether it's the hierarchy, that is rather likely something not only to
> >> be fixed or introduced for Firefox OS.
> >>>
> >>> I added an initial "genericFirefoxOS", feel free to experiment with
> >> extensions to that. As of now I didn't add a child device that would
> detect
> >> say:
> >>> Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
> >>>
> >>>
> >>>
> >>> Werner
> >>>
> >>>
> >>> On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net>
> >> wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Hey guys,
> >>>>
> >>>> can you please "hold your horses" for a minute ?
> >>>>
> >>>> I think we all agree a review of the Vocabulary is in order -- for
> >>>> example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
> >>>> file and mentioning it in JIRA does not strike me as proper.
> >>>>
> >>>> And I think the same goes for 'quickly' turning this, that and the
> >>>> other into a "Factory" and adding a 'this' and a 'that' left, right
> >>>> and center to the API.
> >>>>
> >>>> It seems to me that after the recent votes, we should take stock of
> >>>> the situation, agree on what's next and *then* do the next thing.
> >>>>
> >>>> esjr
> >>>> -----BEGIN PGP SIGNATURE-----
> >>>> Version: GnuPG v2.0.22 (MingW32)
> >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>>
> >>>> iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
> >>>> iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
> >>>> vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
> >>>> 4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
> >>>> +wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
> >>>> byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
> >>>> =Fsfe
> >>>> -----END PGP SIGNATURE-----
> >>>>
>
>
Re: OS detection
Posted by Adam Leach <ad...@adders.eu>.
I'm currently using OpenDDR on a number of php sites to get the browser
type (ie desktop, smartphone, bot, etc) and the browser name (ie Chrome,
Firefox, etc) . These are then recorded for analytics and passed to the
backend to allow for the detection for mobile sites.
On the PHP side it has got a built-in feature
(http://php.net/manual/en/function.get-browser.php) that uses a .ini
file and regular expressions, however this is relatively slow and is
reliant on the http://browscap.org/ project. Most of the frameworks
have stopped integrating with the browser detection libraries as they
are mainly commercial.
I use https://github.com/TheWeatherChannel/dClass module built into
Varnish for the detection and then set additional headers that are
passed to the backend.
Regards
Adam
On 30/07/2014 02:34, Werner Keil wrote:
> Simply assuming every desktopDevice must now have 1600x900 pixel is
> dangerous and does not add much value to layout or responsive design, etc.
>
> I spoke to a friend from the PHP camp who was also in Nürnberg as speaker,
> and not only in this area he once again confirmed, a majority of users
> probably would not use any of these repositories, neither Open Source (like
> DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly
> in PHP. A vast majority of "end users" or web designers rely on a framework
> or content engine like Zend, Typo3, or WordPress and those engines have to
> provide some level of device regognition.
>
> Similar for Java, the PoC (and if some of them work on the Apache site it
> is nice to test it against a variety of devices before thinking to use it)
> is OK as a demonstrator, but people would prefer to have the Spring Mobile,
> or the JSF library of their choice use it where necessary, or Portal
> servers like Liferay or Pluto.
>
> Werner
>
> On Wed, Jul 30, 2014 at 3:18 AM, Reza <re...@yahoo.com.invalid>
> wrote:
>
>> We can definitely extend our desktop detection to do OS detection too.
>>
>> So the reason that we have desktop detection is for backend
>> responsive/adaptive web design. Desktop users have a mouse and a much
>> larger viewing area. Phone users have a touch screen and a much smaller
>> viewing area. That is an extremely important distinction to be made when
>> you are serving a responsive/adaptive layout. So I would be careful when
>> you say that desktopDevice is quite meaningless :)
>>
>> Sure, there are other use cases for DeviceMap where you want to know more
>> specific information about a desktop. So maybe we should step back and
>> better understand who are our potential users and how they plan on using
>> DeviceMap? Are they doing responsive/adaptive web design? Web analytics?
>> Something else?
>>
>> Just an FYI, I spend a *lot* of time working with frontends, responsive,
>> and adaptive designs, so my opinion is always heavily steered towards this
>> use case.
>>
>>
>> ________________________________
>> From: Werner Keil <we...@gmail.com>
>> To: "devicemap-dev@incubator.apache.org" <
>> devicemap-dev@incubator.apache.org>
>> Sent: Tuesday, July 29, 2014 8:59 PM
>> Subject: Re: Take stock
>>
>>
>>
>> Based on initial OpenDDR (desktopDevice is not new btw. only got a few
>> extra properties or screen "assumption" changed from 800x600 to 1600x900,
>> whether that makes sense is another question) experience told us, that e.g.
>> Apple devices of all kind, including MacBook, etc. had a more descriptive
>> recognition based on "genericApple".
>>
>> Hence it is dangerous and leads to missing even the most trivial
>> information like the "Windows" string for the OS if the fallback is too
>> generic.
>> There is a "genericLG" which could under certain circumstances act as the
>> most common fallback for an LG phone with Firefox OS, but now there is a
>> generic OS root, too.
>>
>> W3C DDR and implementations like Open/DeviceMap DDR know at least 3
>> "aspects", if you want those are extensible, so having a fallback
>> "hardware" or "OS" may conflict with each other, see the "desktop" which is
>> quite meaningless and loses the information that this is a "Windows"
>> desktop at the moment
>>
>> Werner
>>
>>
>>
>>
>> On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com>
>> wrote:
>>
>> Well there are 2 aspects, one API, the "new/alternate" client may evolve,
>> and putting those things in JIRA is not wrong.
>>> Whether the person responsible for a component (i.E. Reza for the Java
>> client or yourself for .NET) just picks something or there is some sort of
>> "voting process" (with a series of +1 or similar, see Eclipse, I also
>> recall having heard about that somewhere here) that is probably worth
>> considering.
>>>
>>> Even though design patterns are applied in most modern languages, not
>> everything might be applied exactly the same way on the .NET side, so if
>> you don't see the need of a "factory" for something there, just leave it.
>>>
>>> The data can use some care, not just for brand new platforms, and IMHO
>> adding a reliable recognition of new families like Firefox OS, Blackberry
>> 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a
>> lot to do and no need to wait. We may rarely have JIRA tickets other than
>> from actual committers now, but even on GitHub there are one or two ODDR
>> either overlooked or did not consider a high priority including a fix for
>> BlackBerry OS which we are probbly still missing in the current device-data.
>>>
>>> I'm afraid, the "desktopDevice" doesn't add that much value right now,
>> given I see:
>>> model: browser
>>> ajax_support_getelementbyid: true
>>> marketing_name: -
>>> displayWidth: 1600
>>> id: desktopDevice
>>> device_os: -
>>> xhtml_format_as_attribute: false
>>> is_crawler: false
>>> dual_orientation: false
>>> nokia_series: 0
>>> device_os_version: -
>>> nokia_edition: 0
>>> vendor: desktop
>>> mobile_browser_version: -
>>> ajax_support_events: true
>>> is_desktop: true
>>> ajax_support_inner_html: true
>>> image_inlining: false
>>> mobile_browser: -
>>> ajax_support_event_listener: true
>>> ajax_manipulate_css: true
>>> displayHeight: 900
>>> is_tablet: false
>>> inputDevices: -
>>> ajax_support_javascript: true
>>> is_wireless_device: false
>>> ajax_manipulate_dom: true
>>> xhtml_format_as_css_property: false
>>>
>>>
>>> running the console demo or any comparable Java client app against a
>> local Windows 7.
>>> So "is_crawler" or even a new "pixel_density" which might be of relevance
>> to Retina screens, could be a nice extra gimick but a default display of
>> 1600x900 is meaningless for a desktop and
>> http://www.useragentstring.com/index.php tells me this
>>>
>>> Chrome 36.0.1985.125
>>> Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent,
>> which is only true for Gecko browsers like Firefox and Netscape. For all
>> other user agents it means 'Mozilla-compatible'. In modern browsers, this
>> is only used for historical reasons. It has no real meaning anymore
>>> 5.0 Mozilla version
>>> Windows NT 6.1 Operating System:
>>> Windows 7
>>> WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a
>> 64-bit processor
>>> AppleWebKit The Web Kit provides a set of core classes to display web
>> content in windows
>>> 537.36 Web Kit build
>>> KHTML Open Source HTML layout engine developed by the KDE project
>>> like Gecko like Gecko...
>>> Chrome Name :
>>> Chrome
>>> 36.0.1985.125 Chrome version
>>> Safari Based on Safari
>>> 537.36
>>>
>>>
>>> based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64)
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
>>>
>>> So we are far from that I'm afraid,
>>> Whether it's the hierarchy, that is rather likely something not only to
>> be fixed or introduced for Firefox OS.
>>>
>>> I added an initial "genericFirefoxOS", feel free to experiment with
>> extensions to that. As of now I didn't add a child device that would detect
>> say:
>>> Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>> On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net>
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hey guys,
>>>>
>>>> can you please "hold your horses" for a minute ?
>>>>
>>>> I think we all agree a review of the Vocabulary is in order -- for
>>>> example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
>>>> file and mentioning it in JIRA does not strike me as proper.
>>>>
>>>> And I think the same goes for 'quickly' turning this, that and the
>>>> other into a "Factory" and adding a 'this' and a 'that' left, right
>>>> and center to the API.
>>>>
>>>> It seems to me that after the recent votes, we should take stock of
>>>> the situation, agree on what's next and *then* do the next thing.
>>>>
>>>> esjr
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v2.0.22 (MingW32)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
>>>> iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
>>>> vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
>>>> 4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
>>>> +wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
>>>> byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
>>>> =Fsfe
>>>> -----END PGP SIGNATURE-----
>>>>
Re: OS detection
Posted by Werner Keil <we...@gmail.com>.
As mentioned it will only be used via a decent number of "UI Component
Libraries", beside Spring (not just using Spring, but having Spring Mobile (
http://projects.spring.io/spring-mobile/) and similar projects use or at
leasts directly refer to it.
I was quite sucessful, see RichFaces Mobile
https://community.jboss.org/wiki/GettingStartedWithMobileRichFaces to
evangelize OpenDDR.
It probably takes at least graduation to take DeviceMap seriously, but see
CDI as well as Spring the current static singleton offered by the
Classifier will make it harder for most DI containers to use. When the time
is right for Pluto I also propose or actively participate in DeviceMap
support, but first of all Pluto needs to move to Portlet 3, that is
currently more important. Apache DeltaSpike also has potential, so do a few
other APIs, I mentioned them a few times, it does not mean we need to write
something against all of them, but they should be attracted to the project
to use it[?]
On Wed, Jul 30, 2014 at 3:43 AM, Reza <re...@yahoo.com.invalid>
wrote:
> I dont think that 1600x900 is supposed to be taken literally. Obviously
> you cannot detect the size of a browser window on the backend. That is
> basically meant to be a placeholder. If you are using backend device
> classification for the window size, simply put, you are doing frontend
> wrong.
>
> Werner, what DeviceMap use case do you advocate? Or do you see no use for
> this project?
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> Sent: Tuesday, July 29, 2014 9:34 PM
> Subject: Re: OS detection
>
>
>
> Simply assuming every desktopDevice must now have 1600x900 pixel is
> dangerous and does not add much value to layout or responsive design, etc.
>
> I spoke to a friend from the PHP camp who was also in Nürnberg as speaker,
> and not only in this area he once again confirmed, a majority of users
> probably would not use any of these repositories, neither Open Source (like
> DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly
> in PHP. A vast majority of "end users" or web designers rely on a framework
> or content engine like Zend, Typo3, or WordPress and those engines have to
> provide some level of device regognition.
>
> Similar for Java, the PoC (and if some of them work on the Apache site it
> is nice to test it against a variety of devices before thinking to use it)
> is OK as a demonstrator, but people would prefer to have the Spring Mobile,
> or the JSF library of their choice use it where necessary, or Portal
> servers like Liferay or Pluto.
>
> Werner
>
>
>
>
> On Wed, Jul 30, 2014 at 3:18 AM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> We can definitely extend our desktop detection to do OS detection too.
> >
> >So the reason that we have desktop detection is for backend
> responsive/adaptive web design. Desktop users have a mouse and a much
> larger viewing area. Phone users have a touch screen and a much smaller
> viewing area. That is an extremely important distinction to be made when
> you are serving a responsive/adaptive layout. So I would be careful when
> you say that desktopDevice is quite meaningless :)
> >
> >Sure, there are other use cases for DeviceMap where you want to know more
> specific information about a desktop. So maybe we should step back and
> better understand who are our potential users and how they plan on using
> DeviceMap? Are they doing responsive/adaptive web design? Web analytics?
> Something else?
> >
> >Just an FYI, I spend a *lot* of time working with frontends, responsive,
> and adaptive designs, so my opinion is always heavily steered towards this
> use case.
> >
> >
> >________________________________
> > From: Werner Keil <we...@gmail.com>
> >To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> >Sent: Tuesday, July 29, 2014 8:59 PM
> >Subject: Re: Take stock
> >
> >
> >
> >Based on initial OpenDDR (desktopDevice is not new btw. only got a few
> extra properties or screen "assumption" changed from 800x600 to 1600x900,
> whether that makes sense is another question) experience told us, that e.g.
> Apple devices of all kind, including MacBook, etc. had a more descriptive
> recognition based on "genericApple".
> >
> >Hence it is dangerous and leads to missing even the most trivial
> information like the "Windows" string for the OS if the fallback is too
> generic.
> >There is a "genericLG" which could under certain circumstances act as the
> most common fallback for an LG phone with Firefox OS, but now there is a
> generic OS root, too.
> >
> >W3C DDR and implementations like Open/DeviceMap DDR know at least 3
> "aspects", if you want those are extensible, so having a fallback
> "hardware" or "OS" may conflict with each other, see the "desktop" which is
> quite meaningless and loses the information that this is a "Windows"
> desktop at the moment
> >
> >Werner
> >
> >
> >
> >
> >On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com>
> wrote:
> >
> >Well there are 2 aspects, one API, the "new/alternate" client may evolve,
> and putting those things in JIRA is not wrong.
> >>Whether the person responsible for a component (i.E. Reza for the Java
> client or yourself for .NET) just picks something or there is some sort of
> "voting process" (with a series of +1 or similar, see Eclipse, I also
> recall having heard about that somewhere here) that is probably worth
> considering.
> >>
> >>
> >>Even though design patterns are applied in most modern languages, not
> everything might be applied exactly the same way on the .NET side, so if
> you don't see the need of a "factory" for something there, just leave it.
> >>
> >>
> >>The data can use some care, not just for brand new platforms, and IMHO
> adding a reliable recognition of new families like Firefox OS, Blackberry
> 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a
> lot to do and no need to wait. We may rarely have JIRA tickets other than
> from actual committers now, but even on GitHub there are one or two ODDR
> either overlooked or did not consider a high priority including a fix for
> BlackBerry OS which we are probbly still missing in the current device-data.
> >>
> >>
> >>I'm afraid, the "desktopDevice" doesn't add that much value right now,
> given I see:
> >>model: browser
> >>ajax_support_getelementbyid: true
> >>marketing_name: -
> >>displayWidth: 1600
> >>id: desktopDevice
> >>device_os: -
> >>xhtml_format_as_attribute: false
> >>is_crawler: false
> >>dual_orientation: false
> >>nokia_series: 0
> >>device_os_version: -
> >>nokia_edition: 0
> >>vendor: desktop
> >>mobile_browser_version: -
> >>ajax_support_events: true
> >>is_desktop: true
> >>ajax_support_inner_html: true
> >>image_inlining: false
> >>mobile_browser: -
> >>ajax_support_event_listener: true
> >>ajax_manipulate_css: true
> >>displayHeight: 900
> >>is_tablet: false
> >>inputDevices: -
> >>ajax_support_javascript: true
> >>is_wireless_device: false
> >>ajax_manipulate_dom: true
> >>xhtml_format_as_css_property: false
> >>
> >>
> >>running the console demo or any comparable Java client app against a
> local Windows 7.
> >>So "is_crawler" or even a new "pixel_density" which might be of
> relevance to Retina screens, could be a nice extra gimick but a default
> display of 1600x900 is meaningless for a desktop and
> http://www.useragentstring.com/index.php tells me this
> >>
> >>
> >>Chrome 36.0.1985.125
> >>Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent,
> which is only true for Gecko browsers like Firefox and Netscape. For all
> other user agents it means 'Mozilla-compatible'. In modern browsers, this
> is only used for historical reasons. It has no real meaning anymore
> >>5.0 Mozilla version
> >>Windows NT 6.1 Operating System:
> >> Windows 7
> >>WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a
> 64-bit processor
> >>AppleWebKit The Web Kit provides a set of core classes to display web
> content in windows
> >>537.36 Web Kit build
> >>KHTML Open Source HTML layout engine developed by the KDE project
> >>like Gecko like Gecko...
> >>Chrome Name :
> >>Chrome
> >>36.0.1985.125 Chrome version
> >>Safari Based on Safari
> >>537.36
> >>
> >>
> >>based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
> >>
> >>
> >>So we are far from that I'm afraid,
> >>Whether it's the hierarchy, that is rather likely something not only to
> be fixed or introduced for Firefox OS.
> >>
> >>
> >>I added an initial "genericFirefoxOS", feel free to experiment with
> extensions to that. As of now I didn't add a child device that would detect
> say:
> >>Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
> >>
> >>
> >>
> >>Werner
> >>
> >>
> >>On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net>
> wrote:
> >>
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>Hey guys,
> >>>
> >>>can you please "hold your horses" for a minute ?
> >>>
> >>>I think we all agree a review of the Vocabulary is in order -- for
> >>>example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
> >>>file and mentioning it in JIRA does not strike me as proper.
> >>>
> >>>And I think the same goes for 'quickly' turning this, that and the
> >>>other into a "Factory" and adding a 'this' and a 'that' left, right
> >>>and center to the API.
> >>>
> >>>It seems to me that after the recent votes, we should take stock of
> >>>the situation, agree on what's next and *then* do the next thing.
> >>>
> >>>esjr
> >>>-----BEGIN PGP SIGNATURE-----
> >>>Version: GnuPG v2.0.22 (MingW32)
> >>>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>
> >>>iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
> >>>iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
> >>>vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
> >>>4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
> >>>+wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
> >>>byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
> >>>=Fsfe
> >>>-----END PGP SIGNATURE-----
> >>>
> >>
>
Re: OS detection
Posted by Reza <re...@yahoo.com.INVALID>.
I dont think that 1600x900 is supposed to be taken literally. Obviously you cannot detect the size of a browser window on the backend. That is basically meant to be a placeholder. If you are using backend device classification for the window size, simply put, you are doing frontend wrong.
Werner, what DeviceMap use case do you advocate? Or do you see no use for this project?
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Tuesday, July 29, 2014 9:34 PM
Subject: Re: OS detection
Simply assuming every desktopDevice must now have 1600x900 pixel is dangerous and does not add much value to layout or responsive design, etc.
I spoke to a friend from the PHP camp who was also in Nürnberg as speaker, and not only in this area he once again confirmed, a majority of users probably would not use any of these repositories, neither Open Source (like DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly in PHP. A vast majority of "end users" or web designers rely on a framework or content engine like Zend, Typo3, or WordPress and those engines have to provide some level of device regognition.
Similar for Java, the PoC (and if some of them work on the Apache site it is nice to test it against a variety of devices before thinking to use it) is OK as a demonstrator, but people would prefer to have the Spring Mobile, or the JSF library of their choice use it where necessary, or Portal servers like Liferay or Pluto.
Werner
On Wed, Jul 30, 2014 at 3:18 AM, Reza <re...@yahoo.com.invalid> wrote:
We can definitely extend our desktop detection to do OS detection too.
>
>So the reason that we have desktop detection is for backend responsive/adaptive web design. Desktop users have a mouse and a much larger viewing area. Phone users have a touch screen and a much smaller viewing area. That is an extremely important distinction to be made when you are serving a responsive/adaptive layout. So I would be careful when you say that desktopDevice is quite meaningless :)
>
>Sure, there are other use cases for DeviceMap where you want to know more specific information about a desktop. So maybe we should step back and better understand who are our potential users and how they plan on using DeviceMap? Are they doing responsive/adaptive web design? Web analytics? Something else?
>
>Just an FYI, I spend a *lot* of time working with frontends, responsive, and adaptive designs, so my opinion is always heavily steered towards this use case.
>
>
>________________________________
> From: Werner Keil <we...@gmail.com>
>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
>Sent: Tuesday, July 29, 2014 8:59 PM
>Subject: Re: Take stock
>
>
>
>Based on initial OpenDDR (desktopDevice is not new btw. only got a few extra properties or screen "assumption" changed from 800x600 to 1600x900, whether that makes sense is another question) experience told us, that e.g. Apple devices of all kind, including MacBook, etc. had a more descriptive recognition based on "genericApple".
>
>Hence it is dangerous and leads to missing even the most trivial information like the "Windows" string for the OS if the fallback is too generic.
>There is a "genericLG" which could under certain circumstances act as the most common fallback for an LG phone with Firefox OS, but now there is a generic OS root, too.
>
>W3C DDR and implementations like Open/DeviceMap DDR know at least 3 "aspects", if you want those are extensible, so having a fallback "hardware" or "OS" may conflict with each other, see the "desktop" which is quite meaningless and loses the information that this is a "Windows" desktop at the moment
>
>Werner
>
>
>
>
>On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com> wrote:
>
>Well there are 2 aspects, one API, the "new/alternate" client may evolve, and putting those things in JIRA is not wrong.
>>Whether the person responsible for a component (i.E. Reza for the Java client or yourself for .NET) just picks something or there is some sort of "voting process" (with a series of +1 or similar, see Eclipse, I also recall having heard about that somewhere here) that is probably worth considering.
>>
>>
>>Even though design patterns are applied in most modern languages, not everything might be applied exactly the same way on the .NET side, so if you don't see the need of a "factory" for something there, just leave it.
>>
>>
>>The data can use some care, not just for brand new platforms, and IMHO adding a reliable recognition of new families like Firefox OS, Blackberry 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a lot to do and no need to wait. We may rarely have JIRA tickets other than from actual committers now, but even on GitHub there are one or two ODDR either overlooked or did not consider a high priority including a fix for BlackBerry OS which we are probbly still missing in the current device-data.
>>
>>
>>I'm afraid, the "desktopDevice" doesn't add that much value right now, given I see:
>>model: browser
>>ajax_support_getelementbyid: true
>>marketing_name: -
>>displayWidth: 1600
>>id: desktopDevice
>>device_os: -
>>xhtml_format_as_attribute: false
>>is_crawler: false
>>dual_orientation: false
>>nokia_series: 0
>>device_os_version: -
>>nokia_edition: 0
>>vendor: desktop
>>mobile_browser_version: -
>>ajax_support_events: true
>>is_desktop: true
>>ajax_support_inner_html: true
>>image_inlining: false
>>mobile_browser: -
>>ajax_support_event_listener: true
>>ajax_manipulate_css: true
>>displayHeight: 900
>>is_tablet: false
>>inputDevices: -
>>ajax_support_javascript: true
>>is_wireless_device: false
>>ajax_manipulate_dom: true
>>xhtml_format_as_css_property: false
>>
>>
>>running the console demo or any comparable Java client app against a local Windows 7.
>>So "is_crawler" or even a new "pixel_density" which might be of relevance to Retina screens, could be a nice extra gimick but a default display of 1600x900 is meaningless for a desktop and http://www.useragentstring.com/index.php tells me this
>>
>>
>>Chrome 36.0.1985.125
>>Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent, which is only true for Gecko browsers like Firefox and Netscape. For all other user agents it means 'Mozilla-compatible'. In modern browsers, this is only used for historical reasons. It has no real meaning anymore
>>5.0 Mozilla version
>>Windows NT 6.1 Operating System:
>> Windows 7
>>WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a 64-bit processor
>>AppleWebKit The Web Kit provides a set of core classes to display web content in windows
>>537.36 Web Kit build
>>KHTML Open Source HTML layout engine developed by the KDE project
>>like Gecko like Gecko...
>>Chrome Name :
>>Chrome
>>36.0.1985.125 Chrome version
>>Safari Based on Safari
>>537.36
>>
>>
>>based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
>>
>>
>>So we are far from that I'm afraid,
>>Whether it's the hierarchy, that is rather likely something not only to be fixed or introduced for Firefox OS.
>>
>>
>>I added an initial "genericFirefoxOS", feel free to experiment with extensions to that. As of now I didn't add a child device that would detect say:
>>Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
>>
>>
>>
>>Werner
>>
>>
>>On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net> wrote:
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Hey guys,
>>>
>>>can you please "hold your horses" for a minute ?
>>>
>>>I think we all agree a review of the Vocabulary is in order -- for
>>>example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
>>>file and mentioning it in JIRA does not strike me as proper.
>>>
>>>And I think the same goes for 'quickly' turning this, that and the
>>>other into a "Factory" and adding a 'this' and a 'that' left, right
>>>and center to the API.
>>>
>>>It seems to me that after the recent votes, we should take stock of
>>>the situation, agree on what's next and *then* do the next thing.
>>>
>>>esjr
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v2.0.22 (MingW32)
>>>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>>iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
>>>iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
>>>vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
>>>4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
>>>+wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
>>>byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
>>>=Fsfe
>>>-----END PGP SIGNATURE-----
>>>
>>
Re: OS detection
Posted by Werner Keil <we...@gmail.com>.
Simply assuming every desktopDevice must now have 1600x900 pixel is
dangerous and does not add much value to layout or responsive design, etc.
I spoke to a friend from the PHP camp who was also in Nürnberg as speaker,
and not only in this area he once again confirmed, a majority of users
probably would not use any of these repositories, neither Open Source (like
DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly
in PHP. A vast majority of "end users" or web designers rely on a framework
or content engine like Zend, Typo3, or WordPress and those engines have to
provide some level of device regognition.
Similar for Java, the PoC (and if some of them work on the Apache site it
is nice to test it against a variety of devices before thinking to use it)
is OK as a demonstrator, but people would prefer to have the Spring Mobile,
or the JSF library of their choice use it where necessary, or Portal
servers like Liferay or Pluto.
Werner
On Wed, Jul 30, 2014 at 3:18 AM, Reza <re...@yahoo.com.invalid>
wrote:
> We can definitely extend our desktop detection to do OS detection too.
>
> So the reason that we have desktop detection is for backend
> responsive/adaptive web design. Desktop users have a mouse and a much
> larger viewing area. Phone users have a touch screen and a much smaller
> viewing area. That is an extremely important distinction to be made when
> you are serving a responsive/adaptive layout. So I would be careful when
> you say that desktopDevice is quite meaningless :)
>
> Sure, there are other use cases for DeviceMap where you want to know more
> specific information about a desktop. So maybe we should step back and
> better understand who are our potential users and how they plan on using
> DeviceMap? Are they doing responsive/adaptive web design? Web analytics?
> Something else?
>
> Just an FYI, I spend a *lot* of time working with frontends, responsive,
> and adaptive designs, so my opinion is always heavily steered towards this
> use case.
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Tuesday, July 29, 2014 8:59 PM
> Subject: Re: Take stock
>
>
>
> Based on initial OpenDDR (desktopDevice is not new btw. only got a few
> extra properties or screen "assumption" changed from 800x600 to 1600x900,
> whether that makes sense is another question) experience told us, that e.g.
> Apple devices of all kind, including MacBook, etc. had a more descriptive
> recognition based on "genericApple".
>
> Hence it is dangerous and leads to missing even the most trivial
> information like the "Windows" string for the OS if the fallback is too
> generic.
> There is a "genericLG" which could under certain circumstances act as the
> most common fallback for an LG phone with Firefox OS, but now there is a
> generic OS root, too.
>
> W3C DDR and implementations like Open/DeviceMap DDR know at least 3
> "aspects", if you want those are extensible, so having a fallback
> "hardware" or "OS" may conflict with each other, see the "desktop" which is
> quite meaningless and loses the information that this is a "Windows"
> desktop at the moment
>
> Werner
>
>
>
>
> On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> Well there are 2 aspects, one API, the "new/alternate" client may evolve,
> and putting those things in JIRA is not wrong.
> >Whether the person responsible for a component (i.E. Reza for the Java
> client or yourself for .NET) just picks something or there is some sort of
> "voting process" (with a series of +1 or similar, see Eclipse, I also
> recall having heard about that somewhere here) that is probably worth
> considering.
> >
> >
> >Even though design patterns are applied in most modern languages, not
> everything might be applied exactly the same way on the .NET side, so if
> you don't see the need of a "factory" for something there, just leave it.
> >
> >
> >The data can use some care, not just for brand new platforms, and IMHO
> adding a reliable recognition of new families like Firefox OS, Blackberry
> 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a
> lot to do and no need to wait. We may rarely have JIRA tickets other than
> from actual committers now, but even on GitHub there are one or two ODDR
> either overlooked or did not consider a high priority including a fix for
> BlackBerry OS which we are probbly still missing in the current device-data.
> >
> >
> >I'm afraid, the "desktopDevice" doesn't add that much value right now,
> given I see:
> >model: browser
> >ajax_support_getelementbyid: true
> >marketing_name: -
> >displayWidth: 1600
> >id: desktopDevice
> >device_os: -
> >xhtml_format_as_attribute: false
> >is_crawler: false
> >dual_orientation: false
> >nokia_series: 0
> >device_os_version: -
> >nokia_edition: 0
> >vendor: desktop
> >mobile_browser_version: -
> >ajax_support_events: true
> >is_desktop: true
> >ajax_support_inner_html: true
> >image_inlining: false
> >mobile_browser: -
> >ajax_support_event_listener: true
> >ajax_manipulate_css: true
> >displayHeight: 900
> >is_tablet: false
> >inputDevices: -
> >ajax_support_javascript: true
> >is_wireless_device: false
> >ajax_manipulate_dom: true
> >xhtml_format_as_css_property: false
> >
> >
> >running the console demo or any comparable Java client app against a
> local Windows 7.
> >So "is_crawler" or even a new "pixel_density" which might be of relevance
> to Retina screens, could be a nice extra gimick but a default display of
> 1600x900 is meaningless for a desktop and
> http://www.useragentstring.com/index.php tells me this
> >
> >
> >Chrome 36.0.1985.125
> >Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent,
> which is only true for Gecko browsers like Firefox and Netscape. For all
> other user agents it means 'Mozilla-compatible'. In modern browsers, this
> is only used for historical reasons. It has no real meaning anymore
> >5.0 Mozilla version
> >Windows NT 6.1 Operating System:
> > Windows 7
> >WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a
> 64-bit processor
> >AppleWebKit The Web Kit provides a set of core classes to display web
> content in windows
> >537.36 Web Kit build
> >KHTML Open Source HTML layout engine developed by the KDE project
> >like Gecko like Gecko...
> >Chrome Name :
> >Chrome
> >36.0.1985.125 Chrome version
> >Safari Based on Safari
> >537.36
> >
> >
> >based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
> >
> >
> >So we are far from that I'm afraid,
> >Whether it's the hierarchy, that is rather likely something not only to
> be fixed or introduced for Firefox OS.
> >
> >
> >I added an initial "genericFirefoxOS", feel free to experiment with
> extensions to that. As of now I didn't add a child device that would detect
> say:
> >Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
> >
> >
> >
> >Werner
> >
> >
> >On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <se...@ducis.net>
> wrote:
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Hey guys,
> >>
> >>can you please "hold your horses" for a minute ?
> >>
> >>I think we all agree a review of the Vocabulary is in order -- for
> >>example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
> >>file and mentioning it in JIRA does not strike me as proper.
> >>
> >>And I think the same goes for 'quickly' turning this, that and the
> >>other into a "Factory" and adding a 'this' and a 'that' left, right
> >>and center to the API.
> >>
> >>It seems to me that after the recent votes, we should take stock of
> >>the situation, agree on what's next and *then* do the next thing.
> >>
> >>esjr
> >>-----BEGIN PGP SIGNATURE-----
> >>Version: GnuPG v2.0.22 (MingW32)
> >>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>
> >>iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
> >>iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
> >>vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
> >>4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
> >>+wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
> >>byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
> >>=Fsfe
> >>-----END PGP SIGNATURE-----
> >>
> >