Commit ec453658 authored by Michael Murtaugh's avatar Michael Murtaugh
Browse files

renamed cookbook to makeserver, attempted to remove submods

parent aa8ccbd4
[submodule "cookbook/data/htdocs/tablesort"]
path = cookbook/data/htdocs/tablesort
url = https://github.com/tristen/tablesort.git
[submodule "cookbook/data/htdocs/draggable"]
path = cookbook/data/htdocs/draggable
url = git@gitlab.constantvzw.org:aa/draggable.git
[submodule "cookbook/data/htdocs/editor"]
path = cookbook/data/htdocs/editor
url = git@gitlab.constantvzw.org:aa/editor.git
[submodule "cookbook/data/htdocs/player"]
path = cookbook/data/htdocs/player
url = git@gitlab.constantvzw.org:aa/player.git
......@@ -11,28 +11,55 @@
<div id="header">
<h1 class="title">LOG</h1>
</div>
<h2 id="nov-2016">24 nov 2016</h2>
<p>Woke up this morning with the thought: this project must be <em>promiscuous</em>.</p>
<ul>
<li>Simply drawing on the background could trigger widgets.</li>
<li>Widgets should &quot;receive&quot; links and have other input/output <em>nodes</em> to route messages (instead of the current mess of relaying ALL messages).</li>
<li>Different kinds of widgets should exist:
<ul>
<li>Viewer (as in iframe, but then better -- ie pdf.js)</li>
</ul></li>
<li>Think how link clicking can map into a TEXT document.</li>
<li>Widget: Close box</li>
<li>Editor: hide + extend the options!</li>
<li>Editor: status: temporary overlay</li>
<li>Widget: Need font with case (can't check the filenames!)</li>
<li>Widget: Z-Indexing! (as they overlap!)</li>
<li>File selection (via icons) + actions (such as delete)... rename with search / replace &amp; patterns (regexp!)</li>
<li>CRUCIAL: refresh listing without reloading page (and losing widgets!)</li>
<li>etherpad widget/viewer/editor (or could a similar experience occur somehow directly ?!?!)</li>
</ul>
<p>Maybe need to make a choice:</p>
<ul>
<li>Widgets are all about producing rich editing experiences with interacting components (view + text edit)</li>
<li>Widgets are about publishing static documents, new ways of writing.</li>
<li>Or do both of these things work together (rather than need to be split)?</li>
</ul>
<p>SHOUT OUT TO WEBSTALKER!</p>
<p>WRITING WITH CODE (promiscuous is a performative writing environment)</p>
<h2 id="nov-2016-1">23 nov 2016</h2>
<ul>
<li>Enabled operation without makefile</li>
<li>iframe widget</li>
<li>move fragment code from player to &quot;iframe&quot;(frame) widget</li>
</ul>
<h2 id="nov-2016-2">22 nov 2016</h2>
<ul>
<li><s>Rehookup index.cgi as directory listing</s> -- actually this became a proper class (no CGI!)</li>
<li><s>Add a frame creator widget (via mini tool palette!)</s> POC complete, now for the real deal</li>
<li>make sure drag and drop works with this (to enable play &amp; edit!)</li>
<li>ensure frame messages working</li>
<li><p>Eventually remove the cgi-bin!? ... need to transition to HTTP VERBS? (POST for save?)</p></li>
<li>4 Nov 2016: Switch from hard coded directory listing to one that's makefile driven (indexical!)</li>
<li>4 Nov 2016: REMOVAL of jinja2 dependency!</li>
<li>14 Nov 2016: Change to simplified single makefile</li>
<li>18 Nov 2016: Added ?edit syntax and &quot;direct editor&quot; view.</li>
<li><p>18 Nov 2016: Added ?edit syntax and &quot;direct editor&quot; view.</p></li>
</ul>
<h2 id="earlier">earlier</h2>
<p>It seemed very strong how when generalizing the data join, I suddenly (finally) started to care about the form of the incoming data. In other words, the specific labels of the data started to have an effect as they connected (or didn't) with the names of properties in the rdfa &quot;template&quot; element. Thus the document becomes instrumentalized as a sort of filter / query into the incoming data stream. Now, finally, the benefits of data rewriting via a mechanism like json-ld would be most useful (and appreciated) to complete the loop without a need for ad hoc reframing / tweaking of the data. The hit or miss effect of the selection, filtering and ignoring unnecessary data, is reminiscent (in an encouraging way) of json-ld's contexts as filters.</p>
<p>A surprising discovery has been the re-finding of writing &quot;template&quot; code in the form of a sample table row with rdfa properties. It seems it might be useful to revisit early web publishing flows that must have used this kind of mechanism (vague memories of Internet Explorer specific html element properties like data-source).</p>
<p>Next step? * Data value filters (based on a type? ... or simply connected to a specific value) to do date formating and file size niceness!</p>
<p>(later: I realize that this data join stuff was best separate from the main line of the makefile based server and can better be split off and developed on it raises quite a few questions on it's own)</p>
<h2 id="nov-2016">22 nov 2016</h2>
<ul>
<li><s>Rehookup index.cgi as directory listing</s> -- actually this became a proper class (no CGI!)</li>
<li><s>Add a frame creator widget (via mini tool palette!)</s> POC complete, now for the real deal</li>
<li>make sure drag and drop works with this (to enable play &amp; edit!)</li>
<li>ensure frame messages working</li>
<li>Eventually remove the cgi-bin!?</li>
</ul>
<h2 id="nov-2016-1">23 nov 2016</h2>
<ul>
<li>TODO: Enable operation without makefile (default)</li>
</ul>
</body>
</html>
......@@ -2,6 +2,56 @@
title: LOG
---
24 nov 2016
-------------
Woke up this morning with the thought: this project must be *promiscuous*.
* Are widgets just different kinds of "server flavors" like ?edit and ?serve ?! ... Would be nice to roll the media specific code back into a "media player" HTML ... then make the framing code just deal with hashchange events?!
* Simply drawing on the background could trigger widgets.
* Widgets should "receive" links and have other input/output *nodes* to route messages (instead of the current mess of relaying ALL messages).
* Different kinds of widgets should exist:
* Viewer (as in iframe, but then better -- ie pdf.js)
* Think how link clicking can map into a TEXT document.
* Widget: Close box
* Editor: hide + extend the options!
* Editor: status: temporary overlay
* Widget: Need font with case (can't check the filenames!)
* Widget: Z-Indexing! (as they overlap!)
* File selection (via icons) + actions (such as delete)... rename with search / replace & patterns (regexp!)
* CRUCIAL: refresh listing without reloading page (and losing widgets!)
* etherpad widget/viewer/editor (or could a similar experience occur somehow directly ?!?!)
Maybe need to make a choice:
* Widgets are all about producing rich editing experiences with interacting components (view + text edit)
* Widgets are about publishing static documents, new ways of writing.
* Or do both of these things work together (rather than need to be split)?
SHOUT OUT TO WEBSTALKER!
WRITING WITH CODE
(promiscuous is a performative writing environment)
23 nov 2016
-----------
* Enabled operation without makefile
* iframe widget
* move fragment code from player to "iframe"(frame) widget
22 nov 2016
---------------
* <s>Rehookup index.cgi as directory listing</s> -- actually this became a proper class (no CGI!)
* <s>Add a frame creator widget (via mini tool palette!)</s> POC complete, now for the real deal
* make sure drag and drop works with this (to enable play & edit!)
* ensure frame messages working
* Eventually remove the cgi-bin!? ... need to transition to HTTP VERBS? (POST for save?)
* 4 Nov 2016: Switch from hard coded directory listing to one that's makefile driven (indexical!)
* 4 Nov 2016: REMOVAL of jinja2 dependency!
* 14 Nov 2016: Change to simplified single makefile
......@@ -19,18 +69,3 @@ Next step?
(later: I realize that this data join stuff was best separate from the main line of the makefile based server and can better be split off and developed on it raises quite a few questions on it's own)
22 nov 2016
---------------
* <s>Rehookup index.cgi as directory listing</s> -- actually this became a proper class (no CGI!)
* <s>Add a frame creator widget (via mini tool palette!)</s> POC complete, now for the real deal
* make sure drag and drop works with this (to enable play & edit!)
* ensure frame messages working
* Eventually remove the cgi-bin!? ... need to transition to HTTP VERBS? (POST for save?)
23 nov 2016
-----------
* Enabled operation without makefile
* iframe widget
* move fragment code from player to "iframe"(frame) widget
cookbook
makeserver
=========
......@@ -10,9 +10,9 @@ cookbook
we create new TOOLS to manipulate the material we work with
cookbook is a python web server that incorporates the spirit of the wiki with a file-system oriented workflow drawing on the tools of software development. The server: (1) uses *make* to manage dynamic resources as *potential* transformations of files, triggering scripts *as needed* in the course of browsing, (2) uses *git* to enable navigable histories of sets of files. In essence, cookbook doesn't replace or claim to do more than what make or git do already, it just situates them the browser in a way that makes their operation more like that of a CMS or browsing the web. It acts as glue between javascript code and scripts by allowing authors to create web pages that refer to potential files that are then generated as needed according to the specific recipes of a makefile. In sum cookbook supports a paradigm of web development that's both tried and true (makefile and git-based workflows) and novel being (in part) driven by the webbrowser rather than exclusively the commandline.
makeserver is a python web server that incorporates the spirit of the wiki with a file-system oriented workflow drawing on the tools of software development. The server: (1) uses *make* to manage dynamic resources as *potential* transformations of files, triggering scripts *as needed* in the course of browsing, (2) uses *git* to enable navigable histories of sets of files. In essence, makeserver doesn't replace or claim to do more than what make or git do already, it just situates them the browser in a way that makes their operation more like that of a CMS or browsing the web. It acts as glue between javascript code and scripts by allowing authors to create web pages that refer to potential files that are then generated as needed according to the specific recipes of a makefile. In sum makeserver supports a paradigm of web development that's both tried and true (makefile and git-based workflows) and novel being (in part) driven by the webbrowser rather than exclusively the commandline.
By operating on (and producing) static files, cookbook operates as a kind of *scaffolding-server* whereby editors generate and shape resources by browsing them via the cookbook development server. In the process this produces archival results viewable (in parallel) via a traditional static web server. In this way the project is a *framework* for making [static site generators](https://www.staticgen.com/). SSGs provide an alternative to CGI / LAMP / or other dynamic web publishing paradigms where server side code is implicated in all resource views. It is a *framework* in that rather than being defined for a specific purpose (blog posts, photo gallery, etc), the actual form of the website generated is determined by the contents of the itself malleable makefile and the scripts employed therein. In this way cookbook, though itself implemented in python, is language and tool agnostic (like a makefile).
By operating on (and producing) static files, makeserver operates as a kind of *scaffolding-server* whereby editors generate and shape resources by browsing them via the makeserver development server. In the process this produces archival results viewable (in parallel) via a traditional static web server. In this way the project is a *framework* for making [static site generators](https://www.staticgen.com/). SSGs provide an alternative to CGI / LAMP / or other dynamic web publishing paradigms where server side code is implicated in all resource views. It is a *framework* in that rather than being defined for a specific purpose (blog posts, photo gallery, etc), the actual form of the website generated is determined by the contents of the itself malleable makefile and the scripts employed therein. In this way makeserver, though itself implemented in python, is language and tool agnostic (like a makefile).
The server is designed to be used both (1) *small scale* ad-hoc mode, running as needed over on a local machine, offline, for an individual or small group on a local network, and (2) online as a parallel server for editors.
......@@ -27,7 +27,7 @@ Some Design Goals
* Static by default: Generate resources that are "archival" in the sense of being -- in static form -- stable, add dynamic / external dependecies via scripts in a way that gracefully fails when these services are (no longer) available.
* Discoverability: Be a framework that makes helps non-programmers and novice programmers work comfortably with tools traditionally available through the commandline
* Bootstrap other web development processes: By using makefiles (and starting from some other tried and true recipes), the goal is to start projects quickly. As the project develops, scripts can be iteratively tuned and (re)developed to match. Eventually, projects may well best be deployed with other forms of online services.
* Mixability: Embody a laterally composed system (as opposed to a monolithic/silo style service) Besides use via the built in server, components of cookbook are designed to be usable separately, mixed and matched as needed, and deployed as cgi+javascripts.
* Mixability: Embody a laterally composed system (as opposed to a monolithic/silo style service) Besides use via the built in server, components of makeserver are designed to be usable separately, mixed and matched as needed, and deployed as cgi+javascripts.
FAQ
......@@ -37,7 +37,7 @@ Q: Oh, so it's yet-another-markdown-based-static-site-generator.
A: Well, it could be used to do that, but actually it depends on the rules you put in your makefile.
Q: Makefile, yeeeeeck. That's like from the 70s!
A: Indeed, make was first released by Stuart Feldman in 1977. In a world where software platforms come and go with alarming frequency, it's interesting to look at tools that somehow manage to persist for decades. The version of make used by cookbook is [GNU Make](https://www.gnu.org/software/make/), that's at the heart of any modern GNU+Linux system.
A: Indeed, make was first released by Stuart Feldman in 1977. In a world where software platforms come and go with alarming frequency, it's interesting to look at tools that somehow manage to persist for decades. The version of make used by makeserver is [GNU Make](https://www.gnu.org/software/make/), that's at the heart of any modern GNU+Linux system.
Q: Oh, so it's an editor?
A: Not exactly, though it does incorporate the ace.js project to provide browser-based file editing and viewing with syntax coloring.
......@@ -101,7 +101,7 @@ Single makefile
----------------
After encountering a subtle bug with the "cascading makefile" system, making decision to try a simple single makefile (either explicitly specified, or defaulting to ./makefile).
Problem: "index_.html" exists in the subdirectory 2016-10-05. There's also a (local) makefile in 2016-10-05 which is being detected by cookbook. When this makefile is --question'ed, make returns 0 (instead of 2) because make --question of a file which exists will always be 0 when the file in questions is NOT a target of the makefile.
Problem: "index_.html" exists in the subdirectory 2016-10-05. There's also a (local) makefile in 2016-10-05 which is being detected by makeserver. When this makefile is --question'ed, make returns 0 (instead of 2) because make --question of a file which exists will always be 0 when the file in questions is NOT a target of the makefile.
QUESTION the usefulness of multiple levels of makefiles ... it's creating confusion! ... A SIMPLE (but maybe too drastic) solution: Assume a single makefile, default is any one in the root of the webserver. Eventually other processes can be run for sub directories.
......
#!/usr/bin/env python
# from cookbook import serve
from cookbook import make_server
from makeserver import make_server
# serve.main()
make_server.main()
......
Subproject commit 6e27a1b72e383c1ff0e4da8b8ba6c3085dafafca
Subproject commit d2f2e378eaac05f70300048410ed3469f2ea8fd7
Subproject commit 6e6d920e05b73561ec7bd8e37a9bd65b34d7e1e0
Subproject commit 72481c2bed958bf7728f092445a0e4dfb4f45936
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment