I had a dream to create a graph-visual phrasebook instead non-editable creature of google translate. I could re-connect associated words whereas in serial list you can think of related only words piled one on top of another. I first chosen Chrome as my browser because Firefox could not handle even the 1500 words in the google phrasebook -- how do you handle a graph?
I still did not select the front end -- which graph library to edit the graph in the browser, yet it makes sense to store the graph in the clouds. The first option is to use chrome.storage.sync. However, it is limited only to Chrome and, furthermore, it is available only for Chrome apps that you must publish somewhere. Otherwise, chrome.storate object is not available. Furthermore, it seems have limited storage (100 KB). This seems affordable for mine app (google translate is also limited to 1500 word pairs) but I could not understand if 100 KB is space available for every app or shared by all user apps. I could not check it because I could not run it. There are too many ways to start your app (background.js vs background.html vs content.js vs content.html and etc.) and none seems to allow the basic debug tools -- neither alert() nor console.log. Google Chrome App deny html-embedded javascript at all (for security reasons, of course). Why not to deny HTML altogether for the same reasons?
I then looked at Google Drive Realtime API and Storage API. They are not limited Chrome browser and to 100 KB storage. Yet, there is a limit for 10 mln requests/day (this seems to be the number of authorizations/day rather than real requests) instead (and you must additionally pay for Google Storage) and 10 MB per collaborative document.
Realtime API seems to be overkill since I am not going to share my graph with anybody for collaboration. Furthermore, Realtime API creates the database in a file of user Google Drive, which adds a level of complexity: you need to create the file in addition to simply logging in and you may mistakenly deltete it, loosing your dictionary, or confusingly create many backend files. Finally, Realtime API communicates to user Google Drive over the server-side app, that you must create in order your client-side javascript could access user's google drive. Invoking this nuisance is additionally quite involved in terms of javascript code.
Google Storage seems to eliminate all the overkill of Realtime API (no need for sharing and files) except the need for server client ID for user authentication. Additionally, I am not sure if user's storage is used instead off app storage in this case. Anyway, cloud storage sucks.
I still did not select the front end -- which graph library to edit the graph in the browser, yet it makes sense to store the graph in the clouds. The first option is to use chrome.storage.sync. However, it is limited only to Chrome and, furthermore, it is available only for Chrome apps that you must publish somewhere. Otherwise, chrome.storate object is not available. Furthermore, it seems have limited storage (100 KB). This seems affordable for mine app (google translate is also limited to 1500 word pairs) but I could not understand if 100 KB is space available for every app or shared by all user apps. I could not check it because I could not run it. There are too many ways to start your app (background.js vs background.html vs content.js vs content.html and etc.) and none seems to allow the basic debug tools -- neither alert() nor console.log. Google Chrome App deny html-embedded javascript at all (for security reasons, of course). Why not to deny HTML altogether for the same reasons?
I then looked at Google Drive Realtime API and Storage API. They are not limited Chrome browser and to 100 KB storage. Yet, there is a limit for 10 mln requests/day (this seems to be the number of authorizations/day rather than real requests) instead (and you must additionally pay for Google Storage) and 10 MB per collaborative document.
Realtime API seems to be overkill since I am not going to share my graph with anybody for collaboration. Furthermore, Realtime API creates the database in a file of user Google Drive, which adds a level of complexity: you need to create the file in addition to simply logging in and you may mistakenly deltete it, loosing your dictionary, or confusingly create many backend files. Finally, Realtime API communicates to user Google Drive over the server-side app, that you must create in order your client-side javascript could access user's google drive. Invoking this nuisance is additionally quite involved in terms of javascript code.
Google Storage seems to eliminate all the overkill of Realtime API (no need for sharing and files) except the need for server client ID for user authentication. Additionally, I am not sure if user's storage is used instead off app storage in this case. Anyway, cloud storage sucks.
No comments:
Post a Comment