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

[Paul Snively]

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

Hello, Tom!

On Wednesday, September 17, 2003, at 08:15  AM, Tom Lord wrote:

> > That's more what I was inquiring about, not so much the "native" 
> > nature
> > of the AppleSingle file, which is as you say.
>
> See my reply to Doran Moppert.
Yes, it sounds like the idea is shaping up nicely, and I completely 
understand that it has back-burner priority.

> The "castles in the sky" comment refers to your promotion DNS-SD in a
> context where the problem you're offering to solve currently has the
> status here of, at most, something that shows up in a fairly
> off-the-wall thought experiment.  We're at the stage here of "Ok,
> maybe some functionality in that abstract area is something
> interesting to think about" and you're at the stage of telling us that
> some particular piece of low-level technology is therefore a must
> have,

On the contrary; I'll now ask for the third time for alternative 
suggestions.

>  that I'm rude for criticising you for that,

No, merely mistaken in your perceptions and, from appearances, 
unwilling to engage on the notion of technical alternatives.

>  that I'm
> hypocritical because I've written other programs,

Specifically other programs that fit "castles in the sky" just as well 
as integrating automatic service discovery does.

>  that I lack a
> suitable spirit of competition against some version of CVS that
> happens to use that technology .....
I merely believed that such competition was a goal of yours. Happy to 
be corrected. But the point that it serves as an existence proof that 
automatic service discovery in general, and DNS-SD support in the 
specific, is not so "castles in the sky" as never to have been done 
before remains.

> What do you expect me to say in reply to something like that?  "Oh,
> boy, I'm sold on the idea, let's do it?"
Not at all. Once more, with feeling: if you have qualms about DNS-SD, 
suggest an alternative. If you have qualms about automatic service 
discovery, join the discussion about using LDAP or some other kind of 
naming/directory system that requires existing infrastructure, etc. 
There's lots to talk about without just walking off in a huff because I 
had the temerity to introduce a strawman proposal to the list. Even 
when David and I implement something that you may or may not like, 
we're not insisting that you add it to tla, nor am I threatening to 
pull a Walter. OK? I'm being as fair as I know how to be, and I seem to 
be able to engage others on this list in an open discussion of the 
issues. It's clarifying a great deal for me, and I hope for them too. 
Given that you created arch, I'd merely hoped to engage you the same 
way. But to date you seemed to be a bit fixated on the strawman, and 
your only suggested alternative has been a whiteboard. That's a 
sufficiently extreme reaction that I'm not willing to contemplate it. 
But you seem to have something else in mind now:

> We have a sort of symbolic place-holder in tla for things like
> registration services: the `tla grab' command.  It could use things
> like a better parser, a formal spec of the language it accepts,
> support for configs, careful integration into the transport mechanisms
> of src/tla/libarch/archive.h, and some design thought on where to take
> it from there (mirroring hints?  branching hints?  patch-queue links?
> ....).
That's most intriguing. I will begin researching it. Thanks for the 
pointer!

> Now, if you want to layer on top of a fleshed out `grab' mechanism
> some kind of contextual resource discovery (why the context should be
> defined by network topology is a bit of a mystery, but) -- no doubt
> that could then be done entirely externally to arch.
I would have to imagine that you're correct, but it's hard to say 
without learning more about grab, so I will do that.

> -t

Many thanks and best regards,
Paul

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

iEYEARECAAYFAj9pMYkACgkQugPBK9DeteqA7QCgxN2XTkTOTnHo1xj0J9inasjq
CIcAn3GExHynnVVH28/ZdwaqCshC7aoi
=VDd9
-----END PGP SIGNATURE-----