maphew

Topics are Folders

Topics are Folders?

Saturday, February 24, 2018

10:40 AM

https://groups.google.com/d/msg/leo-editor/NEls7w7Jzxw/kbm-QYGzCwAJ

 

After a while I thought that easiest way to connect the two is implementing some kind of special file system. In this (let's call it LeoFS), filenames are gnxes and file content is the body or maybe (headline + '\n' + body). All these editors have some kind of tree representation of the file system which can be enhanced to draw Leo icons and headlines instead of filenames.

 

A long time ago, before I ever considered learning how to script or program, I was intensely involved and enthused with Wiki's in general and TWiki in particular. One of the problems inherent in text-based wiki's, 99% of them, is how to reference and store media such as pictures, sound, videos, pdfs, .... For the most part all of the wiki engines solve the reference part more or less succinctly and sometimes elegantly. Unfortunately the accessories storage part is shoved to the side -- usually one big heap with some kind of human illegible machine generated index. (This isn't unique to wiki's. This same flat 'media ghetto' solution is used by almost every content management system I've had occasion to use.)

 

My conceptual solution to this was/is "What If Topics Were Folders?", topics being the twiki version of Nodes. Basically: every topic is a container, within the container if the default file exists, display that using the filetype's default rendering mechanism (think web servers and index.html). Media files could be "attached" simply by storing in the same container and then referenced with a link from the default file. Any topic can contain other topics, and thus media files, recursively. A text file would be the global default rendering file, but that could be changed for a local topic/branch to use video or audio or graph instead.

 

All this is just a really long way of saying: I agree with you. Filesystems are a smashing great idea. Nodes are a smashing great idea. Putting them together would be awesome.

 

─────────────────────────────────────────────────────────────────────────────────────────
 

Think of it this way, editors are built to work on files, well let Leo be the file system!  All you need is a tree-like browser in your editor to get at the "files", ie Leo's nodes.

Emacs, Vim, VScode all have tree-like file browsers, they just need to be "re-plumbed" to get Leo to open the selected node as if it were a file, (then save any edits back to Leo).

 

From <https://groups.google.com/forum/#!topic/leo-editor/jwhrq-ot9SA>

 

 

Much later email conversation with Daniel Beardsmore, not related to Leo

 

I am not averse to CMS software. My aversions to WordPress are that it’s a bloated, slow, incapable mess that tends to produce unstructured sites that are hard to navigate, which usually offer visitors no means of direct contact. We had a site at work designed in WordPress where each page had a gruesome mess of HTML and CSS repeated on every page. I really don’t know whether the designer was a moron or WordPress’s template facilities are that useless. I only know that no sane person would repeat so much HTML on each page, as it is an editing nightmare.

 

I have a vision for a really interesting CMS, but I’ve never met a single person alive who understands it, no matter how simple it is. (It’s not complicated; I just never encounter any properly technical folk in life.) Where it gets more complicated is when you want to make a wiki for a subject that demands a lot of object-orientated data storage and presentation. In my case that is computer keyboards, but it also applies to cars, trains, planes, anything where want to enumerate items based on specific axes (e.g. show all fighter aircraft ordered by combat range, greatest to least). These are subjects where there are large numbers of numeric-based objects. For keyboard switches, it’s figures like preload, actuation force, tactile force, peak force, terminal force, pretravel, total travel, hysteresis, rated lifetime etc. For aircraft, it might be not-exceed speed, cruise speed, service ceiling, etc. In both cases, there are going to be subtypes that need to be classed together as one page, but each have property overrides, which gets awkward for wiki presentation with infoboxes.

 

The end desire becomes a hybrid of an object store for the individual records (manufacturer, product range, product, sub-type, component etc) and a high-grade wiki such as MediaWiki for the article text of each record and for general non-specific articles, such as how aerofoils work, how flaps work, how keyboards sense keystrokes etc. Records need to embed wiki text (for the write-up on that product/model/type/subtype) and both the product write-ups and general articles need data mining access, for showing lists of available products (all products by the manufacturer, all subtypes etc), as well as articles that collate facts, such as a table of all keyboard switches showing their durability: rated lifetime, resistance from new, resistance at end of life, bounce time from new, bounce time at end of life … (in my case I have to build this by hand, which means that my list so far is very small; with a product-based wiki this table would build itself: http://telcontar.net/KBK/tech/specifications.php)

 

This is way beyond what a wiki is; it’s a wiki inside out. Instead of constructing this data manually in MediaWiki and hand-rolling the tables or using messy hacks like Semantic MediaWiki (no use since most people in the keyboard community pretend to be incapable of editing a wiki at all), instead you have a nice object store for recording data, and the wiki facility runs the text aspects of it. (It does raise the question of whether the object data should be versioned the same as the wiki text.)

 

One day I will find someone who understands any of that; so far, no-one ever has. Although I could build something like that, I dread to think how it would end up. It would take a long time and it would not be pretty. For now, it’s plain old HTML for me …

 

From <https://mail.google.com/mail/u/0/#search/resident%40telcontar.net/FMfcgxwDrHlsdswSfbxVnZWfBhpdsHJC>

 

So far, I have used pmWiki, Twiki and MediaWiki (and whatever Geekhack had originally). pmWiki did not (and may still not) handle media. MediaWiki is the only one that I have used in a long time.

 

MediaWiki is where I started to really encounter data model problems. Images on MediaWiki are versioned, but the images and descriptions are versioned separately, and there is no support for image metadata fields, such as licence, description, author etc (especially troublesome where you want to mandate that these be entered, since you cannot). It is not possible to apply a change to the description and the image simultaneously, such as amending the description and date at the same time as the new image version is added. This means that there is no method of tying together any revision of the metadata with any revision of the image. Wikipedia’s own image pages are pretty chaotic, indicating that nobody has a clue how to handle images properly.

 

It gets worse, because it is possible to rename the image itself without renaming the File: page that contains it, or vice versa, thanks to a horrible bug in page rename. The image and its File: page are only tenously connected.

 

It’s all symptomatic of a thought process that does not put data first, from not starting with the data model. (MediaWiki’s template syntax is particularly gruesome too.)

 

I am not sure about whether your file-based system is a workable model. It seems that too much data could be in the file system, instead of the database. Image nesting sounds like a really bad idea. My site is highly structured, and this already causes me a real headache, because I have images in one part of the site that I need to appear in another part of the site, without the risk that renaming or moving the original images breaks the other places they get used. Hard links are one solution, I just realised, so long as I can mirror those in Windows.

 

I just hope that one day, someone will actually decide that my own model makes sense. I had a very interesting idea for a keyboard controller, but nobody took that seriously either. It’s no use having ideas: you have to also have the brains and dedication to build it without anyone’s help, as nobody will buy into the idea unless you can prove it works. (Unless you have an inspirational personality, that is

 

From <https://mail.google.com/mail/u/0/#inbox/FMfcgxwDrHlsdswSfbxVnZWfBhpdsHJC>

 

My migration path has been twiki, dekiwiki, mindtouch, onenote; with a few side trips into moin-moin and more recently Leo, an outlining text editor. Leo doesn't do media directly but it's conception of nodes in a hierarchy and cloned nodes (think file-system hard links) informs my mental what-if model. I don't understand what makes databases better than a filesystem, except that many obviously smarter than me people build on db instead. [in a db] I see a mass of stuff all squished into one level, and then whole bunch of differing and often conflicting interface logic on top which tries compose order. A tenuous linking akin to the mediawiki images example. There's some fundamental missing pieces in my education I suppose.

 

(Although, a file system isn't really files and folders either. At disk or block level it's also mash of flattish stuff with an interpolation layer or three on top. I guess part of the difference is that the presentation has been stable for decades, and mostly identical across platforms.)

 

Nesting containers inside content holding more content might indeed be a spectacularly bad idea. That part I'm less attached too. I like fractals, so the idea appeals, but maybe only so long as it remains idea.

 

"It’s no use having ideas: you have to also have the brains and dedication to build it without anyone’s help, as nobody will buy into the idea unless you can prove it works."

 

s'truth!

 

From <https://mail.google.com/mail/u/0/#inbox/FMfcgxwDrHlsdswSfbxVnZWfBhpdsHJC>

 

------------------------------------------------------

Start from the smallest possible unit. (atom? proton, neutron, electron? quark? lepton?)

 

what are minimal viable metadata?

  • gnx
  • parent gnx
  • child gnx (None or list)

 

This is all that's needed for graph. For a kb we need to add:

  • content (list)
    • default.txt
    • image1.png
    • image2.svg
    • audio1.mp3
    • video1.mp4
      • mime-type/x-mp4

 

(do we really need file extensions? We could use 'nix magic headers. x-mime-type is newest form, start there. For now we use .ext as shorthand to indicate presence of additional mime-type)

Mime-type is another way of saying "handler" or "preferred app to open with". I can imagine wanting distinct mime-type and preferred handler.

 

Hmm. content leptons are children of parent container, with own gnx et al. So when does a thing transform from content to container? con-tent. con-tain.

con-script, con-nect!

 

What if any node could live any and everywhere? All together in one flat db or file, or across a machine, or anywhere in the interwebs? Each one would need it's own address. That could be gnx, or maybe ipv6. That would necessitate all links be made over network protocol. Much overhead. but also, much potential. What's the fastest and slowest it could possibly be?

 

--------------------------------

Universal metadata fields:

  • created-timestamp
  • created author
  • last-modified-author
  • last-modified-timestamp
  • permissions (eeep. this could be huge)

 

(o) Windows and Mac file-system has or had concept of metadata at FS level. It seems to have not taken off. However it would be good to look at was being considered for fields. For ideas on what could or should be included here.

 

.......

 

mathew@universeodon.com - @maphew That's exactly how Hugo does it these days — a folder containing at least an index file with the text, and any number of media files or other text files which are referred to by the main index file.

 

https://gohugo.io/content-management/page-bundles/

 

One issue with making Postfreely use SQLite databases for bundles is that it's also designed to be usable with MySQL.

 

 

Created with OneNote.