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

[Tom Lord]

    > From: Paul Snively <address@hidden>

    > But I guess I'm not clear as to why this is a nasty thing for Arch to  
    > have to deal with. It's no nastier than MacCVSPRO or CVL having to deal  
    > with it. AppleSingle exists precisely so that you can plug it in and  
    > play nicely with plain ol' POSIX filesystems. Obviously, it would be  
    > conditionally compiled just for the Mac and only called in cases where  
    > there was a resource fork and/or non-default metadata. I'm a little  
    > surprised that this point is the one that's proving difficult, and the  
    > (in my mind, anyway) much trickier issue of DNS-SD support isn't even  
    > being commented on. But one thing at a time, I agree. :-)

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?


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.

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.

-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+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD

and

address@hidden for www.moneybookers.com payments.