Story Serialization - issues with expression as URL

[paul90]

The current way the current view into a federation is presented as a URL presents a few issues.

There are two types entry points, URLs like http://fed.wiki.org/welcome-visitors.html, and http://fed.wiki.org/view/welcome-visitors/plugins.fed.wiki.org/about-plugins. http://fed.wiki.org/ is redirected to http://fed.wiki.org/welcome-visitors.html.

• http://fed.wiki.org/welcome-visitors.html, for which the server serves a render HTML page. On loading, if javascript is not disabled, the page will be re-rendered by the client and the URL re-written as http://fed.wiki.org/view/welcome-visitors.
• http://fed.wiki.org/view/welcome-visitors/plugins.fed.wiki.org/about-plugins, which in #411 is represents as the story serialization S( S( S(protocol) - V(://) - O(FQDN) ) - V(view) - O(welcome-visitors) ) - V(FQDN) - O(welcome-visitors). The way such requests are handled by the server, is not to return a single page with the content. But, to serve a page with place holders that the client will populate.

Re-writing the URL has a knock-on effect that an intelligent server is required, the URL does not point directly to a resource that a dumb server can serve. This acts as a barrier to using a cheap 'dumb' server to publish a public view of a private federation, part of #410. Creation of a static server entails saving content (page json, sitemap, etc…), together with the client, in the locations that the client expects to find them.

Some additional issues:

• While the protocol used to access the origin server is indicated, there is no indication of that needed to access those whose FQDN is given. It is hard-coded into the client, assumes http. Becomes a problem if the remote site is https only.
• While not directly related, page names are restricted to subset of the ASCII character set, which presents a barrier to internationalization, I12N. There is probably little reason for not to URL encode page names.

A Proposal

Use fragment identifier, to separate the origin from the list of pages in the lineup. Pages within the lineup being separated with :. For example:

• http://fed.wiki.org/view/welcome-visitors becomes http://fed.wiki.org/#welcome-visitors, and
• http://fed.wiki.org/view/welcome-visitors/view/recent-changes becomes http://fed.wiki.org/#welcome-visitors:recent-changes

Where the page is from a server other than the origin, we need to indicate the page-name together with the FQDN, using = as a separator. For example:

• http://fed.wiki.org/view/welcome-visitors/plugins.fed.wiki.org/about-plugins becomes http://fed.wiki.org/#welcome-visitors:plugins.fed.wiki.org=about-plugins

Server rendered pages retain the http://fed.wiki.org/welcome-visitors.html scheme, and the client must not re-write the URI, or re-render the page. The client should be able to configure link behaviour, so able to explore the federation as a series of static pages without needing to disable javascript.

[WardCunningham]

This advice comes at a very good time. My own summary of server classes ends with the realization:

• Servers shouldn't need to participate in browser history by parsing and echoing lineups.

I've come to this realization in my work with @1337807 on a minimalist federated wiki server in Go where we attempt to stay within core modules and Go centric idioms. Parsing /view/slug/view/slug has been clearly a mis-fit even in this very modern programming environment.

[egonelbre]

Just noticed the Go problem you were having, you can parse /view/alpha/view/beta with

func handler(rw http.ResponseWriter, req *http.Request) {
    tokens := strings.Split(req.URL.Path, "/")[1:]
    // tokens[0] == "view"
    // tokens[1] == "alpha"
    // tokens[2] == "view"
    // tokens[3] == "beta"
}

req.URL.Path contains the pathname as a regular string so you can split/parse it as needed.

[WardCunningham]

Good point. We were a little too attached to regex routing since that is what we had been doing in Sinatra. We do want the added validation provided by regex in the Factory drop logic but that is in the client where it is well supported.

[egonelbre]

There are plenty of different routers that provide different features (e.g. (http://www.gorillatoolkit.org/pkg/mux, https://github.com/bmizerany/pat, and even more https://github.com/vishr/go-http-routing-benchmark). Of course, implementing your own router is trivial https://play.golang.org/p/lXRFobL4GJ (note, code untested and can be made nicer).

[WardCunningham]

Yes, we went down the custom router route. It became more complicated than the rest of the server. I had to stop and ask, what is it about wiki that requires this complexity. My conclusion: nothing. Hence my desire to simplify.