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 <[email protected]>
To: [email protected]; Reza Naghibi <[email protected]>
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 <[email protected]>
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 <[email protected]>
To: [email protected]
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
