Json in TiddlyWiki by standard

Developers
#26

1. Disadvantages of the pdf file

Although there are some note-worthy benefits of using PDF files, there are also some grave disadvantages of using this type of format.

  1. Cost of editing. Unfortunately - it’s not possible to directly edit your PDF file for free. You would need to use a platform such as Adobe Acrobat and other costly PDF editing softwares to acquire the “editing” function. This is a great disadvantage of the PDF as it doesn’t allow for corrections to be made easily.
  2. Layout. Although PDF files are ideal for printing - their pages are commonly in A3 or A4 format, making it hard to see each full page at a time. This results in a lot of scrolling and zooming in, which definitely dissatisfies “user-experience”.
  3. Basic. Despite the fact that PDF formats facilitate some interactive elements - let’s face it - it doesn’t engage readers as much as alternative formats due to its simplistic and rigid presentation. This can be seen as one of the disadvantages of the PDF file, making newer, more modern alternatives to PDFs more desirable!

2. Advantages of the opendocument file

image
image850×484 110 KB

3. Disadvantages of the web-bundle file

  1. Now that I’ve piqued your interest and sold you on Web Bundles, I need to mention a couple of limitations. As with any piece of technology, Web Bundles are better suited for some situations than others.
  2. Anything stored on servers won’t be encapsulated so this limits the functionality of what can be bundled. Web Bundles are especially effective for static websites such as many blogs, online portfolios and games. This is because they don’t require API calls to servers.
  3. Another issue is Web Bundles require user awareness. If your browser automatically cached the bundle of every site or web app you use, it would quickly fill your memory. The only feasible option is the user needs to know it’s an option to right-click and save their site of interest manually.

4. Advantages of the proposed file format “.tiddlywiki new format”

  1. There is no editing cost, you can edit in tiddlywiki-app itself or in the browser
  2. It is possible to have different types of layout
  3. There are several types of interactive element with tiddlywiki
  4. Supported by multiple applications
  5. Separation of content, presentation, logic, interface/interaction, data, metadata
  6. Mixed JSONSchemas/Markup: “UISchema”, “DataSchema”, “Editor-js”, “atjson”, “wikitext”
  7. “what is paid are plugins to change or added some functionality in .tiddlywiki documents” - this does not change your edition, it only changes its functioning, its visualization
  8. Expert and community technical support
  9. API calls to servers

5. References

#27
  1. This problem is solved, because part of the tiddlywiki information is sent to external and remote servers - as there are parts of the file that are synchronized, this prevents, for example, that a large file takes up a lot of memory or storage space. Other parts of the file are attached locally.
  2. Binary JSON format is a relatively small format and takes up less space than a PDF/Open Document/Web package. The idea of the tiddlywiki binary JSON format is to have some nice aspects of things in the PDF/Open Document/Web package - but without having a relatively high storage size.
  3. This happens because the plugins that need to be loaded are not packaged in the final file - there is a part of the json responsible for storing the corresponding plugin links that you purchased or had access to.
  4. As much of the data is plain text, there are no security/virus issues etc.
  5. The idea is to create text metadata to match the formatting
#31

but why?

  1. The collaborative economy is a worldwide trend, in which goods and services are acquired in a shared way instead of the traditional individual transaction. Its growth is mainly related to the appreciation of conscious capitalism and greater concern for the environment.
  2. Maybe we can have a collaborative economy, where everyone makes money either with tiddlywiki support through services, creation of themes/plugins etc - or by donating financially to the project - The idea I have with this file format would be the same with Xanadu, but different from some things - for example, I don’t think it’s feasible to have micropayments - my idea would be payments that can be monthly/annual depending on the plugin the person is using
#33

@anon5541130 , fellow @joshuafontany is very much into JSON for TW. Maybe he is up for discussing ideas and come with input.

1 Like
#34

It sounds like you want to use the TW Node.js server as a dev platform to generate OTHER static.html+css+javascript “web apps”/pages. Totally doable as is without adding any libraries. The relevant server commands would be “render tiddler” & each final-html-page’s transclusion-template would be as complex as the one that renders-a-tiddly-wiki-for-saving (i.e. it would place data in the head or body tags as appropriate).

Start learning about how TW does transclusion. Its a very different model than json+schema driven asset generation.

1 Like
#35

