Open jugglingcats opened 9 years ago
These are very important news also for me. If I don't get access for free to the UAS data updates in future anymore I cannot maintain this library efficiently. Furthermore the bundled database within the uadetector-resources
JAR will not be updated.
Alternatively we could maintain the database for our own. To be honest, I'm not interested in maintaining it for my own. I expect Pull Requests in future from all users of UADetector if we want to go in this direction.
Thank you for your feedback @jugglingcats.
Hi André thanks for quick response. I personally don't think it is feasible to maintain a database managed by users of UADetector. I think the way to go is to somehow make it easy for subscribers to udger.com to update their UADetector installs, using their own login for access to copyright info. Totally take your point about you needing access, although it looks like they have a free tier with demo data available you might be able to use. I guess we need to know more about how udger.com will manage access and whether the format of the data will stay the same!
I'm also fine if the examples are enough to maintain UADetector in future. In the past I found several issues by running integration tests regularly with the provided examples against the database.
I see that the requests of users to support specific clients and devices is always growing and hopefully the subscription model increases the quality and features.
Lets wait how udger.com is changing.
Hi. Notification of Changes is on the site for quite some time. Much more is a big part of the contents redirected to udger.com. André, I thought that you do not care. There is no problem for you to grant full access to udger.com. The original format of the data will continue to be supported for some time. Description of the new format is also not a problem to send. No need to wait how the situation turns out, just ask!
Hi Mallat, great that you responded to this thread so quickly - thanks. Seems like UADetector lib with updates can continue to function for the foreseeable future. Can you also confirm the licence position for users of udger.com data via the UADetector lib?
Hi. Sure, the license is for data. As the user processes the supplied data, depends on the user.
Sounds reasonable. Is it possible to contact you to discuss our use case?
Sure, jaroslavDOTmallatATgmailDOTcom
Hi @before
I'm interested in creation and maintenance of browscap.ini support. I'm aware that you've already took a look at it and you were not satisfied with it, but that's the best bet we can get from open source community and by providing unified Java library for it we will expand it's use and contributions to it.
What I want to know is if this library will stay alive for me to contribute to ? It came far away and I don't want all those people using it run away from it due to subscriptions or inability for auto-update.
Thanks in advance, Ahmed
Any news on this? If udger.com offers the datafile in a user-agent-string.info compatible format for registered users (in a free and paid version), isn't the change then just to replace the hardcoded download url with a user configurable url?
Update: So, a difference between full and light is also that you can't download an update of the light version with a library like this. Also the new lite version of the database does not use CC BY 3.0 any longer, so bundling as part of this library won't be possible.
@avila-devlogic yes, if you are interested I open the repository for you. Than you can develop directly in a topic branch and I would also contribute to this. I'm not very motivated to develop this for my own. Any contribution is welcome.
@HaraldWalker What do you suggest? Which database is out there that could bundled with our library?
For all customers of udger.com it would be nice to easily switch the url to the private udger url. This can easily be done with the current code. But parsing the XML file will fail because the path to the DTD was changed in the udger.com files. This leads to an exception in the class XmlDataHandler and the default DTD path cannot be (easily) overridden without duplicating a lot of code to instantiate our own version of the XmlDataHandler:
See:
protected static final String UASDATA_DEF_URL = "http://user-agent-string.info/rpc/uasxmldata.dtd";
net.sf.uadetector.internal.data.XmlDataHandler.resolveEntity(String, String)
We could open a pull request to allow overriding the DTD location which would make this great library usable again.
@tjacoby good job. I like your changes. Only the indentation is different to mine.
@tjacoby @before I'm struggling to figure out how to reconfigure uadetector to use the data from udger.com. Would someone mind helping me figure it out with some sample code?
@ESPNMichaelKidd There hasn't been a new release yet but if you don't mind building the jar yourself (and using a local maven repository), then you can use the commercial udger.com database. The UADetectorServiceFactory can now be initialized using your own data and version URLs (so you use the new udger.com link including the access key you get for a paid subscription).
@HaraldWalker many thanks, I see how it works now. @before any thoughts on cutting a release with these changes?
Hi, there is a message at http://user-agent-string.info saying:
That's in six days time. It doesn't look like the new site is ready for prime time yet though.
Am actually happy to help fund user-agent-string.info service and the published price seems reasonable. I just wonder if there is going to be any impact on uadetector as this is what we've integrated with and am very happy with it!