User questions on the new JSON format tiddler store in 5.2

[AnthonyMuscio]

Jeremy et al,

I trust that the changes proposed for 5.2 will go smoothly from a user perspective, because I do not (yet) have the skills to grasp the consequences. These questions relate to what the user will see (if anything). Unless there will be a need to change the way we "super users" included, make use of tiddlywiki, I am content with answers that state, it is a non-issue (without a need to explain why unless you feel like it).

Here, I am asking ONLY from the single file wiki perspective.

1. Could the old .tid files still be imported?
2. Can the old tid files still be exported?
3. Will tiddlers containing fields with the expanded naming survive import/export as .tid files?
4. As we can currently export one or more tiddlers as JSON files presently - Will the new JSON tiddler "format" be the same or similar, even with extended naming of fields?
5. I find csv files and JSON mangler very powerful, I use it to generate plugins containing tiddlers that represent each row as a shadow tiddler in a plugin - will this be affected?
6. In the Google Groups user forum, and Github discussions - users, super users and developers alike, like to share tiddlers when sharing methods and answering questions, can we have a easy to copy and paste version of tiddlers that are not JSON eg title, tags, text and fields, including the newly named ones?
7. Will or can the tiddler title naming convention be loosened? eg Warning: avoid using any of the characters | [ ] { } in tiddler titles.
8. Can any valid tiddler name be used as a name for a field? This has valuable design utility if yes. If not can we have a reversible slugify to do so?
9. Would this allow one wiki to open import or read the tiddlers of another wiki? (see below)
10. The announcement says storing JSON in <script> tags, are we confident script injection will not be possible?
11. Not withstanding Question 10 would this open the possibility of other desirable javascript being introduced by designers? There is such a large "script kiddy" resource out there this would be a helpful way to introduce other code without needing plugin authorship.

Advanced Question based on Question 9 above

I have being keen to have a wiki that can test if another wiki is checked out to someone, and only open the second wiki for edit if it is not. If one wiki (in the same folder) can read another and get a tiddler and alter its logic depending on the content of the returned tidder some great functionality could be developed. Basically using a Chain or network of single file wikis, perhaps to open a new one for each user, or the same one using a different url etc...

With tw-reciever we can give different wikis different save rights to the public.

I mention this now because it may be the opportunity during such an upgrade to introduce this feature.

In Closing
The freedom we gain in field naming may be a game changer, so I am excited about this change, but I ask these questions as a super user, not a developer because sometimes the line blurs. I worry that perhaps "informing developers" may not be comprehensive enough, as many of us hack tiddlywiki in many different ways (but are not developers).

Regards
Tony/Tones

[Jermolene]

1. Could the old .tid files still be imported?

Yes. The treatment of .tid files is not affected by this change.

2. Can the old tid files still be exported?

Yes. The treatment of .tid files is not affected by this change.

3. Will tiddlers containing fields with the expanded naming survive import/export as .tid files?

Yes. The treatment of .tid files is not affected by this change.

4. As we can currently export one or more tiddlers as JSON files presently - Will the new JSON tiddler "format" be the same or similar, even with extended naming of fields?

The new format is the same as the existing JSON export format expect that the character < must be escaped to \u003C. That change is required in order for the JSON data to be embedded in a script tag.

5. I find csv files and JSON mangler very powerful, I use it to generate plugins containing tiddlers that represent each row as a shadow tiddler in a plugin - will this be affected?

The treatment of CSV files is not affected by this change.

6. In the Google Groups user forum, and Github discussions - users, super users and developers alike, like to share tiddlers when sharing methods and answering questions, can we have a easy to copy and paste version of tiddlers that are not JSON eg title, tags, text and fields, including the newly named ones?

That might be an interesting idea but I don't think it's relevant to this change.

7. Will or can the tiddler title naming convention be loosened? eg Warning: avoid using any of the characters | [ ] { } in tiddler titles.

The treatment of tiddler titles is not affected by this change.

8. Can any valid tiddler name be used as a name for a field? This has valuable design utility if yes. If not can we have a reversible slugify to do so?

Yes, tiddler titles, field names and variable names are now all free format, and can store one another interchangeably.

[AnthonyMuscio]

Jeremy,

Thanks for the answers, as I expected a non-issue, but its nice to be reassured.

7. So to be clear, field-names (as for titles will) not allow "| [ ] { }"
8. I can see how using tiddler titles as field-names will be able to allow a reference to another tiddler, where the value of the field-name can describe the relationship.

• Such a field can also contain a list of tiddlers so the building sophisticated networks or database models will be easy. Very good.

Regards
Tones

[Jermolene]

Apologies, my finger slipped and I sent too early.

9. Would this allow one wiki to open import or read the tiddlers of another wiki? (see below)

No.

10. The announcement says storing JSON in <script> tags, are we confident script injection will not be possible?

<script> tags are only executed by the browser if they have the attribute type set to application/javascript, or if the type attribute is missing. Here we're using the type application/json which causes the script blocks to be ignored by the browser.

11. Not withstanding Question 10 would this open the possibility of other desirable javascript being introduced by designers? There is such a large "script kiddy" resource out there this would be a helpful way to introduce other code without needing plugin authorship.

No, this change doesn't affect the usage of JavaScript within wikitext. As an aside, I'm pretty sure I've already explained multiple times why it will never be possible to lift and shift arbitrary scripts off the internet and have them work in TiddlyWiki.

I have being keen to have a wiki that can test if another wiki is checked out to someone, and only open the second wiki for edit if it is not. If one wiki (in the same folder) can read another and get a tiddler and alter its logic depending on the content of the returned tidder some great functionality could be developed. Basically using a Chain or network of single file wikis, perhaps to open a new one for each user, or the same one using a different url etc...

That kind of thing is possible in some scenarios, but I don't think that it is anything to do with the change to the JSON store area.

The freedom we gain in field naming may be a game changer, so I am excited about this change, but I ask these questions as a super user, not a developer because sometimes the line blurs. I worry that perhaps "informing developers" may not be comprehensive enough, as many of us hack tiddlywiki in many different ways (but are not developers).

My comment was about "developers writing tools that produce or consume TiddlyWiki files", which is I think a small but very well defined group of people.

[AnthonyMuscio]

11. I was not necessarily talking about arbitrary scripts, only a subset, I understand the DOM issues (somewhat), but never mind.

Thanks Jeremy, the meaning of "developers writing tools that produce or consume TiddlyWiki files" can be a little less obvious to someone who does not do such a thing.

Thanks for the complete and comprehensive answer, I may quote it to other users prompted to ask similar questions.

Tony

[Jermolene]

Thanks @AnthonyMuscio, those are helpful questions and it's good to draw out the details in this way.