Re: [ft-devel] Export services?

[Chia-I Wu]

On Fri, Oct 14, 2005 at 10:11:21PM +0200, David Turner wrote:
> the "wrapper" functions are here to protect the users of the service's
> implementation details. They have various advantages:
> 
> - they expose a "clean" API that doesn't depend on internals of
>  the font engine. Allowing us to redesign services when needed
> 
> - services can be used either internally or to implement a public
>  API.
> in other words, exposing services publicly has many problems:
> 
> - it forces us to expose more internals of the font engine, which
>  means less possibilities for improvements in the future. And
>  it's not like we've not been burned by this already
>  (i.e. FT_OPTIMIZE_MEMORY breaks rogue libraries)
> - it forces us to add a way to distinguish between "internal"
>  and "public" services.
This won't be hard because we can list services like
{ SERVICE_ID, POINTER_TO_FUNCTION, PUBLIC_OR_NOT },
where PUBLIC_OR_NOT is the new field.

An exported service is like an exported function call, once get
exported, it allows no change.  Or we may say it's a way for the modules
to export module-specific API.  Since it is module-specific, I think
it's better exported by the module itself, and not by a wrapper function
in "base".

Currently, wrapper functions in "base" are either simply wrappers, which
are good candicates of services to be exported, or high-level functions
of the services, i.e. they ease the pain of using the low-level
services.  In the latter case, we can hide the low-level service and
export a high-level one, like the wrapper function is.  The bottom line
is, it's a way for the module to export API.

> And I don't see how they could make the engine "more powerful".
Those services I can think of are already wrapped :(

Hmm, maybe we can export the byte interpreter as a service, then a
client can use this service to show how intructions instruct a glyph
vividly.

-- 
Regards,
olv