Martin v. Loewis
Fri, 7 Sep 2001 08:41:48 +0200
> second, please understand that it is not my desire to
> mandate any changes to existing peps or guidelines. i
> want to create a real world extensible system that can
> be used and tested before asking for pep revisions and
> or authoring new peps
So IOW, you want to create a competing infrastructure, hoping that it
will be better than the one specified in the PEP, and that it will
eventually replace the PEP. Is that correct?
Then, of course, you are free to make any choice of implementation,
protocol, etc., that you consider appropriate. I'm less interested in
such a thing, though, since I cannot interoperate with it unless its
protocol is documented.
> generic language indepedent processing tools for
> heirarchical information thats amenable to
> internationalization and is easily extensible. all of
> which are standard "xml benefits" items ( i feel like
> i'm preaching to the choir:). the real question is
> what do rfc822 headers provide, very little imo.
Almost all of the same. Language-independence, internationalization,
easily extensible. They only difference is that they are not
> simple processing via standard module and low
> developer overhead.
I think processing of 822 headers is simpler than processing XML,
because 822 headers are not hierarchical.
> the cumulative benefits for implementations of catalog
> servers and clients seem overwhelming to me.
I don't share this optimism, but as I said: If you are planning your
own infrastructure, go with whatever you consider appropriate.
> i think we might have different core goals. to me
> depedency info is a must. leaving it out of the
> standard and to convention violates your stated
> principal above of using 'standard metadata'. without
> depedency info i think there is undue burden on client
> and server implentations for depedency resolution
> (both for install, upgrade, and removal).
Initially, and until dependency is in the metadata, the software would
not deal with dependency at all. It would be up to the user to deal