[Top][All Lists]

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

Re: [Help-gnu-arch] Checking In...

From: Paul Snively
Subject: Re: [Help-gnu-arch] Checking In...
Date: Thu, 11 Sep 2003 08:05:42 -0700

Hash: SHA1

Hello, Tom!

On Wednesday, September 10, 2003, at 09:57  AM, Tom Lord wrote:

From: Paul Snively <address@hidden>

So do I take from the radio silence here that the suggestions for RFC
1740 and ZeroConf aren't perceived as good?

They're a bit off the beaten track, at least.

Not as far as it might seem: RFC 1740 is commonly implemented in tools that have reason to cross filesystems, for example netatalk, as well as in implementations of popular version control systems that must deal with HFS[+] filesystems, for example <> and <>. ZeroConf is admittedly newer, but gaining traction thanks to its inclusion in Mac OS X 10.2. We now have some very nice collaborative tools, for example <> and <>. Through either Apple's open source implementations or Howl, ZeroConf is available for other popular platforms as well.

Finally, it seems worth observing that RFC 1740 and ZeroConf are both IETF standards-track technologies--they are not in any way proprietary. I was quite careful in applying that criteria to this discussion.

Are you subscribed to gnu-arch-users?    I recall that you started
this thread wondering where a good place to jump in and make
improvements might be.

Well, some relatively specific improvements in the sense of addressing a different filesystem and perhaps making dynamic networked collaboration even easier.

   Lurking on that list for a while and using
arch to get a good feel for it might be the best place to start.

I'm using tla 1.0.6 relatively happily, and I do frequently follow the archives for gnu-arch-users. One issue I do have with tla 1.0.6 is that the interpretation of spaces in filenames leading to evaluating the file or directory as "Unknown" appears not to derive from a regexp, but rather is hard-coded. On non-UNIX platforms, source files and directories commonly have spaces in their names.

I can't really assert a definitive "No" to the abstract ideas of
supporting file systems with "exotic" structure or weird file types or
even alternative network configuration mechanisms.   In the very
abstract, those are all fine areas to consider.

One problem I've had with your approach is that you seem to have leapt
immediately to a solution mechanism without first establishing the
existence of specific problems that, if solved, would clearly make
arch a better tool.

Interesting. From my perspective, having millions of potential arch users who happen to have HFS+ filesystems that aren't currently served adequately by arch seems sufficient justification to warrant RFC 1740 support in precisely the same sense that the aforementioned MacCVSPro and CVL support it. That is to say, I fail to see how this suggestion can even be remotely controversial, partially because the problem is extremely well-defined: we know how HFS+ differs from other filesystems. We know how to have HFS+ interact nicely with other filesystems, and the means for doing so have been standardized years ago. These standards are commonly used in other tools to good effect.

"Alternative network configuration mechanisms," again, isn't the piece of ZeroConf that I'm discussing. <> is. And I mentioned a use-case that I think is quite reasonable: a bunch of hackers walk into a conference hall with their 802.11[whatever] laptops. If they had ZeroConf and an appropriately-extended arch, they could immediately do "tla archives" and see all the archives in the hall. It's a small thing, perhaps. On the other hand, it sure beats going around to N thousand attendees and saying "Do you have an archive? What's your IP address?"

The bottom line on this idea is just that arch touts:

"distributed repositories -- each hacker or group can host their own branches. There's a global (world wide) name-space for lines of development and revisions. Branches can be formed from any repository to any other and merge operations can span repository boundaries without needing to actually duplicate the full contents of a repository at each site."

That's feature #1 on the home page, and I feel justifiably so. All I'm suggesting is that there's a nice correlation between that and a technology such as DNS-SD, which happens to be part of ZeroConf, is an IETF standard, and has been implemented at least twice, independently, once even under the GPL.

So I fail to understand your assertion that I haven't established the existence of specific problems (although I'll grant that the lack of DNS-SD support isn't a problem, but rather that an opportunity to address dynamically-formed networks with a lot less manual labor exists). The one issue that is actually a problem is an old one that has been faced by other systems, a solution defined and standardized, and has been widely implemented.

    And yes, you can always take the functionality
that the solution mechanisms you have in mind provide and assert "the
problem is that arch doesn't have that functionality" -- but that's
putting the cart before the horse.

I'm not interested in adding features for the sake of adding features. I'm a member of a particular developer community who would like arch to work even better in environments that I commonly find myself in. That developer community happens to be the developer community for the largest commercial UNIX vendor in the world. It seems to me merely wise to attempt to reach an understanding that will accomplish arch's goals and also be of service to this community. David Harr and I are more than willing to do the work and leave it to you whether you wish to integrate the work, allow us to integrate the work, or disallow us to integrate the work. All we are really asking for is a little guidance, if possible, as to where any preferred integration points are for the types of features we're proposing.


Many thanks and  best regards,

Version: GnuPG v1.2.3 (Darwin)


reply via email to

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