Thanks, I was also about to mention the update. As of now, I assume the version/last-updated should mirror that of OpenDDR while other "metadata" is of course different. Or does it make sense to maintain that differently, i.E. some Open Source projects with SVN repositories (I don't think Git has a full equivalent yet) use keyword expansion for such things as $Date$. If the date is supposed to be a (XML) date value, we may wanna keep it as per OpenDDR.
I understand not many of you except Bertrand/Adobe or Stefano are JCP Members, but allow me to remind those who are of the ongoing EC election. Stefano and I were the only Individual EC Members there, he chose not to run again, most likely he has too much to do, so I am the only Individual EC candidate with notable experience and background at JCP, here at Apache or Eclipse. If you care to vote and believe, some Individual members (also representing healthy and independent Open Source ecosystems, except for Eclipse there is also no candidate like Apache after it left the EC for reasons I don't have to reiterate) should still participate in the EC, please take that into consideration. The election ends next Monday. Werner On Thu, Oct 24, 2013 at 11:41 AM, eberhard speer jr. <[email protected]>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > bit late to the party -- busy finishing a web-log analyses tool -- but > here goes... > > Bertrand's tests > ================ > Reza pretty much covered every angle explaining the results Bertrand > got with his test. > > I would like to add : > > The test data contains a *lot* of user-agent strings of devices which > no longer occur in the OpenDdr resources. > Using 'my' cumulative resources significantly. > On the other hand for a large percentage of new devices in the OpenDdr > data we do not have a user-agent string in the test data. > Hence my plea for 'new' user-agents, to which we all saw the response... > > Release > ======= > Compared to all the 'others' DeviceMapClient is vastly superior : > - - it's *much* faster, > - - it doesn't require tons of code and hard-coded patterns so much > easier to maintain, > - - it has no dependencies so *much* easier to integrate...anywhere > So, I feel confident releasing it and take 'care' of the .Net version(s) . > But... > > Resources > ========= > "Aye, there's the rub..." > I'm totally with Reza on the n-gram vs pattern (regex) thing. > However, it will require : > - - either OpenDdr 'maintains' n-gram resources. The problem with that, > apart from finding them willing to do so, is that unless they maintain > both n-gram and patterns, the 'old' OpenDdr code will no longer work > - - or we maintain an n-gram version of the OpenDdr resources -- I don't > mind investing time and resources in this : setting up the infa to > deal with that and evolve to an automated system as proposed by Werner. > > Please all note that Werner updated the Resources to version 1.22 ! > > So, pending consensus : > - - I don't mind taking care of the .Net release > - - I don't mind taking care of the n-gram maintenance > > also : > - - I'll update the test data with user-agent string I 'harvested' > - - I think we need more 'new' user-agent strings and look into creating > 'specific' test data sets, something I'm also up for -- I've got some > experience in that area :-) > > So, with the resources updated, I think we're good to move ahead with > an initial release and tackling the n-gram issue. > > Nice ! > > esjr > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJSaOtbAAoJEOxywXcFLKYcI5MH/iH/tg9fHZGYiVer82i2NYXS > mgYK7Et62dUcchhmUHDtOQPf40wn/Td31AFyZRAxSt2xf2GwA77N/5hjIBOoVf1Y > MVYhUEzG6KKOUIyfW16Rl8HOgJy4/GSQy5V6gTGag8TXoHxU+fGHW0KqU78d/D4C > 72KjS3aXvXkRD+lVqA3SuQI8JR5URuQ43QMJY/mmdwEbfjg0dPCFjUxdOFXoo4KT > YnCjNroHIOAmSlC0+FsqMBgLfnSiOPr2XZg+ksytVvC/Idf/79XC/6lW7gf3mDF1 > /sk59DR5GNE8IE+VA6G8AZEp+5IN6uO8AjxooSNQ3/+lLntO7Urh5ZJzBmYwQiQ= > =PyBb > -----END PGP SIGNATURE----- >
