Miles Elam wrote:
> > You could call these "soft dependencies", or something similar.
>
> This may be out of scope, but isn't this one of the concepts behind some
> Debian packages? For example, sendmail implements the prerequisite of a
> "mail transport agent" as does postfix and qmail. A program that needs
> a "mail transport agent" (usually a sendmail executable in the path --
> UNIX version of a generic interface?) will have its dependency satisfied
> by any of the above choices.
COM has a concept of dependencies on categories that is exactly the same
as this. In your example, there would be a "mail transport agent"
category, of which sendmail, postfix and qmail would be part. A category
is an agreement on specification and on one or more interfaces.
You are right about your analogy of the sendmail executable (including
agreed upon parameters) in the path, this is one of the closest idea to
a generic interface that I saw.
> I don't have an answer for this -- especially for cross-platform use,
> but maybe the concept can be extrapolated? Default implementations of
> an interface (through ProgID?) and checks at install time for default
> registered implementations of interfaces? By no means trivial but...
I think there is no equivalent to COM categories in XPCOM (XPCOM
categories require a parameter?). But if there was, components could
state what categories they require when registering.
An installation program could verify the dependencies at install time.
But this would be useful only for those using package managers like RPM
or dpkg, because, just like a regular Unix library, nothing prevent the
dependency from disappearing from the system *after* installation time.
The moral of this story is that a component-enabled application should
take precautions when using external components, and taking appropriate
action if a component is not available (degrade service or abord
completely, like ld.so does). I would add that this is not unlike
checking return values all the time, if you don't do it, you're probably
getting what you've paid for (a crash on a NULL dereference at random).
This issue has a lot more to do with platform specific package managers
than with the technology itself. Agreed, the previous iteration of
technology (ld.so) provided a way (the "ldd" command) to know what
dependencies a binary or library has automatically, but that has no
bearing on the problems the technology itself has.
If nsIModule was extended appropriately, then a tool similar to regxpcom
would be able to list both the required and the provided categories
implementations of a module. It would then be a matter of extending
package managers to use this tool, just like they were extended in the
past to use "ldd" to increase the accuracy of their dependencies.
In the end, I think that the problems of stability regarding DLLs that
Windows is experiencing is not due to lack of package management
(Slackware doesn't have either a real package manager nor "DLL Hell") or
COM itself (Windows had DLL Hell before COM even *existed*), but rather
the very loose system administration practices of Windows users. Almost
every Windows program comes with its own depended-upon DLLs and installs
them in the face of anything that was there before, often overwriting a
newer version with an older, bug-ridden version.
--
Pierre Phaneuf
http://www3.sympatico.ca/pphaneuf/
