Updated 29 May 2021
What is a blocki? See About this Blocki.
What software does a blocki need, and not need, to make it easy to set up and use? This one is built on nothing more than a web server, text editor, HTML and CSS, and consequently is clunky and limited for both author and reader. How to do better? Some incomplete thoughts follow.
There are three main classes of user: admin, creator and reader:
Most of the basics are covered by standards-compliant web servers and browsers. HTTPS has become the standard access protocol for almost all remote content. HTML and CSS provide the remaining text functionality after a fashion (and SVG + MathML the diagramming and equations), but with some key shortfalls.
One way forward is to improve the tools I already use, i.e. HTML and CSS, along the lines set out in my HTML 5 Sucks study. Even a local search facility could be implemented in my "Cascasding Simple Smarts" realignment of CSS, without the need to access anything outside the immediate sandbox of the blocki pages; think of it as an additional widget for web forms. A selection of navigation templates and CSS stylesheets would then be all that was needed for many a site creator.
Of course, all this is bound to remain clunky for some users. The ideal would be to develop an easy markup language encompassing both HTML, CSS and the necessary smart functions, such as panscript, and code up a dedicated client-side blocki site designer and maintainer. Panscript will have a Turing-complete programming subset, so the client tool should be compiled from panscript source. Any active code present in the content it processes will be treated as passive content for display.
Any viable blocki standard must engage in three distinct work strands:
Cookies can be useful in giving the user a consistent experience. But client-side cookies are in general no longer trustworthy and tend to get turned off. Cloud-held data swaps one set of risks for another. User preferences are best held server-side, where they can be managed securely alongside their login credentials. Client- and cloud-held repositories can then be offered as options via linking from the server-side preferences, for those users who prefer it that way.
This and other server-side smarts such as search indexing would end up associated with small databases. To what extent should these be maintained off-blocki by a suitable service, or brought into the blocki site space via flat-file csv and similar formats? In-blocki is attractive for its low service overheads and ease of assistive text-based editing.
Can a web server be relied on to block crawlers, bots and other spyware from areas containing sensitive private information in blocki space, or to implement them with an encrypted filesystem? The blocki owner probably has no control over all that, so the generic answer has to be "no". So all that would ideally be managed by dedicated blocki software. The alternative is to leave it up to the provider and caveat emptor - let the prospective user read the small print if they care.
These are things that might be added server- or client-side. Ideally, server-side stuff would be backported to the web server, e.g. as an Apache module, rather than as a bespoke service such as Wordpress. Similarly, client-side features might be backported to the browser.
Indexing and searching. The server maintains searchable/clickable indexes of page content, images and media. When a page is uploaded, the server updates the indexes. The visitor can search or browse the indexes and click through. Would the search algorithm run server- or client-side? Might both be useful, depending on whether the user has opened the index for browsing or not? Client-side can use the browser's search, server-side would only be needed if the index is not opened first and so is not essential.
Site content lists and keywords. The server maintains a clickable list of all articles, sorted alphanumerically. Keywords added to the page by the author may be used to auto-build hierarchical listings by subject, perhaps also a tag cloud, etc.
This is just a notional roadmap towards a viable blocki solution. Almost certainly no more than one grumpy old git's fantasy.
v0.2 This adds a client-side blocki creation and maintenance tool. Its initial purpose is to remove HTML/CSS coding skills from the site desiger and content creator, and is therefore a basic but user-friendly web page editor with a targeted set of features. Later iterations would introduce a simple tag search, list/link html file builder and viewer/page selector display, allowing the creator to tag content and thus supplement or even generate the structured navigation. A tag list template allows the creation and editing of tag/link lists using other tools, including hand coding.
v0.3 Functionally unchanged from v0.2, but implemented in compiled panscript. This implies the development of a suitable compiler which is, in all but name, where the dream parts with sanity.
v1.0 Content creators may write in panscript, with much enhanced transclusion and navigation features. The creation tool automatically transcludes subsidiary content and converts the page to HTML+CSS, when uploading to the live site. Hand-coding of v0.1 pages is unaffected.
v2.0.x... Server-side desirable features standardised via RfC or similar and fed upstream to OSS web servers such as Apache, well-behaved menu features and selected ideas from HTML5 Sucks incorporated into CSS.