[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 |
-----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-----
- [Gnu-arch-users] Ruminations on Arch Desiderata,
Paul Snively <=
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Robert Collins, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Damien Elmes, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Paul Snively, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Tom Lord, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Tom Lord, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Paul Snively, 2003/09/16
- Re: [Gnu-arch-users] Ruminations on Arch Desiderata, Paul Snively, 2003/09/16