kittey said:
So you’re using our tagging efforts and Danbooru’s bandwidth for your application and ask for donations (on your Facebook site) and possibly want to promote a pay-to-use full version later? Why would we want that? There’s nothing in it for us.
Also, I believe you’re infringing on Newtonsoft and zzzproject’s copyrights by not following the conditions listed in the licenses for the Json library and the Html Agility Pack.
[Note to any mod: I don’t mind you deleting my post if you want to delete this thread.]
Regarding external libraries
Newtonsoft.Json Library's License
HTML Agility Pack Librery's License
License's explanation: http://i.imgur.com/48EC5Ir.png
Both library's are free to use in any case for any purpose.
Regarding Danbooru's API
Danbooru offers a REST-like API to make scripting easy. All you need is a way to GET, POST, PUT and DELETE to URLs. Responses are given in either XML or JSON format.
HTTP defines four basic request methods: GET, POST, PUT and DELETE. You'll be using these methods to interact with the Danbooru API. Most API calls that change the state of the database (like creating, updating, or deleting something) require an HTTP POST, PUT or DELETE call. API calls that only retrieve data can typically be done with an HTTP GET call.
A URL is considered a resource and the HTTP methods are actions you perform on the resource. For example, GET /posts/1.json returns a JSON representation of a post. GET /posts/1.xml returns an XML representation. POST /posts/1.json would update the resource, for example changing its tags.
Some new rules about how the API is rate limited went into effect today.
The gist is this: reads are no longer rate limited. Some updates are rate limited. This means simply using the site you shouldn't run into these limits, but if you were heavily updating pools, posts, wiki pages, etc you may run into them. Notable exceptions (currently) for rate limiting including voting and favoriting.
The rate limiting rules, in general, is as follows:
Basic users: 1 update/second
Gold users w/API key: 2 updates/second
Platinum/Builder/Mod w/API key: 4 updates/second
In addition, users have a burst pool where they can make several consecutive updates without being rate limited. This is again dependent on user level:
Basic users: 10 updates at once
Gold users w/API key: 30 updates at once
Platinum/Builder/Mod w/API key: 60 updates at once
This pool is slowly regenerated according to the rate limiting rules mentioned above.
The Danbooru API is free to the public and danbooru itself (https://github.com/r888888888/danbooru) is actually open-source on github. So that means anyone at anytime can make a call. The reason why it has an API it's because it's accessible to anybody who wants to have access to that information.
I can't really say it's "abusing" danbooru's bandwidth, as I am sure you haven't noticed. My application downloads two images at a time (Careful if it's not only one) in order to avoid exactly that. While there are really no limits to the "GET" method. I was very careful when programming this feature.
My application cannot really kill danbooru or abuse of its bandwidth, because the only thing it does is download images and get JSON strings, all the other work is done by me.
People that frequent Danbooru are the same people that always visit the site. So why would that be a negative impact? Think about it. This will actually get more people to it, since Downlooru allows you to go to an specific post.
I'm just adding more to all the other applications on this site (which I think you have not noticed) in which the user can actually browse and download from Danbooru without opening many tabs and by doing so, making the memory usage fly up to the sky.
I'm sorry if it pains the fact that I'm "using your tagging efforts". But all of those "tagging efforts" are what is saved to the server AND theen get by the API. So, if the API allows it, why should it be wrong?
I do understand your frustration. But I very well thought all of this before releasing my application, in fact, I took at least 3 months to do so, because I was preparing myself for any legal issues and any other issue that Downlooru was actually having with the Danbooru server or any of it's external libraries that are free, which I stated previously.
I want to make clear that I never took credit for any of the external libraries and that my application is in no way gulping down any bandwidth more than what an usual user would do.
