devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <reza.nagh...@yahoo.com.INVALID>
Subject Re: Improper "aliasing" of devices
Date Fri, 02 Jan 2015 21:46:19 GMT
Can you demonstrate this:

>> Sure, it broke detection and resulted in a "null" device before the incomplete "alias"
was put into DeviceData incorrectly.

My understanding was that nothing was broken. As I pointed out before, you incorrectly ran
the unit tests created for 1.0.1 against a 1.0.2 snapshot. Thats it. Since the 1.1.0 client
was just released and 1.0.2 data is next, I will be updating the 1.1.0 unit tests to work
against 1.0.2 and eventually 1.0.3. It has to be done this way because we need reproducible
tests, ie tests need to be pinned to data versions, and we cannot release software with snapshot
dependencies. So if someone downloads the 1.1.0 data release, it will run tests against 1.0.1,
validating the release as we released it. Make sense?

---

      From: Werner Keil <werner.keil@gmail.com>
 To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com> 
 Sent: Friday, January 2, 2015 4:38 PM
 Subject: Re: Improper "aliasing" of devices
   
Sure, it broke detection and resulted in a "null" device before the incomplete "alias" was
put into DeviceData incorrectly.
After the fix both SGP311 and SGP312 (or future UA variations like SGP313) UA are properly
detected. Before neither the valid SGP311 nor the incomplete SGP312 were recognized. Sorry
but since BuilderData source contains important patterns for thousands of devices the classifier
has to stick to the correct format of these files as with all the other entries.
Should you have  a completely separate specs for SGP312 other than     <device id="SGP311"
parentId="genericSonyEricsson">            <property name="model" value="SGP311"/> 
          <property name="marketing_name" value="Xperia Tablet Z"/>       
    <property name="displayWidth" value="1200"/>            <property name="displayHeight"
value="1920"/>            <property name="mobile_browser" value="Android Webkit"/> 
          <property name="device_os" value="Android"/>            <property
name="device_os_version" value="4.1.2"/>            <property name="dual_orientation"
value="true"/>            <property name="inputDevices" value="touchscreen"/> 
          <property name="is_tablet" 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="devicemap"/>        </device>
please feel free to add a second independent <device> entry.
DeviceData is full of Thousands of these, see various Droid XYZ, etc.If parent was legitimate
for all those it would have been done, but it isn't.
Use             <device id="SGP311">                <list>   
                <value>SGP31\d</value>                </list>
or something like            <device id="SGP311">                <list> 
                  <value>SGP311</value>                   
<value>SGP312</value>
                </list>in BuilderDataSource for model aliasing.
Thanks,Werner


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

So you cannot demonstrate the client breaking on the parent. Can you please revert you commits
and restore the changes requested by Infomaker Scandinavia AB on DMAP-86 [0]?

[0] https://issues.apache.org/jira/browse/DMAP-86

---

      From: Werner Keil <werner.keil@gmail.com>
 To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
 Sent: Friday, January 2, 2015 4:11 PM
 Subject: Re: Improper "aliasing" of devices

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