devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Improper "aliasing" of devices
Date Fri, 02 Jan 2015 21:11:12 GMT
For certain things like "parent devices" yes, but as I mentioned earlier
(and unlike the incomplete device entry "leaf" this doesn't cause a
mal-detection) the W3C DDR implementation is much more data-driven here
than Classfier having just a few patterns hard-coded in a single Java class.

BuilderDataSource has been full of device-specific regex patterns like
"[Bb]lack.?[Bb]erry" making it flexible to a wide range of matching User
Agents.
I could not find evidence any of that is used by Classifier, instead only
the class name of the branch is split into "simple" or "android", etc.
assuming these values are just keys for the other DeviceData source, which
is not entirely correct. The regEx and even concrete strings are matched
agains relevant sections of the UA, not the deviceId, which is why an exact
same pattern in the "Droid X 2" case may have got a vague result here, but
it didn't break anything and the duplicate was also around since 2012 as of
OpenDDR.

Werner

On Fri, Jan 2, 2015 at 4:05 PM, Reza Naghibi <reza.naghibi@yahoo.com.invalid
> wrote:

> Werner, one thing at a time. First, can you please demonstrate how the
> client is breaking when using an alias? Aliases, or parents, are used all
> over the DDR. Every single device has a parent up until you reach the root
> device. This has been the case since the first release of OpenDDR in 2011.
>
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
>  Sent: Friday, January 2, 2015 9:05 AM
>  Subject: Re: Improper "aliasing" of devices
>
> Reza,
> That ticket did not tell you to "break device-data" which that incomplete
> entry did.Everyone in the project (except you maybe;-/) agrees and
> understands the value of the BuilderDataSource and DeviceDataSource
> including the importance of classes in that file.
> You and everybody in the team are obliged to preserve consistency of the
> 1.x data branch with W3C DDR specs where all these files and their
> relations are defined by.The "duplicate" entry which caused the flaw in
> Classifier only under Java 8 was not a data problem, as there can be
> multiple <value> entries in BuilderDataSource e.g. <device
> id="HTC_Touch_Pro2">                <list>
> <value>HTC</value>                    <value>touch_pro2</value>
>     </list>            </device>
> And it's neither wrong nor illegitimate to have the same <value> in more
> than one builder entry. Making assumptions like a 1:1 relationship are
> short-sighted handling by th parser.If you can't handle or understand
> BuilderDataSource, please leave it alone and stick to DeviceDataSource, but
> there one must stick to the standard, too.
> In case you didn't notice, BuilderDataSource also contains Regular
> Expressions for some builders, not just simple device Ids. These are used
> for more precise detection by the builders, and if a variation in UA was as
> simple as "SGP312" vs. "SGP311" that's how W3C DDR deals with such cases,
> not by breaking the DeviceData file;-)
>  <device id="DROID X2" parentId="genericMotorola">            <property
> name="model" value="MB870"/>            <property name="marketing_name"
> value="DROID X2"/>            <property name="displayWidth" value="540"/>
>           <property name="displayHeight" value="960"/>            <property
> name="mobile_browser" value="Android Webkit"/>            <property
> name="inputDevices" value="touchscreen"/>            <property
> name="device_os" value="Android"/>            <property
> name="device_os_version" value="2.2"/>            <property
> name="dual_orientation" value="true"/>            <property
> name="ajax_support_javascript" value="true"/>            <property
> name="ajax_support_getelementbyid" value="true"/>            <property
> name="ajax_support_inner_html" value="true"/>            <property
> name="ajax_manipulate_dom" value="true"/>            <property
> name="ajax_manipulate_css" value="true"/>            <property
> name="ajax_support_events" value="true"/>            <property
> name="ajax_support_event_listener" value="true"/>            <property
> name="image_inlining" value="true"/>            <property name="from"
> value="oddr"/>        </device>
> and
>         <device id="MB870" parentId="genericMotorola">
> <property name="model" value="MB870"/>            <property
> name="marketing_name" value="DROID X2"/>            <property
> name="displayWidth" value="540"/>            <property name="displayHeight"
> value="960"/>            <property name="mobile_browser" value="Android
> Webkit"/>            <property name="mobile_browser_version" value="4.0"/>
>           <property name="device_os" value="Android"/>            <property
> name="device_os_version" value="2.2.2"/>            <property
> name="inputDevices" value="touchscreen"/>            <property
> name="dual_orientation" value="true"/>            <property
> name="ajax_support_javascript" value="true"/>            <property
> name="ajax_support_getelementbyid" value="true"/>            <property
> name="ajax_support_inner_html" value="true"/>            <property
> name="ajax_manipulate_dom" value="true"/>            <property
> name="ajax_manipulate_css" value="true"/>            <property
> name="ajax_support_events" value="true"/>            <property
> name="ajax_support_event_listener" value="true"/>            <property
> name="image_inlining" value="true"/>            <property name="from"
> value="oddr"/>        </device>
> As well  as Thousands of other device signatures in DeviceData show how
> this works, and trying to "shortcut" it with a crippled single line entry
> didn't.
> So if you want to do this properly, please create a proper entry
> for SGP312 like it's done for all the other device signatures or start with
>  "your own 2.x" structure without discussing requirements and do it there.
> Cheers,Werner
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
> Board Member, DWX '15 Twitter @wernerkeil | @UnitAPI | @JSR354 |
> @AgoravaProj | @DeviceMap | #EclipseUOMo | #DevOps Skype werner.keil |
> Google+ gplus.to/wernerkeil
>
>
> On Fri, Jan 2, 2015 at 7:22 AM, Reza Naghibi
> <reza.naghibi@yahoo.com.invalid> wrote:
>
> Werner, please undo this commit immediately:
>
>
> http://svn.apache.org/viewvc/devicemap/trunk/data/device-data/src/main/resources/devicedata/BuilderDataSource.xml?view=diff&r1=1648972&r2=1648973&pathrev=1648973
>
>
> You just undid this ticket:
>
> https://issues.apache.org/jira/browse/DMAP-86
>
> That ticket was a request from an important user, Infomaker Scandinavia AB.
>
> Secondly, I do not see the connection between that change and your claim
> that "aliasing" in device data is breaking the client. I am shocked that
> you are being so persistent with very little idea of what is going on.
> Quite literally, you are grasping at straws, only now you are committing
> code. This is a serious problem.
>
> I closed DMAP-119 and DMAP-120 because the unit tests fail when you link
> in device data 1.0.2. The unit tests were designed around 1.0.1. The above
> enhancement, DMAP-86, added new devices to 1.0.2. You then proceeded to
> test those devices against unit tests written against 1.0.1. So obviously
> they are going to fail. This has nothing to do with aliasing.
>
> Werner, this is your final warning. Please undo these changes immediately.
> Everything you have done and said tonite leads me to believe you are
> extremely confused regarding how the data and API work and what the goal of
> this project is. After you revert the changes you made to the data and API,
> you are not to commit anymore changes to trunk. Am I clear?
>
> No more arguments Werner. This is very serious. Please just do as I say
> and give it a break for a few days.
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org
>  Sent: Friday, January 2, 2015 12:48 AM
>  Subject: Improper "aliasing" of devices
>
> Reza/all,
>
> As of data 1.x the attempt of "aliasing" device data by trying to override
> a parent device with just a single incomplete line is not working and
> illegitimate.
>
> It breaks both clients.
>
> If such "simplified" device data modeling was desired, it has to be done
> for 2.x, as it breaks compatibility with the 1.x and W3C data model.
>
> After elliminating the wrong/incomplete line for "SGP312" remaining SGP311
> is properly recognized.
>
> Based on Data 1.0.1 it seems the 2 new/wrong entries are ignored, in fact
> if below issue
>
> Tests run: 1176, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.67 sec
> <<< FAILURE! - in org.apache.devicemap.DeviceMapClientTest
> testDeviceMapClient[1174](org.apache.devicemap.DeviceMapClientTest)  Time
> elapsed: 0 sec  <<< FAILURE!
> org.junit.ComparisonFailure: classification failed for 'Mozilla/5.0 (Linux;
> Android 4.3; SGP311 Build/10.4.B.0.577) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/38.0.2125.102 Safari/537.36' *expected:<[genericAndroid]> but
> was:<[SGP311]>*
> at org.junit.Assert.assertEquals(Assert.java:115)
> at
>
> org.apache.devicemap.DeviceMapClientTest.testDeviceMapClient(DeviceMapClientTest.java:74)
>
> is addressed using data 1.0.2-SNAPSHOT with the correct test data file for
> SGP311, the extra line SGP312 in the test file is safely ignored.
>
> Please if needed add a complete record,
>
> This fixes both https://issues.apache.org/jira/browse/DMAP-120 and
> https://issues.apache.org/jira/browse/DMAP-121 you bluntly and prematurely
> brushed away.
>
> Thanks,
> Werner
>
>
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message