[Top][All Lists]

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

[Gnu-arch-users] Ruminations on Arch Desiderata

From: Paul Snively
Subject: [Gnu-arch-users] Ruminations on Arch Desiderata
Date: Mon, 15 Sep 2003 20:59:03 -0700

Hash: SHA1


My name's Paul Snively. I've posted a few times to the "help" list, and Tom and Tobias quite rightly suggested that I join the conversations here. There are a very few things that my old friend and colleague, David Harr, and I are trying to figure out how best to add to Arch, specifically the tla implementation, and we're far from the first to wonder about at least one of them. However, we've not been following the list long, so please bear with us if we're joining the conversation in the middle.

I happen to work on Mac OS X, and as I pointed out to Tom on the other list, Mac OS X' default, and preferred, filesystem remains HFS+. This means that sometimes files have "resource forks," and always files and directories have metadata other than what we're all familiar with from POSIX. This has been true since time immemorial, the problem has been solved by using some encoding scheme, and these schemes are even IETF standards: RFC 1740 defines encodings for HFS[+] files for transportability purposes, and one of the encodings, "AppleSingle," is a popular standard in the real world, being used, for example, by netatalk to store Macintosh files on non-Macintosh filesystems, and by Mac-oriented version control clients like MacCVSPro and CVL. So my first question is: does someone relatively familiar with the tla implementation have any suggestions as to where good integration points for AppleSingle support might be? Bottlenecks that create, open, read, write, close files?

My second observation, and the one that has been treated on this list before, is: some aspects of how file names are recognized are hard-coded despite the presence of regular expressions defining filename patterns. Specifically, the presence of a space in a file or directory name causes that file or directory to be "unrecognized." Of course, on platforms such as Windows and Macintosh, spaces in names are comparatively common, so this particular hard-coded restriction imposes an unfortunate burden on those who would like to enjoy the benefits of Arch on these popular platforms. However, I understand that changing this aspect of Arch would be non-trivial with respect to the assumptions made by the code, and therefore I seek advice from others who have considered the issues in more depth as to how best to approach this desire.

Finally, I'm very excited about the opportunities afforded by <>, the dynamic service discovery system that is part of the IETF ZeroConf standard and which Apple includes with Mac OS X 10.2 and later under the name "Rendezvous." There is an application to set up CVS repositories on Mac OS X at <> that registers the repository with Rendezvous, and includes a tool, cvsDiscover, for finding repositories on the local network. The CVL front-end also supports repository discovery in Rendezvous. I'd very much like to see the same functionality in tla. I should add that while platforms other than Mac OS X 10.2 and later do not have ZeroConf built in, there are two implementations for non-Macintosh platforms: Apple's own open source implementation at <>, and Howl at <>. The former is under the APSL, the latter under the GPL. So this feature idea is not at all limited to the Macintosh platform.

In case there's any confusion, the point of this last idea is to be able to create an archive and make it publicly available on the local network via DNS-SD so that anyone else on the local network who is browsing for the appropriate service type will find it. So imagine going to a geek conference with your WiFi laptop, walking into the conference hall, and instantaneously having your global archive namespace enriched with whatever archives happen to be available. Imagine being able to immediately collaborate on a project, merge changes throughout the hall, branch as desired, and then go home and continue to work offline, connecting perhaps to a more stable archive later and merging again. The idea is to leverage Arch's tremendous benefits of a global distributed namespace and sophisticated branching and merging support in the context of a highly dynamic network environment.

So that's the pitch. I'd love to discuss these ideas, see if they excite anyone else, and learn how best to collaborate with others who are interested in Arch's evolution and success.

Best regards,
Paul Snively
Version: GnuPG v1.2.3 (Darwin)


reply via email to

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