undefined | Better HN

0 pointsforgotmypw175y ago0 comments

Plaintext would not be 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.

0 comments

2 comments · 1 top-level

shadowgovt5y ago· 1 in thread

Plaintext is too complex for programmers and likely drops semantic information that is needed to reconstruct the relations in the original data.

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.

forgotmypw17OP5y ago

I don't agree at all.

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.

j / k navigate · click thread line to collapse