At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit: 1. automatic build scripts: so developers can put their build scripts to public git. 2. Multilingual dictionary projects: so they can query zanata.
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
Any thoughts?
(2014年07月25日 17:04), Ding Yi Chen wrote:
At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit:
- automatic build scripts: so developers can put their build scripts to public git.
- Multilingual dictionary projects: so they can query zanata.
Thank you for the offer, Ding-Yi, To me, it looks attractive. Some time ago, I saw the post on this list asking Tx to allow anonymous users.
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
If this happens often, then the setting can be changed to 'not allow'. Is this too late? Or may be set 'not allow' during translation period only (aka, it starts string freeze date and ends translation deadline date), to avoid unexpected down on peak period? It sounds how does Zanata team manage the risk.
noriko
Any thoughts?
On Fri, Jul 25, 2014 at 12:34 PM, Ding Yi Chen dchen@redhat.com wrote:
At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit:
- automatic build scripts: so developers can put their build scripts to public git.
- Multilingual dictionary projects: so they can query zanata.
These look appealing.
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
What kind of usage would you want to track and which resources cannot be allocated?
On 2014-07-25 17:04, Ding Yi Chen wrote:
At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit:
- automatic build scripts: so developers can put their build scripts to public git.
- Multilingual dictionary projects: so they can query zanata.
Why can't they use API keys?
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
That's a big drawback. We don't want to open the server to denial of service attacks. Zanata's rate limiting is tied to API keys.
Any thoughts?
----- Original Message -----
On 2014-07-25 17:04, Ding Yi Chen wrote:
At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit:
- automatic build scripts: so developers can put their build scripts to
public git. 2. Multilingual dictionary projects: so they can query zanata.
Why can't they use API keys?
Short answer: Convenience, just like you don't need API or password to pull from GitHub, public website and anonymous FTP.
If FAS allows packages, projects or organizations to have their own account, they can surely create an account, then issue the API key with the package.
Use case: John heard about Fedora Zanata and since Fedora contains high quality translation, he wants to create dictionary App using Zanata as backend. So what API keys should he use? John is very unlikely to use his personal API key.
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
That's a big drawback. We don't want to open the server to denial of service attacks. Zanata's rate limiting is tied to API keys.
That's indeed the big concern.
Any way, I am Ok with both decision, as I do not intent to develop the dictionary project myself in foreseeable future.
-- Sean Flanigan
Senior Software Engineer Engineering - Internationalisation Red Hat
On 2014-07-28 14:21, Ding Yi Chen wrote:
----- Original Message -----
On 2014-07-25 17:04, Ding Yi Chen wrote:
At this stage, you need to register to be able to pull. In other words, you need to provide zanata APIKEY in order to pull or use FAS to login and download translation.
However, if allow anonymous to pull, it will benefit:
- automatic build scripts: so developers can put their build scripts to
public git. 2. Multilingual dictionary projects: so they can query zanata.
Why can't they use API keys?
Short answer: Convenience, just like you don't need API or password to pull from GitHub, public website and anonymous FTP.
API keys aren't required for plain git, but github does require authentication to use the github API (or else you are limited to 60 calls per hour, per IP). I don't think we could afford to be that generous to anonymous users though.
If FAS allows packages, projects or organizations to have their own account, they can surely create an account, then issue the API key with the package.
Use case: John heard about Fedora Zanata and since Fedora contains high quality translation, he wants to create dictionary App using Zanata as backend. So what API keys should he use? John is very unlikely to use his personal API key.
If it's a hosted webapp, why not use the developer's API key? If not, the app can ask the user for an API key.
Incidentally, in the case of github, you can create an API key for use in scripts, or else an app can use OAuth. (So instead of asking the user for a key, you can ask them to log in to github and store the token.)
Adding OAuth support to Zanata might make a good RFE.
Cons: We are not able to track the usage, therefore cannot allocate resource accordingly.
That's a big drawback. We don't want to open the server to denial of service attacks. Zanata's rate limiting is tied to API keys.
That's indeed the big concern.
Any way, I am Ok with both decision, as I do not intent to develop the dictionary project myself in foreseeable future.
-- Sean Flanigan
Senior Software Engineer Engineering - Internationalisation Red Hat
-
Ding Yi Chen -
Noriko Mizumoto -
sankarshan -
Sean Flanigan