[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Framework shlib versioning
Re: [PATCH] Framework shlib versioning
Mon, 19 Jan 2004 10:45:48 +0000 (GMT)
> > > The shared libraries are binary-compatible, but the shlib is not the
> > > whole of the framework, and maybe not even the most important part of
> > > it (a framework needn't always have classes -- it may be only
> > > resources and/or headers). Framework resources (or for that matter,
> > > any bundle's) are not internal to its code, but part of the interface
> > It depends. Resource files, just like symbols in object code, can be
> > either public or private. Making an assumption that all resource files
> > are public is as wrong as assuming they are all private.
> It's not an assumption -- it's part and parcel of how frameworks work. A
> framework's interface version applies both to resources and to shared
> objects contained in it. Resources are always public, and you can't "take
> them private".
The same applies to ObjC classes or methods then. There is no way to
"take them private". The determined user of the framework can always get
a list of them, and access any of them if he really wants.
I still claim part of the ObjC classes and methods can be considered
private (just do not document them in the description of the public API,
or add clear comments that they are private), and can be changed without a
need to raise the interface version (of course, if you don't make the new
release binary-incompatible with the previous one ...).
Exactly the same happens with resources, I can't honestly see any
For example, gnustep-gui has got images which are internally used to draw.
Most of them are not at all public, and their names or location could
change without notice and you don't need to recompile your gnustep-gui
application because of that - unless you're accessing the images directly,
which you shouldn't be doing anyway, unless they are documented as public.
They could even disappear and be replaced by low-level drawing commands or
some other mechanism which in that instance might be better or more
efficient to get the same result. The way the framework is drawing
(copying from multiple images ? copying from a single image ? using
drawing commands directly ?) is an implementation detail which doesn't
affect the public API.
> You can put something in the docs saying that developers
> using the framework shouldn't depend on foo.plist having particular contents
> (or whatever), but nothing in a framework's resources is ever private.
Why not ? What's wrong with having private framework resources ? I
actually thought that would be the most common case. I don't understand
why you insist that everything *must* be public, as that makes frameworks
a lot less interesting to me.
So what would I have to do if I do have a private resource file ? It
can't be stored in the framework then, and I'd need to create a new
directory somewhere on disk outside the framework to install it ?
An encryption or math computation framework might have mathematical tables
stored in files (or precompiled in files in some way) as part of his
resources. You can consider those tables part of the algorithm internals,
they are private, as they'd change when the algorithm internals change,
without affecting the public API, so you should not assume they're public.
For example, if I remember correctly, gnustep-base does have pre-compiled
binary dumps of some NSCharacterSets. By loading the binary dump files
rather than creating them every time, it can do things faster. That
doesn't mean the binary dump files are part of the public API. They are
resources internally used by the library/framework to implement its public
NSCharacterSet ObjC API. What's wrong with having those private files ?
If after profiling we find they are actually slowing everything down, we
could remove all of them and rewrite the library internals not to use
them. The resulting release might be binary-compatible with the previous
one (I don't know the details, but it might well be) - it'd just be faster
/ have a different internal implementations. The public API / binary
compatibility is not changed. (maybe in practice it's not exactly this
way, I was trying to express the idea).
Or maybe an Octave/Matlab-like framework would have a core kernel written
in C and then a set of functions implemented in the math interpreted
language supplied by the framework. That's how something like Octave
actually works. The framework resources might contain a vast variety of
files in the interpreted language implementing common functions and
features built on top of the kernel ones. While the functions are part of
the public API (in the interpreted language), that doesn't necessarily
mean the names of the specific files implementing the functions, or their
location, is public. I guess it depends on how the thing works, but part
of the files would probably be automatically loaded or searched at
runtime, so you don't (and should not) access them directly.
Of course, images and sounds as well could be private. You could have
images internally used by framework functions, or sound samples internally
used by a midi framework to render midi files. The way the sound samples
are organized, named or changed might well be part of the private
implementation of the framework. The public ObjC API would let you render
a midi file, and internally the implementation would use some private
sound samples in the way it sees fit. I can't see anything wrong with it.
How the private resources are marked as private depends on the framework's
author, and it's not our task to judge. Maybe they just put them in a
Private/ subdirectory if there are Public resources, or in some cases it
might be all resources are private, or in some cases it might be all
resources are public. Who are we to interfere with the developer's
> > Developers should be free to choose their own policies and to decide if
> > a change in the resources affects the interface version or not.
> They are, just as a developer is free to make a library binary-incompatible
> without revving the soversion.
Changing the resources internally/privately used by the framework to
perform some of its functions does not necessarily make the new release
binary-incompatible with the previous one.
> > But the main point I think is just that when you install a new version,
> > no matter if API compatible or not, you must not overwrite the old
> > version.
Because otherwise you can't have the two versions installed at the same
> And I didn't say API-compatible, I said binary-compatible, meaning
> "works with all binaries that were compiled with old version". API
> compatibility, that's a different issue entirely. :)
They are not the same thing for shared files, but for resources they are
the same thing.
There is a "public API" for resources as well, which tells you which
resources you can access and what they are. A new release of a framework
is 'binary incompatible' with the previous one in terms of resources if
the location/name/function of the public resources changes. The releases
are binary incompatible because you'd potentially have to modify any
application using the framework, and recompile it.
Otherwise, if you rename a private resource file, modify the name used in
the framework code to access it (without making it binary-incompatible),
and recompile and reinstall the framework, you should get something which
is binary compatible with the previous one, meaning you don't need to
recompile anything using the framework.
Btw, at this point I'm curious and I'd like to know how this is done on
Apple. If you make release 1.5.3 and install it, would that overwrite the
resources of already-installed release 1.5.2 ?
(NB: I'd still claim it's wrong even if they do it that way, I was just
Anyone knows ?
- Re: [PATCH] Framework shlib versioning, (continued)
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/12
- Re: [PATCH] Framework shlib versioning, Dennis Leeuw, 2004/01/12
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/12
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/14
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/15
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/16
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/17
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/17
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/19
- Re: [PATCH] Framework shlib versioning,
Nicola Pero <=
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/27
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/29