Re: [Gnu-arch-users] Ruminations on Arch Desiderata

[Paul Snively]

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

Hello, Tom!

On Tuesday, September 16, 2003, at 01:05  PM, Tom Lord wrote:

> Do I understand correctly that you want arch, when it calls `open' on
> a file with resource forks, to see when reading that stream a
> mime-encoded version of the file plus its forks?
>
> If that is so, what do you expect `diff' and `patch' to do with these?
> Or `tar'?   There are at least two issues:
>
>
> 1) diff, patch, and tar are invoked as subprocesses.   At the very
>    least, they would have to be modified as well.
>
>
> 2) Let's suppose that I have three streams which are these
>    mime-encoded multi-fork files: A B and C.
>
>    Let's suppose that `diff' and `patch' operate on these streams.
>    I create a stream D as follows:
>
>    % diff A B > ,tmp
>
>    % patch -o D C ,tmp
>
>    You certainly don't expect D to be a valid and useful mime-encoding
>    of the patched multi-fork file, at least in the general case, do  
> you?
Good points. My understanding was that arch would not attempt to  
diff/patch a binary file. I don't see the issue with tar; people tar up  
AppleSingle files all the time. Once again, MacCVSPro and CVL do  
exactly--EXACTLY--what I'm proposing for arch. These are front ends to  
unmodified CVS servers. They've been in use for many years. They work.  
Any information about why they work with CVS but raise issues with arch  
is welcome. So now my question is: is my understanding of arch's  
handling of binary files wrong? That is, are binary files  
diffed/patched? Merged? Isn't this generally a problem with binary  
files, with arch or with CVS or with...?
> On the DNS-SD support: I think the issue is that you are presuming a
> solution where no widely agreed upon problem actually exists.  You
> gave one use-case on the help list that was interesting in the
> abstract -- but I suspect that if a group of people wanted to solve
> the abstract problem, their solution would be rather different than
> what you are proposing.
Fair enough. I'd be interested in alternative suggestions, most  
definitely.

> The use case involved people arriving at a conference which hosted a
> wireless lan and wanting to "hook in" quickly and easily to all of the
> arch archives on that lan.  I would expect a pragmatic solution to
> such a problem would involve something like a 5 line shell script, a
> README file, a white-board near the registration desk, and a public
> FTP site on the lan at a well-known address (well-known via the
> whiteboard, of course).   Perhaps there would be a wiki.
>
> Never understimate the power of a dry-erase marker.
I find it impossible to take this seriously. Perhaps you'd care to try  
again, this time offering an alternative automated solution? Using a  
computer? Let me point out again that there's at least one CVS server  
implementation that registers itself with DNS-SD, and at least one CVS  
client that looks up repositories with DNS-SD. Perhaps I was mistaken  
in believing that a "global distributed namespace" and DNS-SD were an  
obvious match; perhaps there's another technology that's preferable.  
Saying "let's not use technology to solve this problem," however, is a  
non-starter.

> -t
> ------
> "Fast forward a couple of years. Now the truly massive profit margins
>  meant that just about any mistake and I mean any mistake, was  
> completely
>  masked by the awesome cash flow. Management succumbed to the cash flow
>  drug and vainly assumed that it was their hard work, superior  
> strategies
>  and dizzying business acumen that was driving the company ever  
> skyward.
>  They thought they could do no wrong but they were.
>
>  They thought that t-shirts, purple furniture, jackets, unique building
>  architecture, polo shirts, sabbaticals, watches and great product code
>  names were the secret recipe for success." --Chad Carlin
>
>
>
>
> -----
> https://www.paypal.com/xclick/ 
> business=lord%40emf.net&item_name=support+for+arch+and+other+free+softw 
> are+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD
>
> and
>
> address@hidden for www.moneybookers.com payments.
Best regards,
Paul

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

iEYEARECAAYFAj9n1OoACgkQugPBK9DeteoOvACg0+V2/85IduozaTiz0NBBZ+fy
9VIAn2rU31PwyyefDjk26KLYIWSbpagv
=pVWq
-----END PGP SIGNATURE-----