Treat tiddlers as base64 by default

[Jermolene]

Imported tiddlers with a MIME type that is not registered with the TW core are treated as text. It may be better to default to treating unknown types as binary, base64 tiddlers. That would mean that TW could be used to embed arbitrary unknown file types.

See the original discussion here:

https://groups.google.com/d/topic/tiddlywiki/XoyXlWO8SpA/discussion

[pmario]

As I wrote in the group. I'd vote for a zip / gzip only approach at the moment. Otherwise users will add multi megabyte files to TW and complain about the problems they get. especially with mobile devices.

[Jermolene]

@pmario what do you mean by "a zip/gzip only approach"?

This ticket is proposing a change to the interpretation of unknown content types. It wouldn't affect whether or not users would be able to add multi-megabyte files to TW.

[sukima]

I would agree, This could help with adding support files for documentation, Things like small word documents or zip files a reader might want to reference. As it stands those kinds of documents need to be stored by a CDN and linked to. Leaving them inaccessible for offline use.

Obviously this is a very specific use case and I would not recommend it's use for large files or in places where TW is used as a blog or something but it would be nice in small notebooks, local documentations or journals.

[tobibeer]

Sounds a more sensible approach than assuming text. Changing back to type text/plain format would be easy whereas the other way around would not be possible right now.

Would this introduce some generic base64 tiddler type? E,g, type: Binary / base64?

As for @pmario's comment, I don't see a requirement to force users into a compression requirement. Those knowledgeable about that will do it anyways, those who are not are still able to use things in perhaps less efficient ways.

[pmario]

This ticket is proposing a change to the interpretation of unknown content types. It wouldn't affect whether or not users would be able to add multi-megabyte files to TW.

I'd suggest, that the import dialog has a possibility to set the type to eg:"base64" but we stay with text as the default.

---

reasoning

IMO treating unknown content (file extension) by default as base64 is as wrong, as treating it as text.

TiddlyWiki primarily is a text based system. So one could think, that the main content that's imported, by the silent majority of users, is text. ...

The problem we are facing in the discussion is, that someone (may be the minority) wants to import big junks of binary content. .. It doesn't work so they start to complain, which is ok.

But imo the majority of users, that import "unknown" text don't complain because the default behaviour works for them. ... If we change the default, we may mess it up for them.

[tobibeer]

If we change the default, we may mess it up for them.

Makes sense. Perhaps a simplistic wizard on dnd import would be the best way to go giving a user a choice between an auto-identified format, i.e. some image type, or text, and well, base64. The crucial thing for this issue being the ability to change to base64 as needed.

[Jermolene]

The concern is that this change will break attempts to import text files whose type is not recognised. I think @pmario's logic is probably reasonable that defaulting to text is a better match for TiddlyWiki's textual orientation. We can continue to register the file type info for specific binary file types (as I've done for zip files).

It may also be possible to use heuristics to distinguish text vs. binary data during import.

[pmario]

The import dialog / table imo has enough space to add a drop down, that let's you select the import type. Using heuristics, is good to make a sensible suggestion, but the user may want to change the detected type.