You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by "eberhard speer jr." <se...@ducis.net> on 2014/07/30 01:59:56 UTC
Take stock
-----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: Take stock
Posted by Werner Keil <we...@gmail.com>.
That's not exactly true, especially for essential information like "vendor"
W3C Core Vocabulary took 2 aspects into consideration, OpenDDR added
precision:
<Property name="vendor" datatype="xs:string" aspects="*device, webBrowser,
operativeSystem*" defaultAspect="device"/>
And at least the BuilderDataPatch contains some weird hacks that make no
real sense, like
<builder class="org.apache.devicemap.simpleddr.builder.device.
*AndroidDeviceBuilder*">
<device id="desktopDevice">
<list>
* <value>macintosh</value>*
* <value>windows nt</value>*
<value>x11</value>
</list>
</device>
A patch that initial OpenDDR data used merely for specific Android devices
like the Kindle Fire.
While
<builder class="org.openddr.simpleapi.oddr.builder.device.SimpleDeviceBuilder">
<device id="desktopDevice">
was where desktop devices, even if just the browser matches got extra
recognition support.
Looking at the simple OpenDDR Filter, it shows pretty much the same results
for Windows right now as the Client does:
desktop resolution: 800 x 600
Only few attributes are actually used, but the ones that are show, that
windows is recognized as "desktopDevice", too.
Werner
On Wed, Jul 30, 2014 at 2:53 AM, Reza <re...@yahoo.com.invalid>
wrote:
> So its important not to confuse devices with browsers and operating
> systems. They are all separate entities and a User-Agent contains *ALL
> THREE*.
>
> Right now our device-data only has patterns to detect devices. ODDR never
> expended to include these other entities. So right now DeviceMap does not
> directly detect browsers or operating systems. OS is indirectly detected
> via a device attribute because phone operating systems are pretty static.
>
> In dclass, there is actually a different pattern set used to detect
> browsers and operating systems:
>
>
> https://github.com/TheWeatherChannel/dClass/blob/master/dtrees/browser.dtree
>
>
> So right now DeviceMap only detects desktopBrowser as a *generic device*.
> Its not as detailed as http://www.useragentstring.com/index.php because
> they are doing browser and OS detection.
>
> Long term, we should build out the data to detect browser and OS.
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Tuesday, July 29, 2014 8:43 PM
> Subject: Re: Take stock
>
>
> 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.125MozillaMozillaProductSlice. 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 anymore5.0Mozilla versionWindows NT 6.1Operating System:
> [image: icon] Windows 7
> <http://www.microsoft.com/windows/windows-7/>WOW64(Windows-On-Windows
> 64-bit) A 32-bit application is running on a 64-bit processorAppleWebKitThe
> Web Kit provides a set of core classes to display web content in windows
> 537.36Web Kit buildKHTMLOpen Source HTML layout engine developed by the KDE
> projectlike Geckolike Gecko...Chrome <http://www.google.com/chrome>Name :
> Chrome <http://www.google.com/chrome>36.0.1985.125Chrome
> <http://www.google.com/chrome> versionSafariBased on Safari537.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: Take stock
Posted by Reza <re...@yahoo.com.INVALID>.
So its important not to confuse devices with browsers and operating systems. They are all separate entities and a User-Agent contains *ALL THREE*.
Right now our device-data only has patterns to detect devices. ODDR never expended to include these other entities. So right now DeviceMap does not directly detect browsers or operating systems. OS is indirectly detected via a device attribute because phone operating systems are pretty static.
In dclass, there is actually a different pattern set used to detect browsers and operating systems:
https://github.com/TheWeatherChannel/dClass/blob/master/dtrees/browser.dtree
So right now DeviceMap only detects desktopBrowser as a *generic device*. Its not as detailed as http://www.useragentstring.com/index.php because they are doing browser and OS detection.
Long term, we should build out the data to detect browser and OS.
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Tuesday, July 29, 2014 8:43 PM
Subject: Re: Take stock
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.125MozillaMozillaProductSlice. 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 anymore5.0Mozilla versionWindows NT 6.1Operating System:
[image: icon] Windows 7
<http://www.microsoft.com/windows/windows-7/>WOW64(Windows-On-Windows
64-bit) A 32-bit application is running on a 64-bit processorAppleWebKitThe
Web Kit provides a set of core classes to display web content in windows
537.36Web Kit buildKHTMLOpen Source HTML layout engine developed by the KDE
projectlike Geckolike Gecko...Chrome <http://www.google.com/chrome>Name :
Chrome <http://www.google.com/chrome>36.0.1985.125Chrome
<http://www.google.com/chrome> versionSafariBased on Safari537.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-----
> >>
> >
Re: OS detection
Posted by Reza <re...@yahoo.com.INVALID>.
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: Take stock
Posted by Werner Keil <we...@gmail.com>.
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.125Mozilla 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 versionWindows NT 6.1 Operating System:
> [image: icon] Windows 7 <http://www.microsoft.com/windows/windows-7/>
> WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a
> 64-bit processor AppleWebKitThe Web Kit provides a set of core classes to
> display web content in windows 537.36Web Kit build KHTMLOpen Source HTML
> layout engine developed by the KDE project like Geckolike Gecko... Chrome
> <http://www.google.com/chrome>Name :
> Chrome <http://www.google.com/chrome> 36.0.1985.125 Chrome
> <http://www.google.com/chrome> version SafariBased 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: Take stock
Posted by Werner Keil <we...@gmail.com>.
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.125MozillaMozillaProductSlice. 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 anymore5.0Mozilla versionWindows NT 6.1Operating System:
[image: icon] Windows 7
<http://www.microsoft.com/windows/windows-7/>WOW64(Windows-On-Windows
64-bit) A 32-bit application is running on a 64-bit processorAppleWebKitThe
Web Kit provides a set of core classes to display web content in windows
537.36Web Kit buildKHTMLOpen Source HTML layout engine developed by the KDE
projectlike Geckolike Gecko...Chrome <http://www.google.com/chrome>Name :
Chrome <http://www.google.com/chrome>36.0.1985.125Chrome
<http://www.google.com/chrome> versionSafariBased on Safari537.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: builders and data
Posted by Werner Keil <we...@gmail.com>.
As SimpleDeviceBuilder is only used in the *Patch files right now, it
seemingly takes only these:
<builder class="org.apache.devicemap.simpleddr.builder.device.SimpleDeviceBuilder">
<device id="genericPhone">
<list>
<value>LG</value>
<value>NetFront</value>
<value>Palm</value>
<value>SAMSUNG-SGH</value>
<value>Up.Browser</value>
<value>Windows CE</value>
<value>Windows CE; IEMobile</value>
</list>
</device>
<device id="genericTouchPhone">
<list>
<value>android</value>
<value>blackberry</value>
</list>
</device>
<device id="desktopDevice">
<list>
<value>Mozilla/4.0</value>
<value>Mozilla/5.0 .compatible</value>
<value>Mozilla/5.0 .Windows</value>
<value>Mozilla/5.0 .Macintosh</value>
<value>Mozilla/5.0 .X11</value>
<value>Mozilla/5.0 .Ubuntu</value>
<value>Opera</value>
<value>Safari</value>
<value>Chrome</value>
<value>Konqueror</value>
</list>
</device>
</builder>
and a somewhat longer list in the BuilderDataSourcePatch.xml file also
under "Simple".
Above list like "android, blackberry" (that is not the only place, but one
especially if the parser looks at just a subset of the DDR definitions)
probably needs additional values, if FirefoxOS shall work, aside from a
"genericFirefoxOS" or similar root entry. Like in other cases, the top
level device classes may be OS independent, then we might do without a
"genericFirefox*" but need pointers to the new OS similar to Android or
Apple at the moment.
Of course "desktopDevice" may be anything from Windows to Apple/Mac or
ChromeOS (have we ever tested that btw, some vendors seem to sell it already
[?]) which in addition ot Android may at least appear on a tablet or similar
"factor" device, too (there are others, the UA site contains a limited
number of devices like "XBox", "PlayStation" or "Wii", one may call that
"genericConsole" and don't forget the "Wearable" trend, I saw thoug clunky
and ugly smart watches in Nürnberg with a real browser, too[?])
Werner
On Wed, Jul 30, 2014 at 4:12 PM, Reza <re...@yahoo.com.invalid>
wrote:
> >>Not sure, if we need to revert
>
> We are good on that. I double checked all the code, the classifying
> clients only look at TwoStepDeviceBuilder and SimpleDeviceBuilder and they
> ignore the package prefix.
>
> In 1.0.0, I added the more robust android, browser and crawler detection
> as a patch. I didnt want to cause too much disruption in the core data
> files on the first release, but I wanted the clients to have the enhanced
> functionality those patches bring.
>
> I made this ticket https://issues.apache.org/jira/browse/DMAP-57 to now
> move some of those definitions into core data for the next release. What I
> will likely do is define new builders (BrowserBuilder and CrawlerBuilder)
> so they shouldn't muck up legacy W3C clients. I will go ahead and break up
> the desktop browser into their respective operation systems where possible
> and I will also backfill the new attributes, is_desktop and is_crawler,
> into the vocabulary.
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Wednesday, July 30, 2014 10:03 AM
> Subject: Re: Take stock
>
>
>
> Not sure, if we need to revert it (at least for W3C builders a merge
> conflict that brought an older package name in was now addressed, the
> discussion happened largely in JIRA, but Reza also confirmed here it would
> not break his client) but a good way to use, extend and improve the design
> and specs by W3C DDR in the data files is something we'd want to improve.
>
> I.E. trying to add "features" via the main device data and "vocabulary"
> files rather than punctual tweaks via the Patch files, which are normally
> meant for 3rd party custom specific add-ons, e.g. if a particular
> application wants a fancy property like "has_augmented_reality" we may not
> currently support in the mainstream data
>
> Regarding APIs, it would not hurt if the "New Clients" where available for
> e.g. Java, C#, VB.NET or other languages let's say PHP or Python feel a
> bit similar, to the extent each language allows.
> Having central elements like "Device", "Parser", "Loader" etc. with
> similar names (if one calls it ILoader because of conventions, well, so be
> it) would create a familiar feeling among different libraries. I haven't
> looked much at the WURFL stuff, but its competitors with a longer
> commercial tradition and strong W3C DDR heritage like DeviceAtlas or
> DetectRight do this well for selected languages like Java, PHP, Perl or
> Python, C# or ASP.net.
>
> The IoT frency brings along many companies with open or closed business
> models. Xively as it currently calls itself has a REST/JSON/OAuth based API
> and language bindings:
> https://xively.com/dev/libraries/
>
>
> So within the needs and abilities of DeviceMap could a language specific
> set of examples or libraries also look like over time.
>
> Werner
>
>
> On Wed, Jul 30, 2014 at 9:01 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
> Hi,
> >
> >On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> wrote:
> >
> >> ...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...
> >
> >From the incubation mentor peanut gallery: it is good indeed to discuss
> >specific things (one per email thread ideally) before implementing them
> >when they have "big impact", whatever that means.
> >
> >And IMO discussing here is better than in jira issues, which are more
> >fragmented discussions.
> >
> >That being said, svn allows for reverting any commit, so it's often better
> >to ask for forgiveness than permission, for "small" things - assuming
> >people are willing and able to fully revert things when needed.
> >
> >-Bertrand
> >
Re: builders and data
Posted by Reza <re...@yahoo.com.INVALID>.
>>Not sure, if we need to revert
We are good on that. I double checked all the code, the classifying clients only look at TwoStepDeviceBuilder and SimpleDeviceBuilder and they ignore the package prefix.
In 1.0.0, I added the more robust android, browser and crawler detection as a patch. I didnt want to cause too much disruption in the core data files on the first release, but I wanted the clients to have the enhanced functionality those patches bring.
I made this ticket https://issues.apache.org/jira/browse/DMAP-57 to now move some of those definitions into core data for the next release. What I will likely do is define new builders (BrowserBuilder and CrawlerBuilder) so they shouldn't muck up legacy W3C clients. I will go ahead and break up the desktop browser into their respective operation systems where possible and I will also backfill the new attributes, is_desktop and is_crawler, into the vocabulary.
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Wednesday, July 30, 2014 10:03 AM
Subject: Re: Take stock
Not sure, if we need to revert it (at least for W3C builders a merge conflict that brought an older package name in was now addressed, the discussion happened largely in JIRA, but Reza also confirmed here it would not break his client) but a good way to use, extend and improve the design and specs by W3C DDR in the data files is something we'd want to improve.
I.E. trying to add "features" via the main device data and "vocabulary" files rather than punctual tweaks via the Patch files, which are normally meant for 3rd party custom specific add-ons, e.g. if a particular application wants a fancy property like "has_augmented_reality" we may not currently support in the mainstream data
Regarding APIs, it would not hurt if the "New Clients" where available for e.g. Java, C#, VB.NET or other languages let's say PHP or Python feel a bit similar, to the extent each language allows.
Having central elements like "Device", "Parser", "Loader" etc. with similar names (if one calls it ILoader because of conventions, well, so be it) would create a familiar feeling among different libraries. I haven't looked much at the WURFL stuff, but its competitors with a longer commercial tradition and strong W3C DDR heritage like DeviceAtlas or DetectRight do this well for selected languages like Java, PHP, Perl or Python, C# or ASP.net.
The IoT frency brings along many companies with open or closed business models. Xively as it currently calls itself has a REST/JSON/OAuth based API and language bindings:
https://xively.com/dev/libraries/
So within the needs and abilities of DeviceMap could a language specific set of examples or libraries also look like over time.
Werner
On Wed, Jul 30, 2014 at 9:01 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
Hi,
>
>On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> wrote:
>
>> ...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...
>
>From the incubation mentor peanut gallery: it is good indeed to discuss
>specific things (one per email thread ideally) before implementing them
>when they have "big impact", whatever that means.
>
>And IMO discussing here is better than in jira issues, which are more
>fragmented discussions.
>
>That being said, svn allows for reverting any commit, so it's often better
>to ask for forgiveness than permission, for "small" things - assuming
>people are willing and able to fully revert things when needed.
>
>-Bertrand
>
Re: Take stock
Posted by Werner Keil <we...@gmail.com>.
Not sure, if we need to revert it (at least for W3C builders a merge
conflict that brought an older package name in was now addressed, the
discussion happened largely in JIRA, but Reza also confirmed here it would
not break his client) but a good way to use, extend and improve the design
and specs by W3C DDR in the data files is something we'd want to improve.
I.E. trying to add "features" via the main device data and "vocabulary"
files rather than punctual tweaks via the Patch files, which are normally
meant for 3rd party custom specific add-ons, e.g. if a particular
application wants a fancy property like "has_augmented_reality" we may not
currently support in the mainstream data[?]
Regarding APIs, it would not hurt if the "New Clients" where available for
e.g. Java, C#, VB.NET or other languages let's say PHP or Python feel a bit
similar, to the extent each language allows.
Having central elements like "Device", "Parser", "Loader" etc. with similar
names (if one calls it ILoader because of conventions, well, so be it)
would create a familiar feeling among different libraries. I haven't looked
much at the WURFL stuff, but its competitors with a longer commercial
tradition and strong W3C DDR heritage like DeviceAtlas or DetectRight do
this well for selected languages like Java, PHP, Perl or Python, C# or
ASP.net.
The IoT frency brings along many companies with open or closed business
models. Xively as it currently calls itself has a REST/JSON/OAuth based API
and language bindings:
https://xively.com/dev/libraries/
So within the needs and abilities of DeviceMap could a language specific
set of examples or libraries also look like over time.
Werner
On Wed, Jul 30, 2014 at 9:01 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> wrote:
>
> > ...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...
>
> From the incubation mentor peanut gallery: it is good indeed to discuss
> specific things (one per email thread ideally) before implementing them
> when they have "big impact", whatever that means.
>
> And IMO discussing here is better than in jira issues, which are more
> fragmented discussions.
>
> That being said, svn allows for reverting any commit, so it's often better
> to ask for forgiveness than permission, for "small" things - assuming
> people are willing and able to fully revert things when needed.
>
> -Bertrand
>
Re: Take stock
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> wrote:
> ...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...
>From the incubation mentor peanut gallery: it is good indeed to discuss
specific things (one per email thread ideally) before implementing them
when they have "big impact", whatever that means.
And IMO discussing here is better than in jira issues, which are more
fragmented discussions.
That being said, svn allows for reverting any commit, so it's often better
to ask for forgiveness than permission, for "small" things - assuming
people are willing and able to fully revert things when needed.
-Bertrand
Re: Take stock
Posted by Reza <re...@yahoo.com.INVALID>.
Of course. Can you elaborate on your concerns and then we can discuss in more detail?
So... I added 2 new objects to the Java API: Device and DeviceMapFactory
http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier/src/main/java/org/apache/devicemap/DeviceMapFactory.java?view=markup
http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier/src/main/java/org/apache/devicemap/data/Device.java?view=markup
And I also converted the toString() output of the data objects to JSON.
As for the device-data, basically just moving patterns and definitions from the patch file to the regular files. Specifically, the generic fallback patterns. These patterns are key to plugging the holes 'generically' in our detection code.
Thoughts?
________________________________
From: eberhard speer jr. <se...@ducis.net>
To: "'devicemap-dev@incubator.apache.org'" <de...@incubator.apache.org>
Sent: Tuesday, July 29, 2014 7:59 PM
Subject: Take stock
-----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-----