@joshuafontany

  1. My wish would be for tiddlywiki to be on any operating system (desktop/mobile) - my idea would be for tiddlywiki to be a modifiable, synchronous file format - so we wouldn’t need to have a desktop or server environment.
  2. My concept would be the ‘editable and shared file’ as I said before the idea of having a binary json would be for machines and not for humans - I mean in terms of code readability.
  3. What you said makes perfect sense to me… the only thing I don’t like about the idea is having a text file formatted - my idea is to have an inline markup such as a PDF file I mention would look like.
  4. It would be as if everything were one big transclusion/inclusion… in different ways from the perspective to the user.
  5. On this trip of mine… I’m talking about inspiration/design… I imagine the tiddly-wiki as an html/pdf file… that is… you can’t visualize the formatted data… given that it’s binary… . however, you can open this binary file in the browser and thus modify it
  6. What you said makes perfect sense to me… I say this when you speak at this point: ‘Its a very different model than json+schema driven asset generation.’
  7. The end file itself generates the output data as: ‘JSONSchema.metadata.layer.json’,
    ‘JSONSchema.application.logic.layer.json’,
    ‘JSONSchema.data.layer.json’,
    ‘JSONSchema.model.layer.json’,
    ‘JSONSchema.UISchema.layer.json’,
    ‘JSONSchema.index.layer.json’,
    ‘JSONSchema.settings.layer.json’,
  8. This data is used in case the user wants to store it in some database like couchdb/mongodb
  9. So, you can distribute your file in .tiddlywiki, because it is like pdf - it works in any browser/operating system and if you want to manage this file you can use some database like couchdb/mongodb etc - since every .tiddlywiki file pattern generates final files to be managed by the user in terms of storage/version control
  10. the difference between pdf and this file format i am proposing calling it tiddlywiki - is that it is based on json in different formats - another difference is that the data structure is similar to edl/atson/bson - another difference is that is an editable, shareable file format
  11. unlike the current format which is human readable, the file format I am writing conceptually here is binary
  12. is a file format that packages the necessary plugins for certain activities/tasks that the user would like or wants to do - when I say it is file format that packages the necessary plugins for certain activities/tasks that the user would like or wants to do - here I’m talking in terms of links, inside the .tiddlywiki file you direct or link the plugins you want to install or want - in fact this is done automatically from the user iterations with the .tiddlywiki
  13. depending on how the user interacts it produces new .tiddlywikis which by default connect to other tiddlywikis internally. This would be easily done if operating systems / mobile uses JSONSchema rendering as it does by default with PDF or HTML or PNG files. Any old or modern operating system mostly supports formats like PNG, JPEG, JPG, HTML, PDF, txt.
  14. my idea here is to have a modifiable, integrated, shareable, binary file format
#36

here I talk about the rendering and generation process of this file format

#37

This is based on this RFC: RFC 8089 - The "file" URI Scheme

“The “file” URI Scheme” → “The “tiddlywiki” URI Scheme”

sample 1

tiddlywiki://wiki.tiddlywiki "every .tiddlywiki you've written in the world"

sample-file 2: ‘wiki.tiddlywiki’

{
  "app": {
    "config": "./settings.json",
    "cwd": "./",
    "src": "example/content/",
    "filePattern": "**/*.md",
    "dist": "example/output.json",
    "name": "markdown-json",
    "version": "0.0.1"
  },
  "data": [
    {
      "section": "Elements",
      "title": "buttons",
      "device": [
        "desktop",
        "mobile"
      ],
      "styles": [
        "https://example.com/styles/structure.min.css",
        "https://example.com/styles/app.min.css"
      ],
      "contents": "116-126:a","reference:href", "link:"http://en.wikipedia.org/wiki/Ted_Nelson",  
      "id": "buttons",
      "meta": {
        "relativePath": "content/buttons.html",
        "createdAt": "2020-10-08T16:05:30.415Z",
        "lastModified": "2020-10-08T16:05:14.452Z",
        "size": 2095,
        "formattedSize": "2.0 KB"
      }
    },
  ]
}

references

#38

a real proof of concept

image

image description
  1. as we can see in this image we have a binary wiki.tiddlywiki file, all other files are inside wiki.tiddlywiki
  2. the browser can render as a folder system or as a tiddlywiki site
  3. wiki.tiddlywiki file is based on schemes like JSONScheme, BSON, atjson etc
  4. I would like to distribute tiddywiki through a p2p network that way I could have the content distributed to other computers, there are solutions like IPFS/Hypercore for that

references

#39

@anon5541130 its great to see you are enthusiastic about looking at tiddlywiki in another way. We are a community open to innovation, after all tiddlywiki includes many innovations.

I am not a developer myself but I have scanned this thread to try and see the difference between what we have in TiddlyWiki already and what is in your vision.

