[cairo] Updated ROADMAP for cairo 1.2.0 (and beyond)

[Andreas Raab]

 > 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.

Cheers,
   - Andreas

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
> functionality.
> 
>> 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
> here.
> 
> 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?
> 
> -Carl
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo