3 ms·

Thanks for the clarification. Hmm, I think I'm still not phrasing this clearly. I didn't mean to call for better-designed APIs, just unfrozen interfaces. When t

Thanks for the clarification. Hmm, I think I'm still not phrasing this clearly. I didn't mean to call for better-designed APIs, just unfrozen interfaces. When things break, make a change and put it out there. I don't think this has to be a faster/better dichotomy. Imagine a world without the notion of a stable API. Over time, some interfaces may accumulate changes and gradually remain unchanged for longer and longer periods. Eventually they stay stable so long that we can de facto start treating them like APIs. It seems a perfectly natural evolution.

ChuckMcM 14y ago
That is pretty clear, it's the 'rapidly evolving' path. And it works fine except that you end up with API's with things like ReadFromStream, ReadFromMemoryOrStream, ReadFromStreamGeneric, Etc. which one might "want" to say ok the generic is "ReadFromStream" and the various sub-classes of that can be differentiated within the structure of the first argument. And after a few months, years (depending on evolution speed) you get an API that has a number of slightly different APIs, many deprecated, and none "the best", and someone new comes along and gets frustrated and writes a whole new library with a new generic API. And this process doesn't feel too bad to the folks who are primary users but the secondary users of an API see a lot of churn which keeps requiring them to rebuild and re-release code that isn't otherwise changed and for them it is painful. I'm not sure what your experience is like in this area but my most recent one has been trying to do 'outside of X11' graphics on an embedded ARM system running Linux. All of them can mmap /dev/fb0 and do very slow drawing, some use EGL, some drm/kms, some Wayland or an OpenGL ES library. But all different and yet all, in theory, running Linux. There are many competing camps making 'APIs' for direct render graphics and they all have their own quirks and goals. But there isn't any way for everyone to sit down and say, "Ok, lets see what is what." and design a reasonably clean and yet extensible API with nice versioning and a core set of features.
- akkartik 14y ago
  Most interesting. Are all the different options open source? I'd love pointers to them all, so I can try to put myself in your shoes.

ChuckMcM 14y ago

That is pretty clear, it's the 'rapidly evolving' path. And it works fine except that you end up with API's with things like ReadFromStream, ReadFromMemoryOrStream, ReadFromStreamGeneric, Etc. which one might "want" to say ok the generic is "ReadFromStream" and the various sub-classes of that can be differentiated within the structure of the first argument. And after a few months, years (depending on evolution speed) you get an API that has a number of slightly different APIs, many deprecated, and none "the best", and someone new comes along and gets frustrated and writes a whole new library with a new generic API. And this process doesn't feel too bad to the folks who are primary users but the secondary users of an API see a lot of churn which keeps requiring them to rebuild and re-release code that isn't otherwise changed and for them it is painful. I'm not sure what your experience is like in this area but my most recent one has been trying to do 'outside of X11' graphics on an embedded ARM system running Linux. All of them can mmap /dev/fb0 and do very slow drawing, some use EGL, some drm/kms, some Wayland or an OpenGL ES library. But all different and yet all, in theory, running Linux. There are many competing camps making 'APIs' for direct render graphics and they all have their own quirks and goals. But there isn't any way for everyone to sit down and say, "Ok, lets see what is what." and design a reasonably clean and yet extensible API with nice versioning and a core set of features.

akkartik 14y ago
Most interesting. Are all the different options open source? I'd love pointers to them all, so I can try to put myself in your shoes.