Wilm0r
commented
7 years ago So, the recent wave of ICS-formatted submissions has me thinking about this as well. I've never really wanted [XI]CS to become a first-class citizen in Giggity because it's very poor on metadata and Giggity can only apply some heuristics to try to make it look nice.
(Honestly that problem in some ways even exists with Pentabarf - or really mostly in the way the long descriptions are written. Some schedules use HTML there, some use Markdown of some sort, but you just have to make guesses on what it is, it's not like there's a MIME-type or something - remember the days of MSIE4 rendering HTML as HTML even if the MIME-type was wrong, as a gesture of helpfulness? :-/)
Anyway, I wonder whether we'd be better off having separate code that could get some help on the heuristics (as-in we'll see how that file combined 3 different things into talk titles and supply a regex or something to pull it apart), take in more than just ICS/XCS, and emit a more digested file for Giggity to use?
Note that this thing kind of exists already in fact! https://github.com/Wilm0r/giggity/tree/master/tools/dance_valley has it, and right now it's a generator for the old Giggity-native format, though I haven't used that in ages.
The structure there is just class Schedule(GiggityObject) which you populate by doing whatever terriblesness needed to parse your input, then invoke its xml() function to serialise. And yeah, the code is messy, also most of it is 9y old. :-D
mmuman
Zverik
Following #29 , I just found MozFest that uses yet another thing for their program, which uses some custom JSON format.
Last summer I attended a workshop at RMLL where we discussed events schedule curation for websites like radar.squat.net. I mentioned Giggity on the notes we took.
I think we should collaborate instead of reimplementing the same parsers N times. It's probably simpler to add events to some website supporting known formats and point Giggity to it when the event website doesn't provide a suitable format.