[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Snively
Subject: Re: [Gnu-arch-users] Ruminations on Arch Desiderata
Date: Wed, 17 Sep 2003 21:16:00 -0700

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

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.


Many thanks and best regards,

Version: GnuPG v1.2.3 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]