@AlfieA it seems to me the first step is to allow an .ics file to be imported by choosing a tiddler title, perhaps based on the filename and feeding all the provided data into fields. Now a designer / user has access to the ics and can write solutions to use them. If these are modified it would be helpful to be able to export an ics file as well.
- Once we have an ics file tiddler, people can write there solutions to also interpret ics tiddlers, write and provide a view template and even an editor for such tiddlers.
- The same mechanisium can then be used to import/view/edit/export other “found” filetypes and we build tiddlywikis ability to handle such imports nativly. By setting the tiddler format it is easier to write additional file handlers based on existing ones, and write solutions that leverage each file format.
- Qnce used and established we can consider moving the the support into plugins and/or the core.
The above approach allows step by step development of facilities to handle a myriad of common files found in the wild. Rather than make it one big project we can build a powerful resource piece by piece, and it is more likely to happen.
For Example;
Drop an ics file on tiddlywiki.com its imported and given the title of filename, has the type set to text/calendar and the content placed in the text field.
It is now possible to build;
- a viewer for text/calendar items
- a converter to parse and store in fieldnames
- an exporter of ics files
You can see in this example if we had a way to interogate the text field of a text/calendar to get fieldnames and fieldname values we could use this to;
- Obtain the fields and values
- Move into fieldnames with any fieldname disabiguations
- Apply this according to documented standards of ics files
- Use the same process to include support for additional and similar file formats.
Now we can get somewhat meta about this;
Build a tool to allow someone to import a representative file into a tiddler, then build on all the different components to support a given filetype;
- Custom importer/exporter
- View and edit templates
- Export the resulting tiddlers as a tool for a give filetype
This would allow anyone comming accross an, as yet, unsupported filetype to build support for that file type then share with the community.
Why wouyld we move content into fieldnames?
Because fields already have a suite of tools to access, view and edit them independantly rather than reading from and writting to somewhere in the text field.
- But when you export such a tiddler a “synthetic” text field can be generated from the fieldnames to export as a “flat file”.
- More expierenced users like myself are used to itterating all non standard fieldnames and their values from a tiddler, be it as found or from a defined set of fieldnames.
note:
I think the tiddler may be imported with the filename but this should also be stored in a filename field, and allow the tiddler to be given a user friendly event name.