If I separate from your text the what “it enables” and “the way you suggest we may do it”, what I see is, it is enabling things that are already done by tiddlywiki or can be done with a few tweaks.

  • With this in mind I must ask how well do you already know TiddlyWiki?,
    • perhaps if it is a new discovery to you, we can address some of the outcomes you are seeking, based on the current architecture, before we need to consider a new architecture (most likely a fork), because backwards compatibility is important.
    • perhaps if you know tiddlywiki already and deeply then you could be be presenting your arguments, not so much afresh as a complete solution, but as relative to tiddlywiki as it is already, How is it different, what gaps are our trying to fill?

In addition to finding what are gaps you think your suggestions would fill, I would like to suggest tiddlywiki is already an effective “software development kit”, not only can you use it to make other tiddlywiki’s but you can

  1. use it to make many things from HTML websites, to data files, you can store tiddlers in many different data stores, with savers and sync adaptors, you can use it to create epub files, even prepare content and print to PDF, save to file. You can craft a template for example that generates the very format you seem to be suggesting.
  2. but the reverse is also true, it is possible to import almost anything and then parse this input into one or more tiddlers, CSV or JSON data or other formats. From this you can return to 1. above and make many things.

An argument I would make here, is if tiddlywiki could be used to make what you are proposing, why not use TiddlyWiki to make it?, rather that “remaking tiddlywiki to be what your proposal suggests it could be!”

You seem to have a lot of knowledge and many ideas, as I said we appreciate members of our community with such enthusiasm contributing. But like any community in which you may want to encourage change within, you need to put your case in ways many of us can comprehend. It starts with shorter more readable posts that engage people in a conversation rather than writing things perceived as “Too long”, thus “Did not read” TLDR;

  • Personally I think you can contribute a lot to what tiddlywiki can be but I think you need to start with some smaller targets and make sure you get input from the community first.

This is my personal view and I may have it all wrong.

1 Like
#40

My development process, let’s say, starts with these obstacles

  1. tiddlywiki storage space
  2. Tiddlywiki Version Control
  3. Data structure\format of tiddlywiki
  4. I am proposing a new file format called ‘tiddlywiki’ which is based on several known file schema types
  5. I would like to improve the look of tiddlywiki by defaulting to things like uikit/skeleton/boostrap etc
  6. furthermore, i am proposing and seeing i can contribute with a universal data sync plugin
  7. in all these proposals, i’m analyzing positive and negative feedbacks of these ideas before implementation - for now, what i’ve delivered is some concepts/documentation here
#45

What I’m talking about here briefly is a different, innovative file format. And that needs to be documented for IEFT so that any browser/browser has support for rendering. By default I adopt the RFC file protocol documentation for this - because conceptually what I want is something close to the file protocol with minor tweaks… for example, file protocol allows any file to be listed by the browser/file explorer - in my in case it won’t or can’t run - as .tiddlywiki is both a file format and a protocol for finding files.

#46

Imagine that you have an image file, there are 3 options: the first is to open it in the browser, another is to use the file explorer that your operating system has - another way is to use some program that reads and visualizes this file

#47

.tiddlywiki files are like images/pdfs - it doesn’t matter… they are binary files that can be viewed by browser, file explorer or specific programs

#48

The only difference is that they are editable, that is, it is possible to manipulate the contents of the file, a good example of this by commenting and reading the documentation would be about JSONSchema or atjson that does exactly what I need.

#49

Currently the tiddlywiki app is just a file format like HTML. my intention in this thread is to have a specific file format

#50

how would the tiddlywiki file format be rendered by the browser?

  1. so… the idea is that the browser has the 'tiddlywiki_render.js ’ library which is responsible for reading the file format and rendering it. ‘tiddlywiki_render.js’: contains the rendering engine only and updated links via json about the plugins you want to install - this can be done through an online api via restfull or cdn.js
  2. now for the interesting thing, the operating system has a file handler called tiddlywiki - which is responsible for internal linking different tiddlywiki
  3. in short we have the following programs: 1) tiddlywiki_render.js (responsible for rendering any tiddlywiki file) 2) file hander tiddly or tiddlywiki:///directory/wiki.tiddlywiki (responsible for viewing/directing/linking between different tiddlywiki data) 3 ) we have tiddlywiki file format
#51

how long have you been using tiddlywiki?
3/4 years.

2 Likes
#52
  1. I want to be a good person in this community and help as many people as I can
  2. I really like art/design - in this sense, the proposal of this file format is going, being gradually made
  3. But… it could be my mistake that I haven’t noticed, and i liked your sincerity, i think you’re right
#53

i think i wrote the main ideas and i want everyone here to give their opinion if these ideas are good or bad