This was originally an email to the Haskell web-devel list and was also posted on Reddit.

Somebody claiming to be yi huang wrote:

Why prefer code generation over template Haskell? Isn’t them essentially the same thing, and template haskell is performed automatically.

Also, from Reddit (nicolast):

I never understood why someone would want to avoid using language extensions which have been in GHC for at least some time. The only reason I can think of is: compatibility with other compilers. But is anyone ever going to compile/run a yesod-routes based application using something other than GHC?!

First off, yes, Template Haskell is very similar to code generation. There are a few reasons I would like to avoid it.

It’s a language extension. I try to avoid those in general, in every stanardized language I code in (C89, R5RS, Haskell98) for several reasons.

As nicolast said, compatibility with other compilers is a big one. When I get a piece of code from someone who assumed that “what MSVC does” or “what Racket does” is the same as “anyone can run this”, it makes it quite difficult to use my favourite implementations of those languages. I don’t want to make assumptions about other people’s environments, or what will be useful in the future. Maybe someone writes a Haskell interpreter that makes use in some context I haven’t even imagined much nicer. Who knows.

Additionally, any other static analysis/code processing tools (like, say, hlint) *also* needs to support whatever syntax extensions you’re using (semantics extensions may or may not apply here, depending on the nature of the tool). Requiring that every tool author support all my favourite extensions limits my tool options, and makes life harder for tool authors (since they cannot just look in one place for the spec and write to that anymore if they need to look up compilers’ extensions as well).

Will anyone ever compile/run/analyze a yesod-routes based application using something other than GHC/hlint? (Actually, does hlint support TH? It might.) What specifically about yesod-routes makes this less likely? What drew me to Yesod.Routes.Dispatch was its relative purity in terms of extensions/dependencies, etc.

Additionally, I find Template Haskell specifically (and some other language extensions, like Overlapping Instances) can make code harder to read (for me) and possibly harder to reason about. A code generator makes a file that I can read for comprehension, edit if I want to, etc.

Ok, that’s a bit of a long answer to a short question, but it sort of sums up my motivation vis extensions in general and TH in particular.

Working in the realm of standards (on the web or elsewhere) you eventually realise that there are a lot of terms, not all of which mean what they may initially seem to, or what they are always used for.  This post is an attempt to simply explain some of these common concepts.

Specifications

Or ‘specs’. These are formal documents describing a technology, protocol, or other pattern that may be standardised. A standard cannot exist without a specification, but a specification is not automatically a standard of any kind. Specifications are key in allowing interoperability.

Examples: OAuth, OpenID, EAUT, PortableContacts, HTML4.01, XMPP

Interoperability

Is when two or more implementations of a specification can “talk to” each other, without prior knowledge of the other implementation.

Examples: Psi and Google Talk, Firefox and Opera, USB keys

Implementation

A product, service, or similar that conforms (or claims to conform) to a particular specification.

Standards Body

Or standards organisation. A self-proclaimed shepherd of standards. These bodies hold different amounts of influence with different implementors, based on their membership. Some of these bodies provide resources to those working on specifications they have claimed as “their standards”.

Standards bodies get all of their authority from their membership. These organisations may claim specifications are standards that no one outside them considers to be standards.

Examples: W3C, IETF, OASIS, ISO, ECMA

Open Specification

A specification that has been released to the public under a liberal license.

Standards Community / Open Community

A community that has rallied around a specification or set of specifications. The community seeks to promote and maintain the specifications, and often refers to them as “standards”.

Example: PortableContacts Initiative

An “open” community operates in the open, with transparency into all aspects and discussions. Usually operate on mailing lists and IRC channels.

Example: microformats community

Standard

Not everyone agrees what comprises a “standard”, but many people agree that the term is overused and abused. I will here state my own interpretation of “standard”:

1. A standard has a specification
2. The specification has multiple, independant implementations
3. One or more of these implementations is interoperable
4. One or more of these implementations is libre software
5. One or more of these implementations is “popular”
6. There is an implementation for each relevant platform (OSs, browsers, etc)

Notice that the blessing of a standards body or community is not necessary.

Examples: RTF, HTML4.01, XMPP, H.262

Open Standard

A standard whose specification is an open specification. In addition, the specification should be clear of all patent encumbrances (may be necessary to be considered an open specification).

