[Gnu-arch-users] Ruminations on Arch Desiderata

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

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 
<http://www.dns-sd.org>, 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 
<http://supertart.com/software/CVSServerSetup> 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 
<http://developer.apple.com/darwin/projects/rendezvous>, and Howl at 
<http://www.swampwolf.com/products>. 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAj9mio8ACgkQugPBK9DeteqFagCfap9jMjU1bBeJfEKK+77BFz4e
FwYAoIYiiFrSXqwV0ZVT1X6dNcv3fHxS
=eQqg
-----END PGP SIGNATURE-----