[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnu-arch] RFC 1740 Support

From: Paul Snively
Subject: Re: [Help-gnu-arch] RFC 1740 Support
Date: Thu, 28 Aug 2003 20:20:34 -0700

Hash: SHA1

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.

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

Is this sufficient?

Archives are not, for the most part, a network-local service.   It's a
global namespace.

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
purely theoretical?

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

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.

As for GPL-compatible, there is an alternative version of ZeroConf at <> that is under the GPL. OTOH, I've read <> 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.


Best regards,
Paul Snively

Version: GnuPG v1.2.3 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]