Re: [decentralization] RE: p2p working group/standards
> 1. WBXML tokenized compressionThe following night help:
> Anybody know of a library to do this?
XMill groups XML text strings with respect to their meaning and exploits
similarities between those text strings for compression. Hence, XMill
typically achieves much better compression rates than conventional
compressors such as gzip.
----- Original Message -----
From: "Tony Kimball" <alk@...>
Sent: Tuesday, February 13, 2001 6:40 PM
Subject: [decentralization] RE: p2p working group/standards
> Quote dnm@...:
> : As for the XML parser, again, only needed if the common communications
> : framework is XML-based, which certainly seems to be the trend for a
> : slew of reasons not worth going into here, but is not _necessarily_ the
> : road (given considerations of performance and problem domain).
> There are two reasonable approaches I know of for resolving the XML
> 1. WBXML tokenized compression
> Anybody know of a library to do this?
> 2. gzip encoding
> Cheap and already deployed everywhere, but dog-slow on an 8051.
> lucas@... expostulated:
> : I second Dan on this. decentralized service lookup. Is important.
> How decentralized? Are DNS NAPTR and SRV records not enough?
> UDDI? JINI? I'd like to hear about other
> people's requirements. Here are mine:
> 1. ability to autonomously publish a named resource location
> 2. ability to reliably locate redundant instances of a named resource
> Hmm, so far DNS SRV and NAPTR records seem to do the job just fine.
> It's ubiquitous and cheap and here today.
> 3. ability to autonomously publish metadata describing that resource
> All this requires is a standardized location relative to the result of
> 4. ability to efficiently search (i.e. as locally as possible)
> for resources matching my metadata constraints
> This is more ambitious, probably premature to standardize:
> Requires too many layers of agreement. Implementation first,
> Wesley Felter deliciously pronounced:
> : This remind me: Has anyone given thought to using SLP for discovery of
> : nearby peers? I bet it would work great in dorms and corporate LANs.
> It would work anywhere, but there's no deployed infrastructure for
> the Internet at large, so I can't use it.
> : I think peer discovery and directories (i.e. name->IP mappings, where
> : name may be user@host style (Jabber, SIP), or free-form, or a public
> : key) are something that could definitely be shared among systems.
> I hate name@host. Because I do not live inside a box. I am not
> @host. I am @large.
> : The problem with IPSec is that
> : (AFAIK) it has to be in the networking stack, which is quite an
> : engineering challenge compared to userspace code.
> But it has already been done. There are multiple implementations
> out there to choose from. Just build and reboot, man. Oh, you want
> to interoperate with legacy patforms....
> : 3. Common crypto framework
> What's wrong with SSL again? I know what I don't like: The first
> problem is that it isn't hard enough. The second problem is that you
> can't do HTTP named virtual hosts over SSL. That's enough to kill it
> dead in my mind. But then the third problem is that the API stinks
> on ice. Except in Java.
> : As for thoughts on something that embodies number three, would we
> : from a standard sort of encrypted message format, perhaps along the
> : an OpenPGP-like standard tailored to the P2P problem domain/environment?
> Cris Cummer mumbled:
> : what are the IETF and W3C doing to this end that you're
> : supporting?
> The only value of IETF and W3C standards lies in the reference
> implementations. Give me implementations first please.
> Standards later.
> To unsubscribe from this group, send an email to:
- Justin Chapweske said:
> ... switch to SHA-1.Probably going to SHA-1 isn't too big of a problem. I'll bring it up with
> The biggest group that I havn't yet talked to about this is the Gnutella
> guys, but I'm sure they'd be into it as well. Any Gnutellians on the
those that I know. Interestingly, there are ways to add file hashes within
the existing protocol specifications - it should even be backwards