Given this is explicitly being launched under "Area 120", "Google's workshop for experimental products", I think it's fair to let them ship things, try things out, see what works, and close what doesn't.
Certainly not going to shift my team or multiple teams onto it if I can't trust it's going to be there tomorrow.
Users: Hey Google, please commit to supporting your new shiny product for the long-haul!
Stalemate. Google did this to themselves.
That's winning an early customer, that's proving product/market fit, that's progress. That's why Google would do this.
The marketing material pitches it as a much bigger deal, but then would anyone sign up if it didn't? There's a minimum quality bar that many people expect before signing up, and from a known entity like Google that's likely a much higher bar.
I almost wonder if they're making problems for themselves by naming it under the Google brand? Being completely separate they'd be able to fail faster, ship something lower quality that still proved product/market fit, etc. Area 120 seems to be their attempt to create this space, but I'm undecided on how well I think it will work.
Unless you're a Google competitor there's likely no reason to exclude Google products.
And it's somewhat in the same space as Tables.
Weird. Last I checked, even when deprecations happen, the data is accessible via Takeout.
These days exports are at least usable, so that you can hire a programmer to make something useful out of it, if you need.
I've already helped people make tools to create automated summaries for counting billable hours for language lessons taught over skype or messanger, which was only possible thanks to these exports finally being in some processable format, with enough metadata included.
It's not either or though. Services can export in both nice usable formats, and html garbage that is nice to look at but useless for anything else.
Even JSON is too complex for non-programmers.
Coupled with in-file tokens, it makes for an easy format to export into anything.
That's why I am using it as the base format for my forum application.
At any time, the entire forum content can be exported into plaintext, which is readable by most users on most platforms (except iOS)
And also can be re-imported into just about anything with a quick Perl script.
There's a reason plaintext is rarely used as the preferred method of semantic data exchange. What's our preferred method of representing images with plaintext? Audio files? Rich text, such as Google Docs? Spreadsheets (complete with formulae and attached macros)? Databases that contain bin-blob fields?
> And also can be re-imported into just about anything with a quick Perl script.
In your specific use case, I expect that works well. In the general case, my experience has been that plaintext can be imported into just about anything incorrectly with a quick Perl script. And when the data is MBs / GBs, the odds that such an error goes unnoticed until the data is needed and cannot be reconstituted are high.
For instance, consider email or newsgroups formats, with key-value attribute headers, with the difference of putting them at the bottom of the file.
With each "item" being a text file, you could easily fit the average person's Facebook profile into a zip file of (folder-arranged) text files with the content at the top and the extra attributes (e.g. timestamp, reply-to, etc.) below.
Even for someone very active, this would only be several hundred text files per day, so several hundred thousand per year, and several million for an entire profile. With that many, you'd probably have to split them up, but for the average person with maybe several hundred thousand, that's a manageable number of textfiles to put into a zip file.
These textfiles could be almost trivially imported into a relational database with a simple script.
At the same time, the user can also browse the contents of the zip file if the folder structure is arranged thoughtfully.
Of course, I am talking about text only, not images or videos. For these, you would have to either use metadata or have a matching text-file to go with the file.
(I'm not any kind of Google fanboy. Just bored of predictable takes like this.)
Sept 22, 2021.
Google Announces that Google Tables will be sunset and all users will have to migrate away by Sept 23, 2021.
"Google Tables was a great experiment but we're migrating to Google Tracker - a better version of Google Tables designed for power users." said Dep Re. Kated, VP of Engineering at Google.
Google Tables has no migration tool or system for users to export their data angering some users.
There's no support available for people wanting to get their data off the platform and many users are upset.
"There's no support number? I can't even pay if I wanted to!" said Alice Bob Carol, a huge fan of Google Tables that is upset it's going away.
When I tried to login it told me that "suspicious behavior was detected" and locked my account. Now I can't get access to my data and there's no one I can even contact!
(this was a parody but I'm calling it now - Google products are already dead when they're launched)