Commit 2c3977673b94f67779cc439b7b1460f08d8d38df - mmm

+1

-1

mmm/mmmfs/util.moon less more

103	103	link_to fileder, node, nil, opts.attr
104	104
105	105	when 'sidenote'
106		key = opts.desc or tostring refs\get!
	106	key = tostring refs\get!
107	107	id = "sideref-#{key}"
108	108
109	109	intext = sup a key, href: "##{id}"

+2

-1

root/articles/mmmfs/$order less more

0	0	title
1	1	abstract
	2	table-of-contents
2	3	motivation
3	4	historical-approaches
4	5	framework

7	8	evaluation
8	9	conclusion
9	10	references
	11	ba_log
10	12	statement-of-originality
11		ba_log

+4

-0

root/articles/mmmfs/ba_log/intro: text$markdown.md less more

	0	The following pages document the development of the `mmmfs` system described above in the form of a project log.
	1	Please note that the log has been written primarily for viewing using a web browser, and as such makes extensive use of
	2	hyperlinking, and also includes some videos that cannot be reproduced in print. It is therefore recommended to view the
	3	live version of the log online at the following address: [s-ol.nu/ba/log](https://s-ol.nu/ba/log).

+2

-1

root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon less more

5	5	div {
6	6	class: 'print-ownpage'
7	7
8		h1 link_to @, "appendix: project log"
	8	h1 (link_to @, "appendix: project log"), id: 'ba-log'
	9	@gett 'intro: mmm/dom'
9	10	table.unpack for post in *@children
10	11	continue if post\get 'hidden: bool'
11	12

+2

-1

root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon less more

3	3
4	4	=>
5	5	div {
6		h1 link_to @, "appendix: project log"
	6	h1 (link_to @, "appendix: project log"), id: 'ba-log'
	7	@gett 'intro: mmm/dom'
7	8	ul do
8	9	posts = for post in *@children
9	10	continue if post\get 'hidden: bool'

+0

-1

~~root/articles/mmmfs/ba_log/title: text$plain~~ less more

0

project log

+1

-2

root/articles/mmmfs/conclusion/text$markdown+sidenotes.md less more

0		conclusion
1		==========
	0	# 7. conclusion
2	1
3	2	<div class="well well-warning">[section under construction]</div>

+11

-12

root/articles/mmmfs/evaluation/text$markdown+sidenotes.md less more

0		evaluation
1		==========
	0	# 6. evaluation
2	1
3		## examples
	2	## 6.1 examples
4	3	In this section I will take a look at the implementations of the example for the use cases outlined above,
5	4	and evaluate them with regard to the framework derived in the corresponding section above.
6	5
7		### publishing and blogging
	6	### 6.1.1 publishing and blogging
8	7	Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to
9	8	see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this
10	9	context:

24	23	separately from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic
25	24	than initially anticipated.
26	25
27		### pinwall
	26	### 6.1.2 pinwall
28	27	The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
29	28	The type coercion layer completely abstracts away the complexities of transcluding different types of content,
30	29	and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.

39	38	UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
40	39	output means other than the web.
41	40
42		### slideshow
	41	### 6.1.3 slideshow
43	42	A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
44	43	framework simplifies the generation of ad-hoc UI dramatically:
45	44

70	69	The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
71	70	more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
72	71
73		## general concerns
	72	## 6.2 general concerns
74	73	While the system has proven pretty successful and moldable to the different use-cases that it has been tested in,
75	74	there are also limitations in the proposed system that have become obvious in developing and working with the system.
76	75	Some of these have been anticipated for some time and concrete research directions for solutions are apparent,
77	76	while others may be intrinsic limitations in the approach taken.
78	77
79		### global set of converts
	78	### 6.2.1 global set of converts
80	79	In the current system, there is only a single, global set of converts that can be potentially applied to facets
81	80	anywhere in the system.
82	81	Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.

97	96	The biggest downside to this approach would be that it presents another pressure factor for, while also reincforcing,
98	97	the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
99	98
100		### code outside of the system
	99	### 6.2.2 code outside of the system
101	100	At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
102	101	itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
103	102	itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start

114	113	Both of these are expected to undergo changes as users adapt the system to their own content types and
115	114	domains of interest, as well as their visual identity, respectively.
116	115
117		### type system
	116	### 6.2.3 type system
118	117	The currently used type system based on strings and pattern matching has been largely satisfactory,
119	118	but has proven problematic for some anticipated use cases.
120	119	It should be considered to switch to a more intricate,

126	125	Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
127	126	when embedded in other documents.
128	127
129		### type-coercion
	128	### 6.2.4 type-coercion
130	129	By giving the system more information about the data it is dealing with,
131	130	and then relying on the system to automatically transform between data-types,
132	131	it is easy to lose track of which format data is concretely stored in.

141	140	Emphasising the conversion process more strongly in this way might be a way to turn this feature from an opaque
142	141	hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design.
143	142
144		### editing
	143	### 6.2.5 in-system editing
145	144	Because many converts are not necessarily reversible, it is very hard to implement generic ways of editing stored data
146	145	in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into
147	146	viewable HTML markup, but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.

+88

-0

root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md less more

	0	## 5.1 publishing and blogging
	1	### 5.1.1 blogging
	2	Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text,
	3	interspersed with media such as images and videos or perhaps social media posts.
	4	Markdown is a great tool for this job, and has been integrated in the system to much success:
	5	There are two different types registered with converts: `text/markdown` and `text/markdown+span`.
	6	They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
	7	The only difference for `text/markdown+span` is that it is limited to a single line,
	8	and doesn't render as a paragraph but rather just a line of text.
	9	This makes it suitable for denoting formatted-text titles and other small strings of text.
	10
	11	The problem of embedding other content together with text comfortably is also solved easily,
	12	because Markdown allows embedding arbitrary HTML in the document.
	13	This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
	14	`<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm.
	15
	16	### 5.1.2 scientific publishing
	17	<div class="sidenote" style="margin-top: 1.25rem">
	18	One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
	19	is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
	20	since it does not support interaction.
	21	</div>
	22
	23	Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
	24	and other media, but generally requiring precise and consistent control over formatting and layout.
	25	Some of these complexities are tedious to manage, but present good opportunities for programmatic
	26	systems and media to do work for the writer.
	27
	28	One such topic is the topic of references.
	29	References appear in various formats at multiple positions in a scientific document;
	30	usually they are referenced via a reduced visual form within the text of the document,
	31	and then shown again with full details at the end of the document.
	32
	33	For the sake of this thesis, referencing has been implemented using a subset of the popular
	34	BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
	35	type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
	36	(`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
	37
	38	For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
	39	which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
	40	API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the
	41	ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
	42	remote corrections.
	43
	44	## 5.2 pinwall
	45	In many situations, in particular for creative work, it is often useful to compile resources of
	46	different types for reference or inspiration, and arrange them spacially so that they can be viewed
	47	at a glance or organized into different contexts etc.
	48	Such a pinwall could serve for example to organise references to articles,
	49	to collect visual inspiration for a moodboard etc.
	50
	51	As a collection, the Pinwall is primarily mapped to a Fileder in the system.
	52	Any content that is placed within can then be rendered by the Pinwall,
	53	which can constrain every piece of content to a rectangular piece on its canvas.
	54	This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
	55	which enumerates the list of children, wraps each in such a rectangular container,
	56	and outputs the list of containers as DOM elements.
	57
	58	The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
	59	`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called
	60	to render the children, plugging the values within the facet into the visual styling of the document.
	61
	62	The script can also set event handlers that react to user input while the document is loaded,
	63	and allow the user to reposition and resize the individual pinwall items by clicking and dragging
	64	on the upper border or lower right-hand corner respectively.
	65	Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
	66	so that the updated position and size are stored for the next time the pinwall is opened.
	67
	68	## 5.3 slideshow
	69	Another common use of digital documents is as aids in a verbal presentation.
	70	These often take the form of slideshows, for the creation of which a number of established applications exist.
	71	In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
	72	advanced (and rewound) one by one using keypresses.
	73
	74	The implementation of this is rather straightforward as well.
	75	The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
	76	as well as a control interface with keys for advancing the active slide.
	77	It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
	78	of the website that may distract from the presentation, and register an event handler for keyboard accelerators
	79	for moving through the presentation.
	80
	81	Finally the script simply embeds the first of its child-fileders into the viewport rectangle.
	82	Once the current slide is changed, the next embedded child is simply chosen.
	83
	84	<!--
	85	## code documentation
	86	/meta/mmm.dom/:%20text/html+interactive
	87	-->

+3

-89

root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md less more

0		# examples
	0	# 5. example use-cases
1	1	To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above,
2	2	a number of example use cases have been chosen and implemented from the perspective of a user.
3	3	In the following section I will introduce these use cases and briefly summarize the implementation
4	4	approach in terms of the capabilities of the proposed system.
5	5
6		## publishing and blogging
7		### blogging
8		Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text,
9		interspersed with media such as images and videos or perhaps social media posts.
10		Markdown is a great tool for this job, and has been integrated in the system to much success:
11		There are two different types registered with converts: `text/markdown` and `text/markdown+span`.
12		They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
13		The only difference for `text/markdown+span` is that it is limited to a single line,
14		and doesn't render as a paragraph but rather just a line of text.
15		This makes it suitable for denoting formatted-text titles and other small strings of text.
16
17		The problem of embedding other content together with text comfortably is also solved easily,
18		because Markdown allows embedding arbitrary HTML in the document.
19		This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
20		`<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm.
21
22		### scientific publishing
23		<div class="sidenote" style="margin-top: 1.25rem">
24		One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
25		is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
26		since it does not support interaction.
27		</div>
28
29		Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
30		and other media, but generally requiring precise and consistent control over formatting and layout.
31		Some of these complexities are tedious to manage, but present good opportunities for programmatic
32		systems and media to do work for the writer.
33
34		One such topic is the topic of references.
35		References appear in various formats at multiple positions in a scientific document;
36		usually they are referenced via a reduced visual form within the text of the document,
37		and then shown again with full details at the end of the document.
38
39		For the sake of this thesis, referencing has been implemented using a subset of the popular
40		BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
41		type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
42		(`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
43
44		For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
45		which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
46		API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the
47		ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
48		remote corrections.
49
50		## pinwall
51		In many situations, in particular for creative work, it is often useful to compile resources of
52		different types for reference or inspiration, and arrange them spacially so that they can be viewed
53		at a glance or organized into different contexts etc.
54		Such a pinwall could serve for example to organise references to articles,
55		to collect visual inspiration for a moodboard etc.
56
57		As a collection, the Pinwall is primarily mapped to a Fileder in the system.
58		Any content that is placed within can then be rendered by the Pinwall,
59		which can constrain every piece of content to a rectangular piece on its canvas.
60		This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
61		which enumerates the list of children, wraps each in such a rectangular container,
62		and outputs the list of containers as DOM elements.
63
64		The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
65		`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called
66		to render the children, plugging the values within the facet into the visual styling of the document.
67
68		The script can also set event handlers that react to user input while the document is loaded,
69		and allow the user to reposition and resize the individual pinwall items by clicking and dragging
70		on the upper border or lower right-hand corner respectively.
71		Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
72		so that the updated position and size are stored for the next time the pinwall is opened.
73
74		## slideshow
75		Another common use of digital documents is as aids in a verbal presentation.
76		These often take the form of slideshows, for the creation of which a number of established applications exist.
77		In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
78		advanced (and rewound) one by one using keypresses.
79
80		The implementation of this is rather straightforward as well.
81		The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
82		as well as a control interface with keys for advancing the active slide.
83		It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
84		of the website that may distract from the presentation, and register an event handler for keyboard accelerators
85		for moving through the presentation.
86
87		Finally the script simply embeds the first of its child-fileders into the viewport rectangle.
88		Once the current slide is changed, the next embedded child is simply chosen.
89
90		<!--
91		## code documentation
92		/meta/mmm.dom/:%20text/html+interactive
93		-->
	6	<span class="sidenote">The online version is available at [s-ol.nu/ba](https://s-ol.nu/ba).</span>
	7	The following examples can be viewed and inspected in the interactive version online:

+3

-11

root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon less more

30	30
31	31	li link_to child
32	32
33		examples = div {
34		style:
35		position: 'relative'
36		'margin-top': '4rem'
	33	examples = ul for child in *@children
	34	preview child
37	35
38		div "The online version is available at ", (a "s-ol.nu/ba", href: 'https://s-ol.nu/ba'), ".", class: 'sidenote'
39		"The following examples can be viewed and inspected in the interactive version online:"
40		ul for child in *@children
41		preview child
42		}
43
44		div (@gett 'intro: mmm/dom'), examples
	36	div (@gett 'intro: mmm/dom'), examples, (@gett 'implementation: mmm/dom')

+9

-10

root/articles/mmmfs/framework/text$markdown+sidenotes.md less more

0		evaluation framework
1		====================
	0	# 3. evaluation framework
2	1
3	2	In the following section, I will collect approaches and reviews of different end-user software systems from current
4	3	literature, as well as derive and present my own requirements and guiding principles for the development of a new
5	4	system.
6	5
7		qualities
8		---------
	6	3.1 qualities of successful end-user computing
	7	----------------------------------------------
9	8
10	9	Ink and Switch suggest three qualities for tools striving to support
11	10	end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:

25	24	constraints: namely the construction of a system for end-users to keep, structure and display personal information and
26	25	thoughts.
27	26
28		modularity
29		----------
	27	3.2 modularity
	28	--------------
30	29
31	30	The UNIX Philosophy<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design
32	31	paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The

49	48	Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds
50	49	directly to the concept of Embodiment described by Ink & Switch.
51	50
52		content transclusion
53		--------------------
	51	3.3 content transclusion
	52	------------------------
54	53
55	54	The strengths of modular architectures should similarily extend also into the way the system will be used by users.
56	55	If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be

75	74	storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
76	75	content transclusion should be paid attention to and taken into consideration for a system's design.
77	76
78		end-user programming
79		--------------------
	77	3.4 end-user programming
	78	------------------------
80	79
81	80	In order to provide users full access to their information as well as the computational infrastructure,
82	81	users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,

+1

-2

root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md less more

0		historical approaches
1		=====================
	0	# 2. historical approaches
2	1
3	2	Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and
4	3	introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".

+0

-1

root/articles/mmmfs/mmmfs/$order less more

0		confusion
1	0	type_coercion_graph
2	1	tree_mmmfs
3	2	tree_mainstream

+0

-5

~~root/articles/mmmfs/mmmfs/confusion/text$markdown.md~~ less more

0		For example, the difference between changing a file extension and converting a file between two formats is often unclear
1		to users, as evident from questions like this: <a
2		href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
3		Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602 from 2019-12-18
4		<!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file -->

+9

-8

root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md less more

0		mmmfs
1		=====
	0	# 4. mmmfs
2	1
3	2	`mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for
4	3	generating static websites, but has been extended with live interaction and introspection, as well as embedded

12	11	The abstraction of data types is accomplished using two major components, the Type System and Coercion Engine and
13	12	the Fileder Unified Data Model for unified data storage and access.
14	13
15		## the fileder unified data model
	14	## 4.1 the fileder unified data model
16	15	The Fileder Model is the underlying unified data storage model.
17	16	Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
18	17

41	40	It should be clear already from this short list that to mainstream operating systems, as well as the applications
42	41	running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
43	42
44		<mmm-embed path="confusion" wrap="marginnote" style="margin-top: -3rem;"></mmm-embed>
45	43	Because these various mechanisms are applied at different times by the operating system and applications, it is possible
46	44	for files to be labelled or considered as being in different formats at the same time by different components of the
47	45	system.
48	46
49		This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
	47	This leads to confusion about the factual format of data among users<mmm-embed path="../references/renaming"
	48	wrap="sidenote" style="margin-top: -3rem;">For example, the difference between changing a file extension and converting
	49	a file between two formats is often unclear to users, as evident from questions like this: </mmm-embed>, but can
	50	also pose a serious security risk:
50	51	Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
51	52	by one software component, while a security mechanism meant to detect such code determines the same file to be a
52		legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote"></mmm-embed> (the file may in fact be valid
53		in both formats).
	53	legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote" style="margin-top: 2rem"></mmm-embed>
	54	(the file may in fact be valid in both formats).
54	55
55	56	In mmmfs, the example above might look like this instead:
56	57	<mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>

75	76	(recursively). Since fileders are the primary unit of data to be operated upon, fileder nesting emerges as a natural
76	77	way of structuring complex data, both for access by the system and its components, as well as the user themself.
77	78
78		## the type system & coercion engine
	79	## 4.2 the type system & coercion engine
79	80	As mentioned above, facets store data alongside its type, and when a component of the system requires data from a
80	81	fileder, it has to specify the expected type (or a list of these) that it requires the data to be in. The system
81	82	then attempts to coerce one of the existing facets into the expected type, if possible. This process can involve many

+9

-10

root/articles/mmmfs/motivation/text$markdown+sidenotes.md less more

0		motivation
1		==========
	0	# 1. motivation
2	1
3		application-centric design
4		--------------------------
	2	1.1 application-centric design
	3	------------------------------
5	4
6	5	The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs,
7	6	using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.

41	40	hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>,
42	41	mobile systems like Apple's iOS already started out as such walled gardens.
43	42
44		cloud computing
45		---------------
	43	1.2 cloud computing
	44	-------------------
46	45
47	46	Web Apps often offer similar functionality to other applications, but are subject to additional limitations:
48	47	In most cases, they are only accessible or functional in the presence of a stable internet connection,

59	58	consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
60	59	whom an inability to access their tools or their cloud-stored data can pose an existential threat.
61	60
62		inert data (and data formats)
63		-----------------------------
	61	1.3 inert data (and data formats)
	62	---------------------------------
64	63
65	64	Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
66	65	created and left behind by apps and applications in the computing model that is currently prevalent: Most data today

81	80	otherwise the user may have to remove the old image, insert the new one and carefully ensure that the positioning in
82	81	the document remains intact.
83	82
84		disjointed filesystems
85		----------------------
	83	1.4 disjointed filesystems
	84	--------------------------
86	85
87	86	The filesystems and file models used on modern computing devices generally operate on the assumption that every
88	87	individual file stands for itself. Grouping of files in folders is allowed as a convenience for users, but most

+14

-14

root/articles/mmmfs/references/$order less more

	0	poc-or-gtfo
	1	aspect-ratios
	2	memex
0	3	appliances
1		osx-files
2		ios-files
3	4	super-powers
	5	dijkstra
	6	subtext
	7	mime-types
	8	alternatives-to-trees
	9	xerox-star
	10	unix
	11	transclusion
4	12	adobe
5		xerox-star
6		memex
	13	acm-dl
7	14	hypercard
8		wikipedia
9		unix
10		subtext
11	15	inkandswitch
12	16	linux-exec
13		poc-or-gtfo
14		acm-dl
15		aspect-ratios
16		alternatives-to-trees
17		transclusion
18		mime-types
19		dijkstra
	17	wikipedia
	18	osx-files
	19	renaming

+1

-0

root/articles/mmmfs/references/adobe/text$bibtex less more

1	1	title = {Adobe is cutting off users in Venezuela due to US sanctions},
2	2	url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions},
3	3	publisher = {The Verge},
	4	author = {Lee, Dami},
4	5	year = {2019},
5	6	visited = {2019-12-18},
6	7	}

+0

-6

~~root/articles/mmmfs/references/ios-files/text$bibtex~~ less more

0		@online{ios:files,
1		title = {Use the Files app on your iPhone, iPad, or iPod touch},
2		url = {https://support.apple.com/en-us/HT206481},
3		publisher = {Apple},
4		visited = {2019-12-27},
5		}

+6

-0

root/articles/mmmfs/references/renaming/text$bibtex less more

	0	@online{renaming,
	1	title = {Why is it possible to convert a file just by renaming it?},
	2	url = {https://askubuntu.com/q/166602},
	3	publisher = {askubuntu.com},
	4	visited = {2019-12-18},
	5	}

+1

-1

root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon less more

4	4	refs = for ref in *@children
5	5	li ref\gett 'mmm/dom'
6	6	div {
7		h1 "references"
	7	h1 "references", id: 'references'
8	8	ol with refs
9	9	refs.style = 'line-height': 'normal'
10	10	}

+1

-1

root/articles/mmmfs/statement-of-originality/text$html+frag.html less more

0	0	<div class="print-only print-ownpage" style="margin: 4cm 0 0;">
1		<h1>Statement of Originality</h1>
	1	<h1 id="statement">statement of originality</h1>
2	2	<p style="margin-top: 5cm">
3	3	This is to certify that the content of this project, documentation and thesis is my own work. It
4	4	has not been submitted for any other degree or other purposes. I certify that the intellectual

+89

-0

root/articles/mmmfs/table-of-contents/text$html+frag.html less more

	0	<!--
	1	{
	2	const fmt = x => `<a href="#${x.id}">${x.innerText}</a>`;
	3
	4	const parse = e => ({
	5	num: +e.tagName.substr(1),
	6	fmt: fmt(e),
	7	});
	8
	9	const render = (list) => {
	10	let str = '';
	11	let num = 0;
	12	for (e of list) {
	13	while (e.num > num) {
	14	str += '<ol style="list-style: none;">'
	15	num += 1;
	16	}
	17
	18	while (e.num < num) {
	19	str += '</ol>';
	20	num -= 1;
	21	}
	22
	23	str += `<li>${e.fmt}</li>`;
	24	}
	25	return str;
	26	};
	27
	28	render([...$0.querySelectorAll('h1, h2, h3, h4, h5').values()].map(parse));
	29	}
	30	-->
	31	<section class="print-ownpage">
	32	<h1 id="table-of-contents">table of contents</h1>
	33	<ol style="list-style: none;">
	34	<li><a href="#abstract">abstract</a></li>
	35	<li><a href="#table-of-contents">table of contents</a></li>
	36	<li><a href="#1-motivation">1. motivation</a></li>
	37	<ol style="list-style: none;">
	38	<li><a href="#11-application-centric-design">1.1 application-centric design</a></li>
	39	<li><a href="#12-cloud-computing">1.2 cloud computing</a></li>
	40	<li><a href="#13-inert-data-and-data-formats">1.3 inert data (and data formats)</a></li>
	41	<li><a href="#14-disjointed-filesystems">1.4 disjointed filesystems</a></li>
	42	</ol>
	43	<li><a href="#2-historical-approaches">2. historical approaches</a></li>
	44	<li><a href="#3-evaluation-framework">3. evaluation framework</a></li>
	45	<ol style="list-style: none;">
	46	<li><a href="#31-qualities-of-successful-end-user-computing">3.1 qualities of successful end-user computing</a></li>
	47	<li><a href="#32-modularity">3.2 modularity</a></li>
	48	<li><a href="#33-content-transclusion">3.3 content transclusion</a></li>
	49	<li><a href="#34-end-user-programming">3.4 end-user programming</a></li>
	50	</ol>
	51	<li><a href="#4-mmmfs">4. mmmfs</a></li>
	52	<ol style="list-style: none;">
	53	<li><a href="#41-the-fileder-unified-data-model">4.1 the fileder unified data model</a></li>
	54	<li><a href="#42-the-type-system--coercion-engine">4.2 the type system & coercion engine</a></li>
	55	</ol>
	56	<li><a href="#5-example-use-cases">5. example use-cases</a></li>
	57	<ol style="list-style: none;">
	58	<li><a href="#51-publishing-and-blogging">5.1 publishing and blogging</a></li>
	59	<ol style="list-style: none;">
	60	<li><a href="#511-blogging">5.1.1 blogging</a></li>
	61	<li><a href="#512-scientific-publishing">5.1.2 scientific publishing</a></li>
	62	</ol>
	63	<li><a href="#52-pinwall">5.2 pinwall</a></li>
	64	<li><a href="#53-slideshow">5.3 slideshow</a></li>
	65	</ol>
	66	<li><a href="#6-evaluation">6. evaluation</a></li>
	67	<ol style="list-style: none;">
	68	<li><a href="#61-examples">6.1 examples</a></li>
	69	<ol style="list-style: none;">
	70	<li><a href="#611-publishing-and-blogging">6.1.1 publishing and blogging</a></li>
	71	<li><a href="#612-pinwall">6.1.2 pinwall</a></li>
	72	<li><a href="#613-slideshow">6.1.3 slideshow</a></li>
	73	</ol>
	74	<li><a href="#62-general-concerns">6.2 general concerns</a></li>
	75	<ol style="list-style: none;">
	76	<li><a href="#621-global-set-of-converts">6.2.1 global set of converts</a></li>
	77	<li><a href="#622-code-outside-of-the-system">6.2.2 code outside of the system</a></li>
	78	<li><a href="#623-type-system">6.2.3 type system</a></li>
	79	<li><a href="#624-type-coercion">6.2.4 type-coercion</a></li>
	80	<li><a href="#625-in-system-editing">6.2.5 in-system editing</a></li>
	81	</ol>
	82	</ol>
	83	<li><a href="#7-conclusion">7. conclusion</a></li>
	84	<li><a href="#references">references</a></li>
	85	<li><a href="#ba-log">appendix: project log</a></li>
	86	<li><a href="#statement">statement of originality</a></li>
	87	</ol>
	88	</section>

+0

-1

root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon less more

10	10	append = (a) -> table.insert _this, a
11	11
12	12	append div {
13		class: 'screen-only'
14	13	h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 }
15	14	p {
16	15	style: