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: Handling Bots and HTTP Clients
Date Tue, 09 Dec 2014 13:13:48 GMT
Would that be a separate XML file for bots?

Can you describe that a bit on the Wiki, we
And regarding working on it, I assume, you signed the contributor
agreement, did you?
Aside from JIRA filing (which pretty much everyone can do) even creating
XML files or executable code in SVN/Git/... requires a contributor.
Should we have missed you in http://devicemap.apache.org/team.html it's a
good opportunity to update that page, otherwise once the agreement is in
place;-)

Here's the Wiki http://wiki.apache.org/devicemap/, in theory if it does not
affect the 1.x Device DB something for bots might grow independently, but
it should be documented either in the 1.0.2 or 2.x Data Wiki.

Werner

On Tue, Dec 9, 2014 at 1:34 PM, Volkan YAZICI <volkan.yazici@gmail.com>
wrote:

> Hello,
>
> In the context of discussion "how do we handle HTTP clients", I would like
> to vote for treating them as bots. Further, I want to propose adding a thin
> layer above DeviceMapClient.classify() to make a shortcut for handling of
> the bots as follows.
>
> private final static Map<String, String> botAttributes =
> Collections.singletonMap("is_bot", "true");
>
> public Map<String, String> classify(String userAgent) {
>     if (isBot(userAgent)) return botAttributes;
> }
>
> The motivation for this change is as follows:
>
>    - Almost all of the attributes are making no sense for a bot and we are
>    losing time to match it against the whole DDR.
>    - Bot database will be able to evolve independently.
>    - We can come up with a single compiled j.u.regex.Pattern to check bots.
>    (I am pretty sure Reza knows a lot better performing approaches, but
> maybe
>    for a future release.)
>
> If the development team is ok with that, I want to implement this feature.
>
> Best.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message