Awesome! So you need someone to take a look at the code, make it multi-platform and put it in Gargoyle? Any links to your repo by chance?
Thanks a bunch 
Yes, that’s the plan, roughly speaking. Not necessarily “make it”, but I’ll need mentoring at least.
Not yet because we were clearing up some license issues, but I’ll post links and questions about new Gargoyle code in the other thread.
I just went through mulehollandaise’s TODO list (ifwiki.org/index.php/User:Muleho … eters_TODO), reorganizing and adding notes from my own (long-standing) TODO lists.
I threw in dev tools (Inform compiler and library), too. And I added links to project pages and bug trackers.
Time to promote this to a top-level “IF Task List” wiki page?
Awesome, thanks so much! 
I also added Vorple stuff from Juhana’s website (‘known limitations’).
Should we split that up in three pages? (dev tools, interpreters and website-related?)
Don’t think it’s that big yet. It’s nice to have an overview that someone can read through.
Ok, looking over the to-do list:
Inform 7:
What, specifically, is needed? Replacements for all the existing hyperlink extensions, to make them compatible with UGI? Is anyone in particular planning to take care of this, or can anyone jump in?
IFDB:
Is checking to make sure you’ve got the correct opening screen, and tweaking this, something a non-programmer could do, or at least help with? Is checking the screenshots something that could be set up for anyone to contribute to, piecemeal, as they have time (e.g. there’s a queue, and you just click a check box to approve the screenshot, or not?)
Web sites:
As long as we’ve got web sites on the list, what about add something along the lines of cvaneseltine’s suggestion of a tool that would allow adding games to IFWiki without duplicating the effort of adding them to IFDB?
The easy task is to port the existing hyperlink and menu extensions over to UGI.
The hard task is to design a state model for choice-based games which is as powerful and easy to use as possible. How hard this is depends on how ambitious you are. 
This might be as flexible (and hard to finish) as Threaded Conversation.
Ideally, all of these are things that a non-programmer could do. However, setting up a system where people can contribute to this is a chunk of programming work in itself. None of it exists yet – I just have a demo that runs off a cruddy config file.
Add away.
I’ll have a think if there are other open tasks that could be added to the list.
Zarf, quick question, how much work would it take to add the option of multiple timers to Glk? By that I mean both speccing it and the relative difficulty of changing the common Glk implementations.
Um. It’s not intrinsically hard to design, but the API would be messier than the current one. You’d need the timer call to return a value which could be used to cancel that particular timer. Implementation wouldn’t be fun.
I know you said you wanted this for “debouncing” window size changes. However, it’s going to be easier to update an interpreter to support that directly than to stuff the functionality into GEP. Having every game run a rapid timer loop behind the author’s back is just not the right way to do things.
The current timer call assumes the input code is self-contained, which doesn’t fit well with GEP. But all of Glk’s input API assumes that. I’m not very motivated to update just one piece this way.
Well most of the terps are badly maintained. We really needed debouncing for Kerkerkruip because of the number of windows it had, and so I’ve already added debouncing to GEP, but its code would be simpler if multiple timers were available. It wouldn’t run constant timer loops, but set up a single timer after the first resize event for 100ms or so. Any resize events that came in before the timer event would check if the timer is running and be ignored.
Multiple timers would have other uses too. Animations of course, but also the stuff Erik wrote his Glulx Real Time extension for. But I think it would really be most useful for just allowing extensions which use timers to operate independently.
Do you mean that glk_request_timer_events() would return an id? I was instead thinking that you would call glk_request_timer_events(millisecs, rock). (Or an alternative function so that the arity wouldn’t be changed.) You would call glk_request_timer_events(0, rock) to turn it off. The rock value would be returned as the event val1. Subsequent calls with the same rock would update the period of that timer, rather than making new timers, and the existing calls could be interpreted as calling with a rock of 0. I don’t think this would be too messy?
Anyways, it’s not essential by any means. We’ve been making do without. But if it’s not too complex then it could be worth adding to the next Glk update, whenever that comes along.
I’m trying to picture the logic for a client-server relationship where timers are concerned.
If we assume the story file manages what timers are “on” and knows their information (expire date-time and a command are the only important data to emit to the client), then if the client knows the list of timers and expiration date-times, it can do what needs to be done.
I’m not really concerned about standard interpreters these days, but for web implementations this seems relatively easy. We just need to emit something to the browser that gets “scraped” out of normal output and tells a JS file to manage the list of emitted timers. When one expires, its command is fired.
For FyreVM this would be trivial. Have a dedicated channel for timer data. The client then manages its timers based on that channel, which could be a JSON payload with all of the pertinent information.
(I’m really just thinking out loud about an extension I’d add to my list of things to do…a fyrevm web timers I7 extension)
This quote struck me because I just started a new thread about clout (or lack thereof) in the IF community, and your term ‘foundation’ in reference to herding cats is pretty on point.
I’d like to see a bunch of the heavy hitters around here form some type of concensus about what needs to be done to bring interpreters into ‘spec’ on all platforms, for all story files, etc. and what the best candidate for doing so would be.
An up-to-date, well-maintained, universal interpreter seems to be a likely unifying goal around here, given that it will benefit everyone and not just users of certain platforms / target audiences / authoring systems.
If anyone has any solid ideas for organizing such a foundation, I’d be willing in investing some time & $$$ in helping to herd those cats.