Commit 6e236eca27e9fafcd8eb628975496368a8197117 - mmm

make mmmfs contents sidenote-mds s-ol 3 years ago

12 changed file(s) with 670 addition(s) and 670 deletion(s). Raw diff Collapse all Expand all

-0

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

(New empty file)

-0

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

(Empty file)

+166

-0

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

	0	evaluation
	1	==========
	2
	3	## examples
	4	### publishing and blogging
	5	Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to
	6	to see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this
	7	context:
	8
	9	The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its
	10	ability to flexibly transclude content from any source. This includes diagrams (such as in this thesis),
	11	videos (as in the documentation in the appendix), but also less conventional media such as
	12	interactive diagrams <mmm-link path="../references/aspect-ratios"></mmm-link> or twitter postings.
	13
	14	On the other hand, the development of the technical framework for this very thesis has posed greater challenges.
	15	In particular, the implementation of the reference and sidenote systems are brittle and uninspiring.
	16
	17	This is mostly due to the approach of splitting up the thesis into a multitude of fileders, and the current lack of
	18	mechanisms to re-capture information spread throughout the resulting history effectively.
	19	Another issue is that the system is currently based on the presumption that content can and should be interpreted
	20	separate from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic
	21	than initially anticipated.
	22
	23	### pinwall
	24	The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
	25	The type coercion layer completely abstracts away the complexities of transcluding different types of content,
	26	and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
	27
	28	A great benefit of the use of mmmfs versus other technology for realising this example is that the example can
	29	seamlessly embed not only plain text, markdown, images, videos, and interactive widgets, but also follow links to all
	30	of these types of content, and display them meaningfully. Accomplishing this with traditional frameworks would take
	31	great effort, where mmmfs benefits from the reuse of these conversions across the whole system.
	32
	33	In addition, the script for the pinwall folder is 120 lines long, of which 30 lines are styling, while almost 60 lines
	34	take care of capturing and handling JS events. The bulk of complexity is therefore shifted towards interacting with the
	35	UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
	36	output means other than the web.
	37
	38	### slideshow
	39	A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
	40	framework simplifies the generation of ad-hoc UI dramatically:
	41
	42	```moon
	43	import ReactiveVar, text, elements from require 'mmm.component'
	44	import div, a, img from elements
	45
	46	=>
	47	index = ReactiveVar 1
	48
	49	prev = (i) -> math.max 1, i - 1
	50	next = (i) -> math.min #@children, i + 1
	51
	52	div {
	53	div {
	54	a 'prev', href: '#', onclick: -> index\transform prev
	55	index\map (i) -> text " image ##{i} "
	56	a 'next', href: '#', onclick: -> index\transform next
	57	},
	58	index\map (i) ->
	59	child = assert @children[i], "image not found!"
	60	img src: @children[i]\gett 'URL -> image/png'
	61	}
	62	```
	63
	64	The presentation framework is a bit longer, but the added complexity is again required to deal with browser quirks,
	65	such as the fullscreen API and sizing content proportionally to the viewport size.
	66	The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
	67	more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
	68
	69	## general concerns
	70	While the system has proven pretty successfuly and moldable to the different use-cases that it has been tested in,
	71	there are also limitations in the proposed system that have become obvious in developing and working with the system.
	72	Some of these have been anticipated for some time and concrete research directions for solutions are apparent,
	73	while others may be intrinsic limitations in the approach taken.
	74
	75	### global set of converts
	76	In the current system, there exists only a single, global set of converts that can be potentially applied
	77	to facets anywhere in the system.
	78	Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
	79	For example if a fileder conatining multiple images wants to provide custom UI for each image when viewed independently,
	80	this code has to either be attached to every image individually (and redundantly), or added as a global convert.
	81	To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
	82	a new type and change the images to use it, which may present more problems yet and works against the principle of
	83	compatibility the system has been constructed for.
	84
	85	A potential direction of research in the future is to allow specifying converts as part of the fileder tree.
	86	Application of converts could then be scoped to their fileders' subtrees, such that for any facet only the converts
	87	stored in the chain of its parents upwards are considered.
	88	This way, converts can be added locally if they only make sense within a given context.
	89	Additionally it could be made possible to use this mechanism to locally override converts inherited from
	90	further up in the tree, for example to specialize types based on their context in the system.
	91
	92	The biggest downside to this approach would be that it presents another pressure factor for,
	93	while also reincforcing, the hierarchical organization of data,
	94	thereby exacerbating the limits of hierarchical structures.<div class="sidenote">see also
	95	<mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed></div>
	96
	97	### code outside of the system
	98	At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
	99	itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
	100	itself matured, but has become a limitation of the user experience now: Potential users of mmmfs would generally start
	101	by becoming familiar with the operation of mmmfs from within the system, as this is the expected (and designated)
	102	experience developed for them. All of the code that lives outside of the mmmfs tree is therefore invisible and opaque
	103	to them, actively limiting their understanding, and thereby the customizability, of the system.
	104
	105	This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by
	106	Ink and Switch<mmm-link path="../references/inkandswitch"></mmm-link>.
	107
	108	In general however, some portion of code may always have to be left outside of the system.
	109	This also wouldn't necessarily represent a problem, but in this case it is particularily relevant
	110	for the global set of converts (see above), as well as the layout used to render the web view,
	111	both of which are expected to undergo changes as users adapt the system to their own content types and
	112	domains of interest, as well as their visual identity, respectively.
	113
	114	### type system
	115	The currently used type system based on strings and pattern matching has been largely satisfactory,
	116	but has proven problematic for some anticipated use cases.
	117	It should be considered to switch to a more intricate,
	118	structural type system that allows encoding more concrete meta-data alongside the type,
	119	and to match converts based on a more flexible scheme of pattern matching.
	120	For example it is envisaged to store the resolution of an image file in its type.
	121	Many converts might choose to ignore this additional information,
	122	but others could use this information to generate lower-resolution 'thumbnails' of images automatically.
	123	Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
	124	when embedded in other documents.
	125
	126	### type-coercion
	127	By giving the system more information about the data it is dealing with,
	128	and then relying on the system to automatically transform between data-types,
	129	it is easy to lose track of which format data is concretely stored in.
	130	In much the same way that the application-centric paradigm alienates users from an understanding
	131	and feeling of ownership of their data by overemphasizing the tools in between,
	132	the automagical coercion of data types introduces distance between the user and
	133	an understanding of the data in the system.
	134	This poses a threat to the transparency of the system, and a potential lack of the quality of "Embodiment" (see above).
	135
	136	Potential solutions could be to communicate the conversion path clearly and explicitly together with the content,
	137	as well as making this display interactive to encourage experimentation with custom conversion queries.
	138	Emphasising the conversion process more strongly in this way might be able to turn this feature from an opaque
	139	hindrance into a transparent tool using careful UX and UI design.
	140
	141	### editing
	142	Because many converts are not necessarily reversible,
	143	it is very hard to implement generic ways of editing stored data in the same format it is viewed.
	144	For example, the system trivially converts markdown-formatted text sources into viewable HTML markup,
	145	but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.
	146	This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem
	147	worsens when the conversion path becomes more complex:
	148	If the markdown source was fetched via HTTP from a remote URL (e.g. if the facet's type was `URL -> text/markdown`),
	149	it is not possible to edit the content at all, since the only data owned by the system is the URL string itself,
	150	which is not part of the viewable representation at all.
	151	Similarily, when viewing output that is generated by code (e.g. `text/moonscript -> mmm/dom`),
	152	the code itself is not visible to the user when interacting with the viewable representation,
	153	and if the user wishes to change parts of the representation the system is unable to relate these changes to elements
	154	of the code or assist the user in doing so.
	155
	156	However even where plain text is used and edited, a shortcoming of the current approach to editing is evident:
	157	The content editor is wholly separate from the visible representation, and only facets of the currently viewed
	158	fileder can be edited. This means that content cannot be edited in its context, which is particularily annoying
	159	due to the fragmentation of content that mmmfs encourages.
	160
	161	As a result, the experiences of interacting with the system at large is still a very different experience than
	162	editing content (and thereby extending the system) in it. This is expected to represent a major hurdle for users
	163	getting started with the system, and is a major shortcoming in enabling end-user programming as set as a goal for
	164	this project. A future iteration should take care to reconsider how editing can be integrated more holistically
	165	with the other core concepts of the design.

-166

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

0		evaluation
1		==========
2
3		## examples
4		### publishing and blogging
5		Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to
6		to see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this
7		context:
8
9		The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its
10		ability to flexibly transclude content from any source. This includes diagrams (such as in this thesis),
11		videos (as in the documentation in the appendix), but also less conventional media such as
12		interactive diagrams <mmm-link path="../references/aspect-ratios"></mmm-link> or twitter postings.
13
14		On the other hand, the development of the technical framework for this very thesis has posed greater challenges.
15		In particular, the implementation of the reference and sidenote systems are brittle and uninspiring.
16
17		This is mostly due to the approach of splitting up the thesis into a multitude of fileders, and the current lack of
18		mechanisms to re-capture information spread throughout the resulting history effectively.
19		Another issue is that the system is currently based on the presumption that content can and should be interpreted
20		separate from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic
21		than initially anticipated.
22
23		### pinwall
24		The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
25		The type coercion layer completely abstracts away the complexities of transcluding different types of content,
26		and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
27
28		A great benefit of the use of mmmfs versus other technology for realising this example is that the example can
29		seamlessly embed not only plain text, markdown, images, videos, and interactive widgets, but also follow links to all
30		of these types of content, and display them meaningfully. Accomplishing this with traditional frameworks would take
31		great effort, where mmmfs benefits from the reuse of these conversions across the whole system.
32
33		In addition, the script for the pinwall folder is 120 lines long, of which 30 lines are styling, while almost 60 lines
34		take care of capturing and handling JS events. The bulk of complexity is therefore shifted towards interacting with the
35		UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
36		output means other than the web.
37
38		### slideshow
39		A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
40		framework simplifies the generation of ad-hoc UI dramatically:
41
42		```moon
43		import ReactiveVar, text, elements from require 'mmm.component'
44		import div, a, img from elements
45
46		=>
47		index = ReactiveVar 1
48
49		prev = (i) -> math.max 1, i - 1
50		next = (i) -> math.min #@children, i + 1
51
52		div {
53		div {
54		a 'prev', href: '#', onclick: -> index\transform prev
55		index\map (i) -> text " image ##{i} "
56		a 'next', href: '#', onclick: -> index\transform next
57		},
58		index\map (i) ->
59		child = assert @children[i], "image not found!"
60		img src: @children[i]\gett 'URL -> image/png'
61		}
62		```
63
64		The presentation framework is a bit longer, but the added complexity is again required to deal with browser quirks,
65		such as the fullscreen API and sizing content proportionally to the viewport size.
66		The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
67		more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
68
69		## general concerns
70		While the system has proven pretty successfuly and moldable to the different use-cases that it has been tested in,
71		there are also limitations in the proposed system that have become obvious in developing and working with the system.
72		Some of these have been anticipated for some time and concrete research directions for solutions are apparent,
73		while others may be intrinsic limitations in the approach taken.
74
75		### global set of converts
76		In the current system, there exists only a single, global set of converts that can be potentially applied
77		to facets anywhere in the system.
78		Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
79		For example if a fileder conatining multiple images wants to provide custom UI for each image when viewed independently,
80		this code has to either be attached to every image individually (and redundantly), or added as a global convert.
81		To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
82		a new type and change the images to use it, which may present more problems yet and works against the principle of
83		compatibility the system has been constructed for.
84
85		A potential direction of research in the future is to allow specifying converts as part of the fileder tree.
86		Application of converts could then be scoped to their fileders' subtrees, such that for any facet only the converts
87		stored in the chain of its parents upwards are considered.
88		This way, converts can be added locally if they only make sense within a given context.
89		Additionally it could be made possible to use this mechanism to locally override converts inherited from
90		further up in the tree, for example to specialize types based on their context in the system.
91
92		The biggest downside to this approach would be that it presents another pressure factor for,
93		while also reincforcing, the hierarchical organization of data,
94		thereby exacerbating the limits of hierarchical structures.<div class="sidenote">see also
95		<mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed></div>
96
97		### code outside of the system
98		At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
99		itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
100		itself matured, but has become a limitation of the user experience now: Potential users of mmmfs would generally start
101		by becoming familiar with the operation of mmmfs from within the system, as this is the expected (and designated)
102		experience developed for them. All of the code that lives outside of the mmmfs tree is therefore invisible and opaque
103		to them, actively limiting their understanding, and thereby the customizability, of the system.
104
105		This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by
106		Ink and Switch<mmm-link path="../references/inkandswitch"></mmm-link>.
107
108		In general however, some portion of code may always have to be left outside of the system.
109		This also wouldn't necessarily represent a problem, but in this case it is particularily relevant
110		for the global set of converts (see above), as well as the layout used to render the web view,
111		both of which are expected to undergo changes as users adapt the system to their own content types and
112		domains of interest, as well as their visual identity, respectively.
113
114		### type system
115		The currently used type system based on strings and pattern matching has been largely satisfactory,
116		but has proven problematic for some anticipated use cases.
117		It should be considered to switch to a more intricate,
118		structural type system that allows encoding more concrete meta-data alongside the type,
119		and to match converts based on a more flexible scheme of pattern matching.
120		For example it is envisaged to store the resolution of an image file in its type.
121		Many converts might choose to ignore this additional information,
122		but others could use this information to generate lower-resolution 'thumbnails' of images automatically.
123		Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
124		when embedded in other documents.
125
126		### type-coercion
127		By giving the system more information about the data it is dealing with,
128		and then relying on the system to automatically transform between data-types,
129		it is easy to lose track of which format data is concretely stored in.
130		In much the same way that the application-centric paradigm alienates users from an understanding
131		and feeling of ownership of their data by overemphasizing the tools in between,
132		the automagical coercion of data types introduces distance between the user and
133		an understanding of the data in the system.
134		This poses a threat to the transparency of the system, and a potential lack of the quality of "Embodiment" (see above).
135
136		Potential solutions could be to communicate the conversion path clearly and explicitly together with the content,
137		as well as making this display interactive to encourage experimentation with custom conversion queries.
138		Emphasising the conversion process more strongly in this way might be able to turn this feature from an opaque
139		hindrance into a transparent tool using careful UX and UI design.
140
141		### editing
142		Because many converts are not necessarily reversible,
143		it is very hard to implement generic ways of editing stored data in the same format it is viewed.
144		For example, the system trivially converts markdown-formatted text sources into viewable HTML markup,
145		but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.
146		This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem
147		worsens when the conversion path becomes more complex:
148		If the markdown source was fetched via HTTP from a remote URL (e.g. if the facet's type was `URL -> text/markdown`),
149		it is not possible to edit the content at all, since the only data owned by the system is the URL string itself,
150		which is not part of the viewable representation at all.
151		Similarily, when viewing output that is generated by code (e.g. `text/moonscript -> mmm/dom`),
152		the code itself is not visible to the user when interacting with the viewable representation,
153		and if the user wishes to change parts of the representation the system is unable to relate these changes to elements
154		of the code or assist the user in doing so.
155
156		However even where plain text is used and edited, a shortcoming of the current approach to editing is evident:
157		The content editor is wholly separate from the visible representation, and only facets of the currently viewed
158		fileder can be edited. This means that content cannot be edited in its context, which is particularily annoying
159		due to the fragmentation of content that mmmfs encourages.
160
161		As a result, the experiences of interacting with the system at large is still a very different experience than
162		editing content (and thereby extending the system) in it. This is expected to represent a major hurdle for users
163		getting started with the system, and is a major shortcoming in enabling end-user programming as set as a goal for
164		this project. A future iteration should take care to reconsider how editing can be integrated more holistically
165		with the other core concepts of the design.

+91

-0

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

	0	# examples
	1	To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above,
	2	a number of example use cases have been chosen and implemented from the perspective of a user.
	3	In the following section I will introduce these use cases and briefly summarize the implementation
	4	approach in terms of the capabilities of the proposed system.
	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	becase 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">
	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	Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
	29	and other media, but generally requiring precise and consistent control over formatting and layout.
	30	Some of these complexities are tedious to manage, but present good opportunities for programmatic
	31	systems and media to do work for the writer.
	32
	33	One such topic is the topic of references.
	34	References appear in various formats at multiple positions in a scientific document;
	35	usually they are referenced via a reduced visual form within the text of the document,
	36	and then shown again with full details at the end of the document.
	37
	38	For the sake of this thesis, referencing has been implemented using a subset of the popular
	39	BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
	40	type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
	41	(`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
	42
	43	For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
	44	which generates links to the ACM Digital Library<mmm-link path="../references/acm-dl"></mmm-link>
	45	API for accessing BibTeX citations for documents in the library.
	46	This means that it is enough to store the link to the ACM DL entry in mmmfs,
	47	and the reference will automatically be fetched (and track potential remote corrections).
	48
	49	## pinwall
	50	In many situations, in particular for creative work, it is often useful to compile resources of
	51	different types for reference or inspiration, and arrange them spacially so that they can be viewed
	52	at a glance or organized into different contexts etc.
	53	Such a pinwall could serve for example to organise references to articles,
	54	to collect visual inspiration for a moodboard etc.
	55
	56	As a collection, the Pinwall is primarily mapped to a Fileder in the system.
	57	Any content that is placed within can then be rendered by the Pinwall,
	58	which can constrain every piece of content to a rectangular piece on its canvas.
	59	This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
	60	which enumerates the list of children, wraps each in such a rectangular container,
	61	and outputs the list of containers as DOM elements.
	62
	63	The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
	64	`pinwall_info: text/json`. This facet can then set on each child and accessed whenever the script is called
	65	to render the children, plugging the values within the facet into the visual styling of the document.
	66
	67	The script can also set event handlers that react to user input while the document is loaded,
	68	and allow the user to reposition and resize the individual pinwall items by clicking and dragging
	69	on the upper border or lower right-hand corner respectively.
	70	Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
	71	so that the script places the content at the updated position and size next time it is invoked.
	72
	73	## slideshow
	74	Another common use of digital documents is as aids in a verbal presentation.
	75	These often take the form of slideshows, for the creation of which a number of established applications exist.
	76	In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
	77	advanced (and rewound) one by one using keypresses.
	78
	79	The implementation of this is rather straightforward as well.
	80	The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
	81	as well as a control interface with keys for advancing the active slide.
	82	It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
	83	of the website that may distract from the presentation, and register an event handler for keyboard accelerators
	84	for moving through the presentation.
	85
	86	Finally the script simply embeds the first of its child-fileders into the viewport rect.
	87	One the current slide is changed, the next embedded child is simply chosen.
	88
	89	## code documentation
	90	/meta/mmm.dom/:%20text/html+interactive

-91

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

0		# examples
1		To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above,
2		a number of example use cases have been chosen and implemented from the perspective of a user.
3		In the following section I will introduce these use cases and briefly summarize the implementation
4		approach in terms of the capabilities of the proposed system.
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		becase 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">
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		Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
29		and other media, but generally requiring precise and consistent control over formatting and layout.
30		Some of these complexities are tedious to manage, but present good opportunities for programmatic
31		systems and media to do work for the writer.
32
33		One such topic is the topic of references.
34		References appear in various formats at multiple positions in a scientific document;
35		usually they are referenced via a reduced visual form within the text of the document,
36		and then shown again with full details at the end of the document.
37
38		For the sake of this thesis, referencing has been implemented using a subset of the popular
39		BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
40		type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
41		(`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
42
43		For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
44		which generates links to the ACM Digital Library<mmm-link path="../references/acm-dl"></mmm-link>
45		API for accessing BibTeX citations for documents in the library.
46		This means that it is enough to store the link to the ACM DL entry in mmmfs,
47		and the reference will automatically be fetched (and track potential remote corrections).
48
49		## pinwall
50		In many situations, in particular for creative work, it is often useful to compile resources of
51		different types for reference or inspiration, and arrange them spacially so that they can be viewed
52		at a glance or organized into different contexts etc.
53		Such a pinwall could serve for example to organise references to articles,
54		to collect visual inspiration for a moodboard etc.
55
56		As a collection, the Pinwall is primarily mapped to a Fileder in the system.
57		Any content that is placed within can then be rendered by the Pinwall,
58		which can constrain every piece of content to a rectangular piece on its canvas.
59		This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
60		which enumerates the list of children, wraps each in such a rectangular container,
61		and outputs the list of containers as DOM elements.
62
63		The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
64		`pinwall_info: text/json`. This facet can then set on each child and accessed whenever the script is called
65		to render the children, plugging the values within the facet into the visual styling of the document.
66
67		The script can also set event handlers that react to user input while the document is loaded,
68		and allow the user to reposition and resize the individual pinwall items by clicking and dragging
69		on the upper border or lower right-hand corner respectively.
70		Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
71		so that the script places the content at the updated position and size next time it is invoked.
72
73		## slideshow
74		Another common use of digital documents is as aids in a verbal presentation.
75		These often take the form of slideshows, for the creation of which a number of established applications exist.
76		In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
77		advanced (and rewound) one by one using keypresses.
78
79		The implementation of this is rather straightforward as well.
80		The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
81		as well as a control interface with keys for advancing the active slide.
82		It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
83		of the website that may distract from the presentation, and register an event handler for keyboard accelerators
84		for moving through the presentation.
85
86		Finally the script simply embeds the first of its child-fileders into the viewport rect.
87		One the current slide is changed, the next embedded child is simply chosen.
88
89		## code documentation
90		/meta/mmm.dom/:%20text/html+interactive

+105

-0

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

	0	Two of the earliest wholistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
	1	The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the "Desktop". It invokes a strong analogy to physical tools.
	2	One of the differences between the Xerox Star system and other systems at the time, as well as the systems we use currently, is that the type of data a file represents is directly known to the system.
	3
	4	<div class="sidenote"><mmm-embed raw path="../references/xerox-star"></mmm-embed></div>
	5
	6	> In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
	7	> They do not "invoke a text editor", they "open a document".
	8	> The system knows the type of each file and notifies the relevant application program when one is opened.
	9	>
	10	> The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a program other than
	11	its "assigned" application. \[...\]
	12	> Star's designers feel that, for its audience, the advantages of allowing users to forget
	13	about programs outweighs this disadvantage.
	14
	15	Other systems at the time lacked any knowledge of the type of files,
	16	and while mainstream operating systems of today have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's name suffix, the intention of making applications a secondary, technical detail of working with the computer has surely been lost.
	17
	18	Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the system (the objects being anything from files to characters or paragraphs).
	19	These typed pieces of information are labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for ordering or defaut view of a folder for example.
	20
	21	***
	22
	23	Fig. 8 - Star Retrospective
	24
	25	The earliest indirect influence for the Xerox Alto and many other systems of its time,
	26	was the Memex. The Memex is a hypothetical device and system for knowledge management.
	27	Proposed by Vannevar Bush in 1945, the concept predates much of the technology that later was used to implement many parts of the vision. In essence, the concept of hypertext was invented.
	28
	29	***
	30
	31	One of the systems that could be said to have come closest to a practical implementation of the Memex might be Apple's Hypercard.
	32
	33	https://archive.org/details/CC501_hypercard
	34
	35	"So I can have the information in these stacks tied together in a way that makes sense"
	36
	37	In a demonstration video, the creators of the software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list.
	38	However these stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a different card.
	39
	40	Alongside Spreadsheets, Hypercard remains one of the most successful implementations of end-user programming, even today.
	41	While it's technical abilities have been long matched and passed by other software (such as the ubiquitous HTML hypertext markup language), these technical successors have failed the legacy of Hypercard as an end-user tool:
	42	while it is easier than ever to publish content on the web (through various social media and microblogging services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished.
	43	End-users do not create hypertext anymore.
	44
	45	The UNIX Philosophy <mmm-link path="../references/unix"></mmm-link>
	46	describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs
	47	research center in the 1960s. The concepts are considered quite influental and are still notably applied in the Linux community.
	48	Many attempts at summaries exist, but the following includes the pieces that are especially relevant even today:
	49
	50	> Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well.
	51	> Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be
	52	> written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs
	53	> than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs,
	54	> become general and useful tools.
	55
	56	This approach has multiple benefits with regard to end-user programmability:
	57	Assembling the system out of simple, modular pieces means that for any given task a user may want to implement,
	58	it is very likely that preexisting parts of the system can help the user realize a solution.
	59	Wherever such a preexisting part exists, it pays off designing it in such a way that it is easy to integrate for the user later.
	60	Assembling the system as a collection of modular, interacting pieces also enables future growth and customization,
	61	since pieces may be swapped out with customized or alternate software at any time.
	62
	63	***
	64
	65	Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours
	66	between contexts.
	67	Content should be able to be transcluded and referenced to facilitate the creation of flexible data formats and interactions,
	68	such that e.g. a slideshow slide can include content in a variety other formats (such as images and text) from anywhere else in the system.
	69	Behaviours should be able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs.
	70	For example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
	71
	72	The system should enable the quick creation of ad-hoc software.
	73
	74	While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is acknowledged,
	75	and the system should therefore be able to include content and behaviours via the network.
	76	This ability should be integrated deeply into the system,
	77	so that data can be treated independently of its origin and storage conditions, with as little caveats as possible.
	78
	79	The system needs to be browsable and understandable by users.
	80
	81	In order to provide users full access to their information as well as the computational infrastructure,
	82	users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
	83	in other words: be able to program.
	84
	85	While there is an ongoing area of research focusing on the development of new programming paradigms,
	86	methodologies and tools that are more accessible and cater to the wide
	87	range of end-users<mmm-link path="../references/subtext"></mmm-link>,
	88	in order to keep the scope of this work appropriate,
	89	conventional programming languages are used for the time being.
	90	Confidence is placed in the fact that eventually more user-friendly languages will be available and,
	91	given the goal of modularity, should be implementable in a straightforward fashion.
	92
	93	Ink and Switch suggest three qualities for tools striving to support
	94	end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
	95
	96	- "Embodiment", i.e. reifying central concepts of the programming model as more concrete, tangible objects
	97	in the digital space (for example through visual representation),
	98	in order to reduce cognitive load on the user.
	99	- "Living System", by which they seem to describe the malleability of a system or environment,
	100	and in particular the ability to make changes at different levels of depth in the system with
	101	very short feedback loops and a feeling of direct experience.
	102	- "In-place toolchain", denoting the availability of tools to customize and author the experience,
	103	as well as a certain accesibility of these tools, granted by a conceptual affinity between the
	104	use of the tools and general 'passive' use of containing system at large.

-105

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

0		Two of the earliest wholistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
1		The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the "Desktop". It invokes a strong analogy to physical tools.
2		One of the differences between the Xerox Star system and other systems at the time, as well as the systems we use currently, is that the type of data a file represents is directly known to the system.
3
4		<div class="sidenote"><mmm-embed raw path="../references/xerox-star"></mmm-embed></div>
5
6		> In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
7		> They do not "invoke a text editor", they "open a document".
8		> The system knows the type of each file and notifies the relevant application program when one is opened.
9		>
10		> The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a program other than
11		its "assigned" application. \[...\]
12		> Star's designers feel that, for its audience, the advantages of allowing users to forget
13		about programs outweighs this disadvantage.
14
15		Other systems at the time lacked any knowledge of the type of files,
16		and while mainstream operating systems of today have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's name suffix, the intention of making applications a secondary, technical detail of working with the computer has surely been lost.
17
18		Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the system (the objects being anything from files to characters or paragraphs).
19		These typed pieces of information are labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for ordering or defaut view of a folder for example.
20
21		***
22
23		Fig. 8 - Star Retrospective
24
25		The earliest indirect influence for the Xerox Alto and many other systems of its time,
26		was the Memex. The Memex is a hypothetical device and system for knowledge management.
27		Proposed by Vannevar Bush in 1945, the concept predates much of the technology that later was used to implement many parts of the vision. In essence, the concept of hypertext was invented.
28
29		***
30
31		One of the systems that could be said to have come closest to a practical implementation of the Memex might be Apple's Hypercard.
32
33		https://archive.org/details/CC501_hypercard
34
35		"So I can have the information in these stacks tied together in a way that makes sense"
36
37		In a demonstration video, the creators of the software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list.
38		However these stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a different card.
39
40		Alongside Spreadsheets, Hypercard remains one of the most successful implementations of end-user programming, even today.
41		While it's technical abilities have been long matched and passed by other software (such as the ubiquitous HTML hypertext markup language), these technical successors have failed the legacy of Hypercard as an end-user tool:
42		while it is easier than ever to publish content on the web (through various social media and microblogging services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished.
43		End-users do not create hypertext anymore.
44
45		The UNIX Philosophy <mmm-link path="../references/unix"></mmm-link>
46		describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs
47		research center in the 1960s. The concepts are considered quite influental and are still notably applied in the Linux community.
48		Many attempts at summaries exist, but the following includes the pieces that are especially relevant even today:
49
50		> Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well.
51		> Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be
52		> written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs
53		> than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs,
54		> become general and useful tools.
55
56		This approach has multiple benefits with regard to end-user programmability:
57		Assembling the system out of simple, modular pieces means that for any given task a user may want to implement,
58		it is very likely that preexisting parts of the system can help the user realize a solution.
59		Wherever such a preexisting part exists, it pays off designing it in such a way that it is easy to integrate for the user later.
60		Assembling the system as a collection of modular, interacting pieces also enables future growth and customization,
61		since pieces may be swapped out with customized or alternate software at any time.
62
63		***
64
65		Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours
66		between contexts.
67		Content should be able to be transcluded and referenced to facilitate the creation of flexible data formats and interactions,
68		such that e.g. a slideshow slide can include content in a variety other formats (such as images and text) from anywhere else in the system.
69		Behaviours should be able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs.
70		For example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
71
72		The system should enable the quick creation of ad-hoc software.
73
74		While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is acknowledged,
75		and the system should therefore be able to include content and behaviours via the network.
76		This ability should be integrated deeply into the system,
77		so that data can be treated independently of its origin and storage conditions, with as little caveats as possible.
78
79		The system needs to be browsable and understandable by users.
80
81		In order to provide users full access to their information as well as the computational infrastructure,
82		users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
83		in other words: be able to program.
84
85		While there is an ongoing area of research focusing on the development of new programming paradigms,
86		methodologies and tools that are more accessible and cater to the wide
87		range of end-users<mmm-link path="../references/subtext"></mmm-link>,
88		in order to keep the scope of this work appropriate,
89		conventional programming languages are used for the time being.
90		Confidence is placed in the fact that eventually more user-friendly languages will be available and,
91		given the goal of modularity, should be implementable in a straightforward fashion.
92
93		Ink and Switch suggest three qualities for tools striving to support
94		end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
95
96		- "Embodiment", i.e. reifying central concepts of the programming model as more concrete, tangible objects
97		in the digital space (for example through visual representation),
98		in order to reduce cognitive load on the user.
99		- "Living System", by which they seem to describe the malleability of a system or environment,
100		and in particular the ability to make changes at different levels of depth in the system with
101		very short feedback loops and a feeling of direct experience.
102		- "In-place toolchain", denoting the availability of tools to customize and author the experience,
103		as well as a certain accesibility of these tools, granted by a conceptual affinity between the
104		use of the tools and general 'passive' use of containing system at large.

+180

-0

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

	0	# mmmfs
	1	`mmmfs` seeks to improve on two fronts.
	2
	3	One of the main driving ideas of the mmmfs is to help data portability and use by making it simpler to inter-operate with different data formats.
	4	This is accomplished using two major components, the Type System and Coercion Engine and the Fileder Unified Data Model for unified data storage and access.
	5
	6	## the fileder unified data model
	7	The Fileder Model is the underlying unified data storage model.
	8	Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
	9
	10	<mmm-embed path="tree_mainstream">schematic view of an example tree in a mainstream filesystem</mmm-embed>
	11
	12	In common filesystems, as pictured, data can be organized hierarchically into folders (or directories),
	13	which serve only as containers of files, in which data is actually stored.
	14	While directories are fully transparent to both system and user (they can be created, browser, listed and viewed by both),
	15	files are, from the system perspective, mostly opaque and inert blocks of data.
	16
	17	Some metadata, such as file size and access permissions, is associated with each file,
	18	but notably the type of data is generally not actually stored in the filesystem,
	19	but determined loosely based on multiple heuristics depending on the system and context.
	20	Some notable mechanism are:
	21
	22
	23	- Suffixes in the name are often used to indicate what kind of data a file should contain. However there is no standardization
	24	- over this, and often a suffix is used for multiple incompatible versions of a file-format.
	25	- Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
	26	On unix systems the `libmagic` database and library of these so-called magic constants is commonly used to guess
	27	the file-type based on these fragments of data.
	28	- on UNIX systems, files to be executed are checked by a variety of methods<mmm-link path="../references/linux-exec">
	29	</mmm-link> in order to determine which format would fit. For example, script files, the "shebang" symbol, `#!`, can
	30	be used to specify the program that should parse this file in the first line of the file.
	31
	32	It should be clear already from this short list that to mainstream operating systems, as well as the applications
	33	running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
	34
	35	Because these various mechanisms are applied at different times by the operating system and applications,
	36	it is possible for files to be labelled as or considered as being in different formats at the same time by different components of the system.
	37	<div class="sidenote" style="margin-top: -5rem;">
	38	The difference between changing a file extension and converting a file between two formats is commonly unclear to users,
	39	for example: see <a href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
	40	Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602
	41	<!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file --> from 2019-12-18
	42	</div>
	43	This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
	44	Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
	45	by one software component, while a security mechanism meant to detect such code determines the same file to be a
	46	legitimate image<mmm-link path="../references/poc-or-gtfo"></mmm-link> (the file may in fact be valid in both formats).
	47
	48	In mmmfs, the example above might look like this instead:
	49	<mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
	50
	51	Superficially, this may look quite similar: there is still only two types of nodes (referred to as fileders and facets),
	52	and again one of them, the fileders are used only to hierarchically organize facets.
	53	Unlike files, factes don't only store a freeform name, there is also a dedicated type field associated with every facet,
	54	that is explicitly designed to be understood and used by the system.
	55
	56	Despite the similarities, the semantics of this system are very different:
	57	In mainstream filesystems, each file stands for itself only;
	58	i.e. in a directory, no relationship between files is assumed by default,
	59	and files are most of the time read or used outside of the context they exist in in the filesystem.
	60
	61	In mmmfs, a facet should only ever be considered an aspect of its fileder, and never as separate from it.
	62	A fileder can contain multiple facets, but they are meant to be alternate or equivalent representations of the fileder itself.
	63	Though for some uses it is required, software in general does not have to be directly aware of the facets existing within a fileder,
	64	rather it assumes the presence of content in the representation that it requires, and simple requests it.
	65	The Type Coercion Engine (see below) will then attempt to satisfy this request based on the facets that are in fact present.
	66
	67	Semantically a fileder, like a directory, also encompasses all the other fileders nested within it (recursively).
	68	Since fileders are the primary unit of data to be operated upon, fileder nesting emerges as a natural way of structuring complex data,
	69	both for access by the system and applications, as well as the user themself.
	70
	71	## the type system & coercion engine
	72	As mentioned above, facets store data alongside its type, and when applications require data from a fileder,
	73	they specify the type (or the list of types) that they require the type to be in.
	74
	75	In the current iteration of the type system, types are simple strings of text and loosely based on MIME-types [TOOD: quote RFC?].
	76	MIME types consist of a major- and minor category, and optionally a 'suffix'.
	77	Here are some common MIME-types that are also used in mmmfs:
	78
	79	- `text/html` and `text/html+frag` (mmmfs only)
	80	- `text/javascript`
	81	- `image/png`
	82	- `image/jpeg`
	83
	84	While these types allow some amount of specifity, they fall short of describing their content especially in cases where formats overlap:
	85	Source code is often distributed in `.tar.gz` archive files (directory-trees that are first bundled into an `application/x-tar` archive,
	86	and then compressed into an `application/gzip` archive).
	87	Using either of these two types is either incorrect or insufficient information to properly treat and extract the contained data.
	88
	89	To mitigate this problem, mmmfs types can be nested. This is denoted in mmmfs type strings using the `->` symbol, e.g. the mmmfs-types
	90	`application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a tar-gz-compressed directory tree and the URL linking to a JPEG-picture respectively.
	91
	92	Depending on the outer type this nesting can mean different things:
	93	for URLs the nested type is expected to be found after fetching the URL with HTTP,
	94	compression formats are expected to contain contents of the nested types,
	95	and executable formats are expected to output data of the nested type.
	96
	97	It is a lot more important to be able to accurately describe the type of a facet in mmmfs than in mainstream operating systems,
	98	because while in the latter types are mostly used only associate an application that will then prompt the user about further steps,
	99	mmmfs uses the type to automatically find one or more programs to execute to convert or transform the data stored in a facet
	100	into the type required by the application.
	101
	102	This process of type coercion uses a database of known converts, that can be applied to data.
	103	Every convert consists of a description of the input types that it can accept, the output type it would produce for a given input type,
	104	as well as the code for actually converting a given piece of data.
	105	Simple converts may simply consist of a fixed in and output type,
	106	such as for example this convert for rendering Markdown-encoded text to a HTML hypertext fragment:
	107
	108	{
	109	inp: 'text/markdown'
	110	out: 'text/html+frag'
	111	transform: (value, ...) ->
	112	-- implementation stripped for brevity
	113	}
	114
	115	Other converts on the other hand may accept a wide range of input types:
	116
	117	{
	118	inp: 'URL -> image/.*'
	119	out: 'text/html+frag'
	120	transform: (url) -> img src: url
	121	}
	122
	123	This convert uses a Lua Pattern to specify that it can accept an URL to any type of image,
	124	and convert it to an HTML fragment.
	125
	126	By using the pattern substitution syntax provided by the Lua `string.gsub` function,
	127	converts can also make the type they return depend on the input type, as is required often when nested types are unpacked:
	128
	129	{
	130	inp: 'application/gzip -> (.*)'
	131	out: '%1'
	132	transform: (data) ->
	133	-- implementation stripped for brevity
	134	}
	135
	136	This convert accepts an `application/gzip` type wrapping any other type, and captures that nested type in a pattern group.
	137	It then uses the substituion syntax to specify that nested type as the output of the conversion.
	138	For an input type of `application/gzip -> image/png` this convert would therefore generate the type `image/png`.
	139
	140	To further demonstrate the flexibility using this approach, consider this last example:
	141
	142	{
	143	inp: 'text/moonscript -> (.*)'
	144	out: 'text/lua -> %1'
	145	transform: (code) -> moonscript.to_lua code
	146	}
	147
	148	This convert transpiles MoonScript source-code into Lua source-code, while keeping the nested type
	149	(in this case the result expected when executing either script) the same.
	150
	151	In addition to the attributes shown above, every convert is also rated with a cost value.
	152	The cost value is meant to roughly estimate both the cost (in terms of computing power) of the conversion,
	153	as well as the accuracy or immediacy of the conversion.
	154	For example, resizing an image to a lower size should have a high cost, because the process is computationally expensive,
	155	but also because a smaller image represents the original image to a lesser degree.
	156	Similarily, an URL to a piece of content is a less immediate representation than the content itself,
	157	so the cost of a convert that simply generates the URL to a piece of data should be high even if the process is very cheap to compute.
	158
	159	Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was present as accurately as possible.
	160	It is also important to prevent some nonsensical results from occuring, such as displaying a link to content instead of the content itself because
	161	the link requires less steps to create than completely converting the content does.
	162
	163	***
	164
	165	Type coercion is implemented using a general pathfinding algorithm, similar to A*.
	166	First, the set of given types is found by selecting all facets of the fileder that match the name given in the query.
	167	The set of given types is marked in green in the following example graph.
	168
	169	From there the algorithm recursively checks whether it can reach other types by applying all matching converts to the type
	170	that is cheapest to reach, excluding any types that have already been exhaustively-searched in this way.
	171	All types it finds, that have not yet been inserted into the set of given types are then added to the set,
	172	so that they may be searched as well.
	173
	174	The algorithm doesn't stop immediately after reaching a type from the result set,
	175	it continues search until it either completely exhausts the result space,
	176	or until all non-exhaustively searched paths are already higher than the maximum allowed path.
	177	This ensures that the optimal path is found, even if a more expensive path is found more quickly initially.
	178
	179	<mmm-embed path="type_coercion_graph">excerpt of the graph of conversion paths from two starting facets to mmm/dom</mmm-embed>

-180

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

0		# mmmfs
1		`mmmfs` seeks to improve on two fronts.
2
3		One of the main driving ideas of the mmmfs is to help data portability and use by making it simpler to inter-operate with different data formats.
4		This is accomplished using two major components, the Type System and Coercion Engine and the Fileder Unified Data Model for unified data storage and access.
5
6		## the fileder unified data model
7		The Fileder Model is the underlying unified data storage model.
8		Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
9
10		<mmm-embed path="tree_mainstream">schematic view of an example tree in a mainstream filesystem</mmm-embed>
11
12		In common filesystems, as pictured, data can be organized hierarchically into folders (or directories),
13		which serve only as containers of files, in which data is actually stored.
14		While directories are fully transparent to both system and user (they can be created, browser, listed and viewed by both),
15		files are, from the system perspective, mostly opaque and inert blocks of data.
16
17		Some metadata, such as file size and access permissions, is associated with each file,
18		but notably the type of data is generally not actually stored in the filesystem,
19		but determined loosely based on multiple heuristics depending on the system and context.
20		Some notable mechanism are:
21
22
23		- Suffixes in the name are often used to indicate what kind of data a file should contain. However there is no standardization
24		- over this, and often a suffix is used for multiple incompatible versions of a file-format.
25		- Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
26		On unix systems the `libmagic` database and library of these so-called magic constants is commonly used to guess
27		the file-type based on these fragments of data.
28		- on UNIX systems, files to be executed are checked by a variety of methods<mmm-link path="../references/linux-exec">
29		</mmm-link> in order to determine which format would fit. For example, script files, the "shebang" symbol, `#!`, can
30		be used to specify the program that should parse this file in the first line of the file.
31
32		It should be clear already from this short list that to mainstream operating systems, as well as the applications
33		running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
34
35		Because these various mechanisms are applied at different times by the operating system and applications,
36		it is possible for files to be labelled as or considered as being in different formats at the same time by different components of the system.
37		<div class="sidenote" style="margin-top: -5rem;">
38		The difference between changing a file extension and converting a file between two formats is commonly unclear to users,
39		for example: see <a href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
40		Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602
41		<!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file --> from 2019-12-18
42		</div>
43		This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
44		Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
45		by one software component, while a security mechanism meant to detect such code determines the same file to be a
46		legitimate image<mmm-link path="../references/poc-or-gtfo"></mmm-link> (the file may in fact be valid in both formats).
47
48		In mmmfs, the example above might look like this instead:
49		<mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
50
51		Superficially, this may look quite similar: there is still only two types of nodes (referred to as fileders and facets),
52		and again one of them, the fileders are used only to hierarchically organize facets.
53		Unlike files, factes don't only store a freeform name, there is also a dedicated type field associated with every facet,
54		that is explicitly designed to be understood and used by the system.
55
56		Despite the similarities, the semantics of this system are very different:
57		In mainstream filesystems, each file stands for itself only;
58		i.e. in a directory, no relationship between files is assumed by default,
59		and files are most of the time read or used outside of the context they exist in in the filesystem.
60
61		In mmmfs, a facet should only ever be considered an aspect of its fileder, and never as separate from it.
62		A fileder can contain multiple facets, but they are meant to be alternate or equivalent representations of the fileder itself.
63		Though for some uses it is required, software in general does not have to be directly aware of the facets existing within a fileder,
64		rather it assumes the presence of content in the representation that it requires, and simple requests it.
65		The Type Coercion Engine (see below) will then attempt to satisfy this request based on the facets that are in fact present.
66
67		Semantically a fileder, like a directory, also encompasses all the other fileders nested within it (recursively).
68		Since fileders are the primary unit of data to be operated upon, fileder nesting emerges as a natural way of structuring complex data,
69		both for access by the system and applications, as well as the user themself.
70
71		## the type system & coercion engine
72		As mentioned above, facets store data alongside its type, and when applications require data from a fileder,
73		they specify the type (or the list of types) that they require the type to be in.
74
75		In the current iteration of the type system, types are simple strings of text and loosely based on MIME-types [TOOD: quote RFC?].
76		MIME types consist of a major- and minor category, and optionally a 'suffix'.
77		Here are some common MIME-types that are also used in mmmfs:
78
79		- `text/html` and `text/html+frag` (mmmfs only)
80		- `text/javascript`
81		- `image/png`
82		- `image/jpeg`
83
84		While these types allow some amount of specifity, they fall short of describing their content especially in cases where formats overlap:
85		Source code is often distributed in `.tar.gz` archive files (directory-trees that are first bundled into an `application/x-tar` archive,
86		and then compressed into an `application/gzip` archive).
87		Using either of these two types is either incorrect or insufficient information to properly treat and extract the contained data.
88
89		To mitigate this problem, mmmfs types can be nested. This is denoted in mmmfs type strings using the `->` symbol, e.g. the mmmfs-types
90		`application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a tar-gz-compressed directory tree and the URL linking to a JPEG-picture respectively.
91
92		Depending on the outer type this nesting can mean different things:
93		for URLs the nested type is expected to be found after fetching the URL with HTTP,
94		compression formats are expected to contain contents of the nested types,
95		and executable formats are expected to output data of the nested type.
96
97		It is a lot more important to be able to accurately describe the type of a facet in mmmfs than in mainstream operating systems,
98		because while in the latter types are mostly used only associate an application that will then prompt the user about further steps,
99		mmmfs uses the type to automatically find one or more programs to execute to convert or transform the data stored in a facet
100		into the type required by the application.
101
102		This process of type coercion uses a database of known converts, that can be applied to data.
103		Every convert consists of a description of the input types that it can accept, the output type it would produce for a given input type,
104		as well as the code for actually converting a given piece of data.
105		Simple converts may simply consist of a fixed in and output type,
106		such as for example this convert for rendering Markdown-encoded text to a HTML hypertext fragment:
107
108		{
109		inp: 'text/markdown'
110		out: 'text/html+frag'
111		transform: (value, ...) ->
112		-- implementation stripped for brevity
113		}
114
115		Other converts on the other hand may accept a wide range of input types:
116
117		{
118		inp: 'URL -> image/.*'
119		out: 'text/html+frag'
120		transform: (url) -> img src: url
121		}
122
123		This convert uses a Lua Pattern to specify that it can accept an URL to any type of image,
124		and convert it to an HTML fragment.
125
126		By using the pattern substitution syntax provided by the Lua `string.gsub` function,
127		converts can also make the type they return depend on the input type, as is required often when nested types are unpacked:
128
129		{
130		inp: 'application/gzip -> (.*)'
131		out: '%1'
132		transform: (data) ->
133		-- implementation stripped for brevity
134		}
135
136		This convert accepts an `application/gzip` type wrapping any other type, and captures that nested type in a pattern group.
137		It then uses the substituion syntax to specify that nested type as the output of the conversion.
138		For an input type of `application/gzip -> image/png` this convert would therefore generate the type `image/png`.
139
140		To further demonstrate the flexibility using this approach, consider this last example:
141
142		{
143		inp: 'text/moonscript -> (.*)'
144		out: 'text/lua -> %1'
145		transform: (code) -> moonscript.to_lua code
146		}
147
148		This convert transpiles MoonScript source-code into Lua source-code, while keeping the nested type
149		(in this case the result expected when executing either script) the same.
150
151		In addition to the attributes shown above, every convert is also rated with a cost value.
152		The cost value is meant to roughly estimate both the cost (in terms of computing power) of the conversion,
153		as well as the accuracy or immediacy of the conversion.
154		For example, resizing an image to a lower size should have a high cost, because the process is computationally expensive,
155		but also because a smaller image represents the original image to a lesser degree.
156		Similarily, an URL to a piece of content is a less immediate representation than the content itself,
157		so the cost of a convert that simply generates the URL to a piece of data should be high even if the process is very cheap to compute.
158
159		Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was present as accurately as possible.
160		It is also important to prevent some nonsensical results from occuring, such as displaying a link to content instead of the content itself because
161		the link requires less steps to create than completely converting the content does.
162
163		***
164
165		Type coercion is implemented using a general pathfinding algorithm, similar to A*.
166		First, the set of given types is found by selecting all facets of the fileder that match the name given in the query.
167		The set of given types is marked in green in the following example graph.
168
169		From there the algorithm recursively checks whether it can reach other types by applying all matching converts to the type
170		that is cheapest to reach, excluding any types that have already been exhaustively-searched in this way.
171		All types it finds, that have not yet been inserted into the set of given types are then added to the set,
172		so that they may be searched as well.
173
174		The algorithm doesn't stop immediately after reaching a type from the result set,
175		it continues search until it either completely exhausts the result space,
176		or until all non-exhaustively searched paths are already higher than the maximum allowed path.
177		This ensures that the optimal path is found, even if a more expensive path is found more quickly initially.
178
179		<mmm-embed path="type_coercion_graph">excerpt of the graph of conversion paths from two starting facets to mmm/dom</mmm-embed>

+128

-0

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

	0	# motivation
	1
	2	The majority of users interacts with modern computing systems in the form of smartphones, laptops or desktop PCs,
	3	using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.
	4
	5	All of these operating systems share the concept of Applications (or Apps) as one of the core pieces of their interaction model.
	6	Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed as Applications.
	7
	8	In addition, a lot of functionality is nowadays delivered in the form of Web Apps, which are used inside a Browser (which is an Application itself).
	9	Web Apps often offer similar functionality to other Applications, but are subject to some limitations:
	10	In most cases, they are only accessible or functional in the presence of a stable internet connection,
	11	and they have very limited access to the resources of the physical computer they are running on.
	12	For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
	13	other than through a standardized set of interactions (e.g. selecting a file via a visual menu, capturing audio and video from a webcam, opening another website).
	14
	15	On the two Desktop Operating Systems (Mac OS X and Windows), file management and the concepts of Documents are still central
	16	elements of interactions with the system. The two prevalent smartphone systems deemphasize this concept by only allowing access to the
	17	data actually stored on the device through an app itself.
	18
	19	This focus on Applications as the primary unit of systems can be seen as the root cause of multiple problems:
	20	Because applications are the products companies produce, and software represents a market of users,
	21	developers compete on features integrated into their applications.
	22
	23	However this lack of control over data access is not the only problem the application-centric approach induces:
	24	A consequence of this is that interoperability between applications and data formats is rare.
	25	To stay relevant, monlithic software or software suites are designed to
	26	As a result applications tend to accrete features rather then modularise and delegate to other software [P Chiusano].
	27	Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in.
	28	This often means re-implementing services and functinality that is already available
	29	and integrating it directly in other applications produced by the same organisation.
	30
	31	This leads to massively complex file formats,
	32	such as for example the .docx format commonly used for storing mostly
	33	textual data enriched with images and videos on occasion.
	34	The docx format is in fact an archive that can contain many virtual files internally,
	35	such as the images and videos referenced before.
	36	However this is completely unknown to the operating system,
	37	and so users are unable to access the contents in this way.
	38	As a result, editing an image contained in a word document is far from a trivial task:
	39	first the document has to be opened in a word processing application,
	40	then the image has to be exported from it and saved in its own, temporary file.
	41	This file can then be edited and saved back to disk.
	42	Once updated, the image may be reimported into the .docx document.
	43	If the word-processing application supports this,
	44	the old image may be replaced directly, otherwise the user may have to remove the old image,
	45	insert the new one and carefully ensure that the positioning in the document remains intact.
	46
	47	https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions
	48
	49
	50	The application-centric computing paradigm common today is harmful to users,
	51	because it leaves behind "intert" data as D. Cragg calls it:
	52
	53	[Cragg 2016]
	54	D. Cragg coins the term "inert data" for the data created, and left behind, by apps and applications in the computing model that is currently prevalent:
	55	Most data today is either intrinsically linked to one specific application, that controls and limits access to the actual information,
	56	or even worse, stored in the cloud where users have no direct access at all and depend soley on online tools that require a stable network connection
	57	and a modern browser, and that could be modified, removed or otherwise negatively impacted at any moment.
	58
	59	This issue is worsened by the fact that the a lot of software we use today is deployed through the cloud computing and SaaS paradigms,
	60	which are far less reliable than earlier means of distributing software:
	61	Software that runs in the cloud is subject to outages due to network problems,
	62	pricing or availability changes etc. at the whim of the company providing it, as well as ISPs involved in the distribution.
	63	Cloud software, as well as subscription-model software with online-verification mechanisms are additionally subject
	64	to license changes, updates modifiying, restricting or simply removing past functionality etc.
	65	Additionally, many cloud software solutions and ecosystems store the users' data in the cloud,
	66	where they are subject to foreign laws and privacy concerns are intransparently handled by the companies.
	67	Should the company, for any reason, be unable or unwanting to continue servicing a customer,
	68	the data may be irrecoverably lost (or access prevented).
	69
	70	Data rarely really fits the metaphora of files very well,
	71	and even when it does it is rarely exposed to the user that way:
	72	The 'Contacts' app on a mobile phone or laptop for example does not store each contacts's information
	73	in a separate 'file' (as the metaphora may have initially suggested),
	74	but rather keeps this database hidden away from the user.
	75	Consequently, access to the information contained in the database is only enabled through the contacts applications GUI.
	76
	77	--
	78
	79	According to some researchers in the field of Human-Computer-Interaction, the state of computing is rather dire.
	80
	81	It seems that a huge majority of daily computer users have silently accepted
	82	that real control over their most important everyday tool will be forever out of reach,
	83	and surrendered it to the relatively small group of 'programmers' curating their experience.
	84
	85	- Applications are bad
	86	- Services are worse
	87
	88
	89	Chiusano blames these issues on the metaphor of the machine, and likens apps and applications to appliances.
	90	According to him, what should really be provided are tools:
	91	composable pieces of software that naturally lend themselves to, or outrightly call for,
	92	integration into the users' other systems and customization,
	93	rather than lure into the walled-gardens of corporate ecosystems using network-effects.
	94
	95	Data is inert [Cragg 2016]
	96
	97	Key points:
	98	- data ownership
	99	data needs to be freely accessible (without depending on a 3rd party) and unconditionally accessible
	100	- data compatibility
	101	data needs to be usable outside the context of it's past use (in the worst case)
	102	- functionality
	103	user needs many, complex needs met
	104
	105
	106	Today, computer users are losing more and more control over their data. Between web and cloud
	107	applications holding customer data hostage for providing the services, unappealing and limited mobile file
	108	browsing experiences and the non-interoperable, proprietary file formats holding on to their own data has
	109	become infeasible for many users. mmmfs is an attempt at rethinking file-systems and the computer user
	110	experience to give control back to and empower users.
	111
	112	mmmfs tries to provide a filesystem that is powerful enough to let you use it as your canvas for thinking,
	113	and working at the computer. mmmfs is made for more than just storing information. Files in mmmfs can interact
	114	and morph to create complex behaviours.
	115
	116	Let us take as an example the simple task of collecting and arranging a mixed collection of images, videos
	117	and texts in order to brainstorm. To create an assemblage of pictures and text, many might be tempted to open an
	118	Application like Microsoft Word or Adobe Photoshop and create a new document there. Both photoshop files and
	119	word documents are capable of containing texts and images, but when the files are saved, direct access to the
	120	contained data is lost. It is for example a non-trivial and unenjoyable task to edit an image file contained
	121	in a word document in another application and have the changes apply to the document. In the same way,
	122	text contained in a photoshop document cannot be edited in a text editor of your choice.
	123
	124	Creative use of computer technology is limited to programmers, since applications constrain their users to the
	125	paths and abilities that the developers anticipated and deemed useful.
	126	Note that 'creative' here does not only encompass 'artistic': this applies to any field and means
	127	that innovative use of technology is unlikely to happen as a result of practice by domain experts.

-128

~~root/articles/mmmfs/problem-statement/text$markdown.md~~ less more

0		# motivation
1
2		The majority of users interacts with modern computing systems in the form of smartphones, laptops or desktop PCs,
3		using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.
4
5		All of these operating systems share the concept of Applications (or Apps) as one of the core pieces of their interaction model.
6		Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed as Applications.
7
8		In addition, a lot of functionality is nowadays delivered in the form of Web Apps, which are used inside a Browser (which is an Application itself).
9		Web Apps often offer similar functionality to other Applications, but are subject to some limitations:
10		In most cases, they are only accessible or functional in the presence of a stable internet connection,
11		and they have very limited access to the resources of the physical computer they are running on.
12		For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
13		other than through a standardized set of interactions (e.g. selecting a file via a visual menu, capturing audio and video from a webcam, opening another website).
14
15		On the two Desktop Operating Systems (Mac OS X and Windows), file management and the concepts of Documents are still central
16		elements of interactions with the system. The two prevalent smartphone systems deemphasize this concept by only allowing access to the
17		data actually stored on the device through an app itself.
18
19		This focus on Applications as the primary unit of systems can be seen as the root cause of multiple problems:
20		Because applications are the products companies produce, and software represents a market of users,
21		developers compete on features integrated into their applications.
22
23		However this lack of control over data access is not the only problem the application-centric approach induces:
24		A consequence of this is that interoperability between applications and data formats is rare.
25		To stay relevant, monlithic software or software suites are designed to
26		As a result applications tend to accrete features rather then modularise and delegate to other software [P Chiusano].
27		Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in.
28		This often means re-implementing services and functinality that is already available
29		and integrating it directly in other applications produced by the same organisation.
30
31		This leads to massively complex file formats,
32		such as for example the .docx format commonly used for storing mostly
33		textual data enriched with images and videos on occasion.
34		The docx format is in fact an archive that can contain many virtual files internally,
35		such as the images and videos referenced before.
36		However this is completely unknown to the operating system,
37		and so users are unable to access the contents in this way.
38		As a result, editing an image contained in a word document is far from a trivial task:
39		first the document has to be opened in a word processing application,
40		then the image has to be exported from it and saved in its own, temporary file.
41		This file can then be edited and saved back to disk.
42		Once updated, the image may be reimported into the .docx document.
43		If the word-processing application supports this,
44		the old image may be replaced directly, otherwise the user may have to remove the old image,
45		insert the new one and carefully ensure that the positioning in the document remains intact.
46
47		https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions
48
49
50		The application-centric computing paradigm common today is harmful to users,
51		because it leaves behind "intert" data as D. Cragg calls it:
52
53		[Cragg 2016]
54		D. Cragg coins the term "inert data" for the data created, and left behind, by apps and applications in the computing model that is currently prevalent:
55		Most data today is either intrinsically linked to one specific application, that controls and limits access to the actual information,
56		or even worse, stored in the cloud where users have no direct access at all and depend soley on online tools that require a stable network connection
57		and a modern browser, and that could be modified, removed or otherwise negatively impacted at any moment.
58
59		This issue is worsened by the fact that the a lot of software we use today is deployed through the cloud computing and SaaS paradigms,
60		which are far less reliable than earlier means of distributing software:
61		Software that runs in the cloud is subject to outages due to network problems,
62		pricing or availability changes etc. at the whim of the company providing it, as well as ISPs involved in the distribution.
63		Cloud software, as well as subscription-model software with online-verification mechanisms are additionally subject
64		to license changes, updates modifiying, restricting or simply removing past functionality etc.
65		Additionally, many cloud software solutions and ecosystems store the users' data in the cloud,
66		where they are subject to foreign laws and privacy concerns are intransparently handled by the companies.
67		Should the company, for any reason, be unable or unwanting to continue servicing a customer,
68		the data may be irrecoverably lost (or access prevented).
69
70		Data rarely really fits the metaphora of files very well,
71		and even when it does it is rarely exposed to the user that way:
72		The 'Contacts' app on a mobile phone or laptop for example does not store each contacts's information
73		in a separate 'file' (as the metaphora may have initially suggested),
74		but rather keeps this database hidden away from the user.
75		Consequently, access to the information contained in the database is only enabled through the contacts applications GUI.
76
77		--
78
79		According to some researchers in the field of Human-Computer-Interaction, the state of computing is rather dire.
80
81		It seems that a huge majority of daily computer users have silently accepted
82		that real control over their most important everyday tool will be forever out of reach,
83		and surrendered it to the relatively small group of 'programmers' curating their experience.
84
85		- Applications are bad
86		- Services are worse
87
88
89		Chiusano blames these issues on the metaphor of the machine, and likens apps and applications to appliances.
90		According to him, what should really be provided are tools:
91		composable pieces of software that naturally lend themselves to, or outrightly call for,
92		integration into the users' other systems and customization,
93		rather than lure into the walled-gardens of corporate ecosystems using network-effects.
94
95		Data is inert [Cragg 2016]
96
97		Key points:
98		- data ownership
99		data needs to be freely accessible (without depending on a 3rd party) and unconditionally accessible
100		- data compatibility
101		data needs to be usable outside the context of it's past use (in the worst case)
102		- functionality
103		user needs many, complex needs met
104
105
106		Today, computer users are losing more and more control over their data. Between web and cloud
107		applications holding customer data hostage for providing the services, unappealing and limited mobile file
108		browsing experiences and the non-interoperable, proprietary file formats holding on to their own data has
109		become infeasible for many users. mmmfs is an attempt at rethinking file-systems and the computer user
110		experience to give control back to and empower users.
111
112		mmmfs tries to provide a filesystem that is powerful enough to let you use it as your canvas for thinking,
113		and working at the computer. mmmfs is made for more than just storing information. Files in mmmfs can interact
114		and morph to create complex behaviours.
115
116		Let us take as an example the simple task of collecting and arranging a mixed collection of images, videos
117		and texts in order to brainstorm. To create an assemblage of pictures and text, many might be tempted to open an
118		Application like Microsoft Word or Adobe Photoshop and create a new document there. Both photoshop files and
119		word documents are capable of containing texts and images, but when the files are saved, direct access to the
120		contained data is lost. It is for example a non-trivial and unenjoyable task to edit an image file contained
121		in a word document in another application and have the changes apply to the document. In the same way,
122		text contained in a photoshop document cannot be edited in a text editor of your choice.
123
124		Creative use of computer technology is limited to programmers, since applications constrain their users to the
125		paths and abilities that the developers anticipated and deemed useful.
126		Note that 'creative' here does not only encompass 'artistic': this applies to any field and means
127		that innovative use of technology is unlikely to happen as a result of practice by domain experts.