3 ms·
Just a few thoughts: - Certainly easier to use than https://script.google.com https://script.google.com - How about a UI for inspecting the storage object? An
by aristidb 14y ago
Just a few thoughts:
- Certainly easier to use than https://script.google.com https://script.google.com
- How about a UI for inspecting the storage object? And why is "storage" _not_ JSON serializable?
- The whole thing gives the impression of "for disposable, not-very-important stuff". Is that deliberate?
- Specifying all the API keys and passwords for each call to an external service by hand seems a bit tedious. Automate all the things! (Maybe with a "secure" credentials object that can be filled with a separate UI?)
- Creating a new script under an existing domain deserves a dedicated UI element, it was not obvious to me that it is possible at all, at first.
- smarx 14y agoThere is actually UI for inspecting storage. As long as you have no more than 20 keys stored, it shows up on the left-hand side of the page, but you have to refresh the page to get the latest. My excuse for this not being discoverable and automatic: we just launched today. :-) I'd say we're generally for quick-and-dirty, not necessarily disposable or even not-very-important. But I may be splitting hairs here. We've been thinking a bit about a sort of global store for credentials. I'm curious to see what people end up doing with Webscript and how often they're typing the same credentials into multiple scripts. Thanks for pointing out the non-obviousness of creating new scripts in the same subdomain. We'll take a look.