Examples: OpenID, OAuth, XHTML1.1, microformats

See also: On Language Extensions (in Haskell and Elsewhere)

Since APP (understand here) is mainlined in WordPress, it makes sense to use it in DiSo efforts.  I doubt that my OAuth plugin will work here, but it’s worth testing.  It may mean using headers, but with comment and discovery support we should be able to build a distributed commenting system, at least for WordPress.

I’ve thought about other APIs that would be useful for DiSo.  For example, adding friends or groups.  APP does not fit this, but the general concepts do.  Perhaps APP can be abstracted into more of a CPP.

GET on main endpoint to list items (ATOM can always be the main wrapper here).

POST to main endpoint to create new items.

PUT to node to edit.

DELETE to node to delete.

Authentication unspecified (HTTP Basic or OAuth work well).

If the content of your POST and PUT requests is ATOM, you have AtomPub.  The same basics can easily work with other content.  (The other content types could be encapsulated in ATOM entry bodies on the GET list, or XOXO).

For example, a POST body of XFN+hCard could add a friend.  A PUT body of hCard could edit a profile (ie, to add groups).

I would also like to suggest that POST on a node could be used to add comments (create new content on a content node).

Pempeth is the result of my work based on my previous private messaging TEP.  The protocol draft has matured and there are now implementations! (see the page).  Most notable is a WordPress plugin, active on this site.

The development of that plugin also sparked an XRDS plugin, which I have also released (despite its somewhat cryptic interface).

Those looking at the main page may also have noticed changes. Yes, that’s a mini-feed based on my online activity.  Yes, it’s a plugin.  The interface, however, only allows for adding sources (not editing or removing) and is somewhat cryptic, so I have not released it yet.

You can also now log into my blog with your Facebook account (see link in header)!  This uses the API, so I don’t got your Facebook password or anything like that.  Also an as-yet-unreleased plugin.

Fun days!  I’m going to be working at AideRSS as a co-op in the coming months, should be fun and more freeing than school!

I have updated this draft and released some code.

Regular readers of my blog know that I am obsessed with one thing: decentralisation. I hate having all my eggs in one basket. IMHO, if anyone has the ultimate power, then it’s not true Web 2.0. In my recent thinking this has extended to my view of social networks such as Facebook and MySpace.

One of the much-used features of these is personal messages. This can be public (ala Facebook wall) or private (ala Facebook message). I here intend to provide a TEP, which I will implement, suggesting a way to do this in a decentralised and RESTful manner.

Detecting the endpoint

I love XRDS! This format comes to us from the OpenID world but really provides a standard way to associate RESTful endpoints with a URL [example].

I think it makes most sense to have one type URL for this TEP and declare a namespace for extending XRDS to (optionally) tag endpoints with a ‘sub-type’. This could look like the following:

<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:dsn="http://singpolyma.net/dsn/xmlns">

<XRD>

<Service priority="50">

<Type>http://singpolyma.net/dsn/pmt

<URI>http://example.com/msg

<dsn:msgtype>private</dsn:msgtype>

</Service>

</XRD>

</xrds:XRDS>

(I will create these pages in a bit.) I would propose the following dsn:msgtype for now: private (only to you) and public (like Facebook wall). As this is a TEP, nothing is remotely final. I’m not sure I like msgtype as the tag name, for one thing.

Sending Data to the Endpoint

This part is easy. To support maximum compatibility with existing systems, either GET or POST data is to be accepted. All fields passed must be processed. The simplest system will simply take all data passed via both GET and POST and put the field name as a header and the value under/beside it in the message body. No data may be ignored (unless there is a particular value, such as a session ID, specific to your server which you want removed). The following is a list of fields which make sense to use in a special way. If you are going to do something special for one of these values you should use the name given here, but really any data can have anything done with it as long as it is included somewhere in the message.

subject, from (contact of sending user), cc, url (of sending user), name (of sending user), body

XHTML is allowed. Special data (such as calendar events) should be marked up with microformats where possible.

A way to contact the user back SHOULD be supplied. If either from or url is a URL, XRDS discovery can be performed on it in order to detect an endpoint for this TEP to use in replying.

I am going to write some code to implement this both for WordPress and independently soon. I may also create a simple service targeted at adding this capability to a blogger blog (or other locked-hosting website).