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

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
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  
<http://sourceforge.net/projects/maccvspro>  and 
<http://sente.epfl.ch/software/cvl>. 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 
<http://www.codingmonkeys.de> and 
<http://www.mathgamehouse.com/istorm>. 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. <http://www.dns-sd.org> 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.

> -t
Many thanks and  best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAj9gj04ACgkQugPBK9DeteqkzACfR1FWHlKuQyjekVgQrCgb9d9X
lpUAn2tWdTK6s9aoWjDTbBb5wkLFYmt8
=FkGI
-----END PGP SIGNATURE-----