Add RSS/Atom

[jasonm]

@cssboy lazily asked for this in campfire

so I'm pinging him here.

Angelo, what are you thinking? A feed-per-city of the events? They're currently unstructured right now:

https://raw.github.com/OpenHack/openhack.github.com/master/boston/index.markdown

but if they adhere to convention, then a fancy-pants script could probably fabricate some RSSification.

[imrehg]

It would be nice to have something like this, if we can figure out a way.

Also, if we do, let's make sure it is compatible with calendar applications (such as Google Calendar) right away. That would make it really useful.

[jasonm]

@imrehg do you have a link to what gcal/etc would need, and what that integration would provide? Would it need to be e.g. http://microformats.org/wiki/hcalendar ?

[imrehg]

@jasonm I have seen ics/iCalendar support more often, here's the list of software supporting it

As much as I understand hcalendar (and other microformats), it would be more like that the search engines can understand it, and display it: eg. someone searches for Openhack Taipei on Google, and it would return with results of This is the page, and by the way, there's an event on 2013 Feb 2 . See this announcement. This would be awesome as well, by the way, every customized search result (i.e. correctly used microformats) reflects somehow so much more professional on the website it belongs to. :)

[jasonm]

@qrush would you be open to an additional build step that extracts dates from markdown entires and builds static RSS/Atom/ICS feeds?

[jasonm]

Here's a quick hack that pulls some events: https://gist.github.com/4537061 assuming people follow the "### Next Meetups: ..." format like in this one.

I also mentioned which cities do not match that style, and what other styles I found while looking through each page.

[imrehg]

@jasonm I implemented in a preliminary hacky way the hcalendar thing for Openhack Taipei, so in the search results it shows up now as an event (can search, or see a screenshot).

Of course it is just horrible ugly HTML in there, ruining the nice markdown, just wanted to figure out a reference implementation that works.

Thus the feed / hcalendar are two different things. Feed could only be a global feature (meaning needs central agreement), hcalendar can be done by the individual pages themselves if they want/need it.

[qrush]

Could we do something more manual? Is there an open/wikiable calendaring system we can use?

[jasonm]

So there are 2 things going on here:

• hCalendar microformat like @imrehg implemented. This is HTML that can reside in the page
• RSS/iCal feeds. These would be separate files that must be built, like jekyll currently builds HTML from the markdown source.

The hCalendar can be done manually, as @imrehg illustrated, though it kinda crufts up the markdown source. There is a discussion from 2006 about making an hCal extension to Markdown (see "Markdown and the hCal microformat" thread), but there is no software I can find to automate this.

Even so, there is some nice discussion in that thread for Markdown-friendly syntax that gets built into hCal. Does anyone know about markdown extensions? Curious if @gettalong (Kramdown author) or @jgm (Pandoc author) are aware of anything related?

The RSS/iCal feeds would need to be built separately, much like jekyll builds the HTML. Maybe it could be built into jekyll, I don't know enough about it to know. Single-source-to-multiple-outputs seems like a pandoc sweet spot, FWIW.

[jgm]

I'm not aware of anything related.

[gettalong]

I'm also not aware of anything hCal related.

It would probably be easier for you to define a special syntax for the OpenHack website that needs no changes in Markdown and that everyone should follow.

Depending on the specific Markdown version you use, you could define that the events that should be in the hCalendar are

• in a list preceded by a header with text "Events"
• each entry in the list is an event
• each event has a certain structure (like first part until the first comma is date, until the next comma location, ...)

This would have the benefit that it is still easily transformable into readable HTML even if your post-transformation pipeline to hCal is not used.

I once wrote something like this for issue tracking, here is the documentation: http://webgen.rubyforge.org/documentation/0.4.x/documentation/references/sipttra_format.html