Tiddlywiki5: Sniff file ext to infer type for _canonical_uri tids

[twMat]

[ Replaces #1594 ]

Compared to most (even all?) other modern note-taking software, TW is severely limited when it comes to directly embedding images and media files. Therefore it makes sense to at least simplify the inclusion of external files. This proposal concerns the _canonical_uri technique.

Proposal
quote from @Jermolene

[...] sniffing any file extension from the URI to infer the type. I think that the way to tackle these cases is to provide more configurability for the import/drop functionality. It would be nice to set up a cascade of rules: for example, "If URI ends with .jpg then set type to image/jpeg" etc."

[pmario]

Compared to most (even all?) other modern note-taking software, TW is severely limited when it comes to directly embedding images and media files.

Hihi, ... Every modern note-taking software is limited in terms of embedding images and media files.

• Here is a complete list of media-types: https://www.iana.org/assignments/media-types/media-types.xhtml

• None of the following lists may be complete:

  • Here are some extensions and related Software: https://en.wikipedia.org/wiki/List_of_file_formats

  • A short reference of mime-types and related file extensions: https://www.thoughtco.com/file-extensions-and-mime-types-3469109

  • A different list of mime-types and related file extensions: https://wiki.selfhtml.org/wiki/MIME-Type/%C3%9Cbersicht

have fun!
mario

[twMat]

Hihi, ... Every modern note-taking software is limited in terms of embedding images and media files.

Of course, but I did say "compared to..." - i.e TW is more limited in this regard.

Good links! I think it would be enough to cover the most common formats and keep the option for manually typing the format name otherwise.

[tobibeer]

Thanks, @twMat, for creating this new issue.

I think sniffing would indeed be a great solution for dragging such target URLs both:

• onto the viewport, opening the import, suggesting to "import" / create a tiddler by the name of the file while embedding it appropriately in the tiddler text
• into an edit field to provide the appropriate embed code to create an embedding / link

...whereas the "representational" bit about each file would be configurable via templating, so it would have placeholders for variables extracted from the URL, e.g. id (youtube), url, domain, extension, filename, protocol or whatever is necessary to construct a desired url in an efficient manner.

So, it appears, the sniffing bit would require some JS modules that "probe" the url and fire a "found a match" alongside a resultset which then passed to the respective template.

@pmario: While I don't think that "link representation" is necessarily the way to move forward, I imagine that your uni-link somewhat does explorations in that direction, doesn't it?

[Jermolene]

I think that @twMat's proposal has a couple of parts:

• Enhancing the import mechanism so that dragged URLs automatically create tiddlers with _canonical_uri fields
• Setting the type of the created tiddler from any extension portion of the URL

The second part is quite easy; there is already a $tw.config.fileExtensionInfo hashmap that maps file extensions to content type. It's the first part that might be harder. Firstly, the action of dropping a URL is highly browser dependent, so will need some investigation to make sure we deal with them all. I recall that in some cases the URLs are delivered as files with a special MIME type, in which case we'd just need a deserializer mapped to that content type.