[cairo] Updated ROADMAP for cairo 1.2.0 (and beyond)
andreas.raab at gmx.de
Thu Apr 27 12:06:06 PDT 2006
> Does that make sense?
In a world of statically compiled single binaries, yes. In a world of
dynamically loadable modules, no. You can't omit the runtime check
however hard you try if you can't foresee what clients have installed on
their machine (e.g., there simply is no "compilation-time verification
that the functionality exists" other than on the one machine you compile
it on). It's fine if you want to use this in addition to the necessary
runtime checks but if you're trying to replace the runtime checks
entirely that would get problematic very quickly.
Carl Worth wrote:
> On Thu, 27 Apr 2006 16:50:47 +0200, Adib Taraben wrote:
>> So this means every new version you change the API?
> Yes. If cairo gets new functionality to target a new version, then the
> application will have to change to start taking advantage of that new
> functionality. This really isn't different than any other
>> I would prefer this:
>> cairo_svg_surface_create_1_2 (int major_version, int minor_version)
>> If you would really prevent enums or strings.
> While the numeric nature of the interface is nice, this doesn't
> actually advertise what guarantees cairo is making for the application
> For example, Emmanuel's initial implementation of the SVG backend
> would emit SVG using features from SVG 1.2. What he has now
> implemented is new functionality that allows this backend to restrict
> itself to using only features available in SVG 1.1.
> Now let's imagine we had one cairo release of the original (1.2 only)
> stuff and a subsequent one with the (1.1 or 1.2) stuff. What's an
> application that requires the 1.1 restriction supposed to do here?
> With a single, numeric API as above, the best the application can do
> is call the function, hope it works, and carefully handle a run-time
> error if it fails.
> However, by associating the new functionality with new API, we now get
> compilation-time verification that the functionality exists, (perhaps
> link-time failure in case of a broken installation), and no need to
> introduce any run-time error for this.
> The earlier the error checks are, (in the sense of compile-time
> vs. run-time), the better.
> Does that make sense?
> cairo mailing list
> cairo at cairographics.org
More information about the cairo