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 14:18:57 GMT
I've been working in standards bodies like the JCP for a  decade now,
elected to the EC for the 4th time in a row, so I deal with such standards
a bit.

These data files in their existing form are based on W3C standards (or
recommendations) just like HTML5.
And I guess you won't just leave the <html></html> tags from your site
either just because you may think it's redundant or "legacy"?;-)

So please respect the standards here if you want to be a constructive
member of the DeviceMap team.

Thanks,
Werner

On Fri, Jan 2, 2015 at 3:05 PM, Werner Keil <werner.keil@gmail.com> wrote:

> 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