Rethinking GLK’s C API: A Message-Based Protocol for Better Capability Negotiation

I feel like I should stay out of this, since my bias is that Glk is fine the way it is. Mostly. Give or take a few feature ideas. :)

The GlkOte protocol is, and should remain, an implementation detail

I’d say it’s co-equal to the C API at this point.

It doesn’t restrict what you could do in a Glk implementation (though real time effects are tricky), nor does it enable things that couldn’t be done without it.

I agree with that though. Keeping them equivalent is now a design goal.

This reminds me that I should finish documenting the image scaling extension (Glk: Image scaling in buffer windows) and release it officially.

4 Likes