[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnu-arch] RFC 1740 Support
Re: [Help-gnu-arch] RFC 1740 Support
Thu, 28 Aug 2003 20:20:34 -0700
-----BEGIN PGP SIGNED MESSAGE-----
My apologies for the lack of clarity. What I'm proposing is that tla
include limited support for the HFS+ filesystem. This support would
consist of examining files to be added to an archive to determine
whether they have a "resource fork" and/or "non-normal" "Finder flags"
and, if so, encode the file using AppleSingle before archiving it.
Likewise, on the way out, an AppleSingle file would be decoded if the
destination filesystem were HFS+.
It's not clear to me specifically what you are proposing so I can't
really tell whether or not it's a good idea.
Is this sufficient?
I understand that archives form a global namespace. Under ordinary
conditions, one uses register-archive, providing an archive name and
physical location, to identify remove archives. What I'm suggesting is
that it would be nice if there were a discovery mechanism based on
ZeroConf that would render registration of archives present on the
local-link network unnecessary. The creation of an archive behind a
public service (HTTP, FTP, etc.) would register the fact via ZeroConf;
an instance of tla on another box on the local-link network would look
up available archives and register them (in the tla sense)
automatically with an appropriate default name and URL. "tla archives"
would reveal these newly-discovered archives. This seems like it would
be useful on wireless networks where archives come and go, or even on
relatively stable networks where someone across the building creates a
new archive and you may wish to have essentially instant knowledge of
and access to it.
Archives are not, for the most part, a network-local service. It's a
I can imagine esoteric situations where you'd have archives on some
non-Internet subnet and want to register those -- are you actually
facing such a situation in the practice of deploying arch or is this
If it is not theoretical, then perhaps it is a problem others will
face as well, in which case we should consider a GPL-compatible
As for GPL-compatible, there is an alternative version of ZeroConf at
<http://www.swampwolf.com/products> that is under the GPL. OTOH, I've
read <http://www.gnu.org/philosophy/apsl.html> and, apart from the mere
assertion of "incompatibility," it's not at all clear what issues there
would be in, e.g. adding appropriate #includes and -lwhatevers to the
appropriate places in the tla code and saying "download Apple's
ZeroConf code over there." Further, I don't know what the issues would
be even if one were to distribute a binary built from the two code
bases: From the above link, I see "The Apple Public Source License
(APSL) version 2.0 qualifies as a free software license. Apple's
lawyers worked with the FSF to produce a license that would qualify"
and "In version 2.0 of the APSL, the definition of 'Externally
Deployed' has been narrowed in a way that is appropriate for the
respect of users' freedoms." There's no analysis of the ramifications
of linking APSL and GPL code other than the flat statement of
incompatibility, which, lacking explanation to the contrary, I
interpret to mean "philosophical incompatibility," which is
contradicted by the preceding statements.
This also raises questions about the possibility of building GUI front
ends for tla, which is a project I'd like to take on at a later date.
The GUI framework that I use is zlib-licensed and under no
circumstances will any of it be GPL'ed. Am I then to understand that I
could not even link with libarch and its dependencies? Has any
consideration been given to at least placing libarch and its
dependencies under the LGPL? It would be a shame to limit tla's spread
to other user communities on the basis of what amounts to a religious
debate about whether or not it's acceptable to link together two
codebases, both of which are committed to keeping their source code
available to anyone who wants it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----