Reza,
The "wall" projects like WURFL created against the community has clearly
worked against them. Especially for the data part the terms "1.0" vs. "2.0"
are artificial, everyone else just calls them XML or JSON;-)
It is up to you (and maybe few others) to focus entirely on a "2.0" client
or both, there are other issues like unbundeling the admin console from the
client which you (or Volkan who volunteered to help with it) may deal with
or not. Whether e.g. Eberhard may port the .NET client to use JSON data
whenever it exists is also to be seen.
I have other areas, e.g. Portlet support to look into since these standard
groups have interest to use DeviceMap, so I don't have to bother
"interrupting" whatever JSON format you may come up with. The first draft
with things like "pattern 1" or "pattern 2" sound purely acadamic, but take
your time and we'll see, what comes out of the JSON structure and when it
can be used. Data is as open and transparent as everything else at Apache.
So you're welcome to start with a completely empty JSON file and hope
enough people can fill that with both old and new device patterns. Or
someone takes the effort of transforming existing data from XML to JSON.
Should new patterns primarily be collected in the new JSON format, then the
other way round is just as eaysily to imagine. Customers of DeviceAtlas and
most other commercial vendors get these signatures in whatever format they
require, so while we must not copy their closed data, nobody will prevent
exchange between the 2 formats inside DeviceMap;-)
HTH,
Werner
On Mon, Jul 13, 2015 at 6:49 PM, Reza Naghibi <re...@apache.org> wrote:
> Werner, thanks for your comments of caution, but its not clear what you are
> trying to say.
>
> I would like to comment that you seem to be engaging and speaking to more
> and more of our 2.0 work. I just want to point out that this is against our
> previous agreement with Bertrand where we partitioned this project into
> different parts where we could work without interruption. 2.0 is one of
> these areas.
>
>
> On Mon, Jul 13, 2015 at 12:17 PM, Werner Keil <werner.k...@gmail.com>
> wrote:
>
> > Not sure about this particular case, but with the necessary caution other
> > similar cases were solved by "sub-classing" those attributes from a
> common
> > parent I recall.
> >
> > A general problem we simply further amended to is, "Device Data" contains
> > information that would belong to the existing browser or OS files.
> > Something that can be addressed with a JSON structures, but once that
> > target structure is in place and ready, we still need to transform
> existing
> > device data.
> > Nobody would want to start from zero by manually adding those Thousands
> of
> > devices already there.
> >
> >
> > On Mon, Jul 13, 2015 at 6:06 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> > > Looks like "HTC One X" and "HTC One X+" match the same since 1.0
> > normalizes
> > > out the regex. Otherwise, im guessing the + is an error because its
> > likely
> > > meant to be a literal \+ and not a regex. Since the patterns are
> > identical,
> > > the device choosen is the first one reached during iteration. The patch
> > > changes this because the data structure changes from a HashMap to a
> > > HashSet, so iteration order is different.
> > >
> > > I could add logic to the ranking function to fix this, but at this
> point
> > > there is no use. Getting matching to properly work on the ODDR data
> will
> > > never be perfect because the data has many errors like the one above.
> So
> > as
> > > always, the solution here is the fix the bad pattern.
> > >
> > > Also, some problems with your split() method. It shouldn't be static
> and
> > > you can remove the reference to Apache commons by using
> String.isEmpty().
> > > Not sure we need the null check, but null is allowed in normalize(), so
> > its
> > > best to err on the side of safety. Below is the corrected version:
> > >
> > > ---
> > >
> > > private List<String> split(String text) {
> > > List<String> nonemptyParts = new ArrayList<String>();
> > >
> > > String[] parts = TEXT_SPLIT_PATTERN.split(text);
> > >
> > > for (String part : parts) {
> > > String normalizedPart = Pattern.normalize(part);
> > >
> > > if (normalizedPart != null && !normalizedPart.isEmpty()) {
> > > nonemptyParts.add(normalizedPart);
> > > }
> > > }
> > >
> > > return nonemptyParts;
> > > }
> > >
> > > ---
> > >
> > > Also, the style of the 1.0 Java client is to be explicit with imports
> and
> > > not use the wildcard. Just a small style nitpick. So if you can correct
> > the
> > > above split() function (and fix the imports), your patch should be good
> > to
> > > go with the HTC One X tests removed.
> > >
> > > I will put this in the ticket.
> > >
> > > Thanks
> > >
> > >
> > > On Mon, Jul 13, 2015 at 10:53 AM, Reza Naghibi <r...@naghibi.com>
> wrote:
> > >
> > > > This sounds good. Why does the patch remove 2 user agents from the
> test
> > > > file?
> > > >
> > > > On Mon, Jul 13, 2015 at 6:06 AM, Volkan Yazıcı <
> > volkan.yaz...@gmail.com>
> > > > wrote:
> > > >
> > > > > Then if there are no objects, I will proceed patching 1.x this
> week.
> > > > >
> > > > > On Mon, Jul 13, 2015 at 11:59 AM, Werner Keil <
> werner.k...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > If it improves the performance, as Stefan mentioned, I see no
> > reason
> > > > why
> > > > > > you should wait.
> > > > > > 2.x is very likely to be much different, most importantly using
> > JSON,
> > > > so
> > > > > > the patch could not even match there as it does now;-)
> > > > > >
> > > > > > Cheers,
> > > > > > Werner
> > > > > >
> > > > > > On Mon, Jul 13, 2015 at 11:39 AM, Volkan Yazıcı <
> > > > volkan.yaz...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hello Reza,
> > > > > > >
> > > > > > > I was waiting for the 2.0 release of the client to commit those
> > > > > changes.
> > > > > > Do
> > > > > > > you want me to commit them to the 1.x branch?
> > > > > > >
> > > > > > > Best.
> > > > > > >
> > > > > > > On Fri, Jul 10, 2015 at 9:40 PM, Reza Naghibi <
> re...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > No reason. This patch was submitted by Volkan before he had
> > > commit
> > > > > > > rights,
> > > > > > > > so he posted it on JIRA. Volkan is now a committer and he is
> > > > allowed
> > > > > to
> > > > > > > > work on the 1.0 clients, so im pretty sure he is free to
> commit
> > > the
> > > > > > > patch.
> > > > > > > >
> > > > > > > > On Fri, Jul 10, 2015 at 3:15 PM, Stefan Seelmann <
> > > > > > > m...@stefan-seelmann.de>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I browsed through the devicemap-client Java code and saw
> some
> > > > > > > > > performance optimizations in DeviceMapClient.classify().
> > Then I
> > > > saw
> > > > > > > that
> > > > > > > > > there is already an issue and patch available since last
> > > > December.
> > > > > Is
> > > > > > > > > there a reason why it is not yet committed? The patch
> > currently
> > > > > has a
> > > > > > > > > compile error as commons-lang is not in dependencies but
> > that's
> > > > > easy
> > > > > > to
> > > > > > > > > fix.
> > > > > > > > >
> > > > > > > > > Kind Regards,
> > > > > > > > > Stefan
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/DMAP-107
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
