Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] RE: p2p working group/standards

Expand Messages
  • Jacobsen
    ... The following night help: http://www.research.att.com/sw/tools/xmill/ XMill groups XML text strings with respect to their meaning and exploits similarities
    Message 1 of 55 , Feb 13 10:02 AM
    • 0 Attachment
      > 1. WBXML tokenized compression
      > Anybody know of a library to do this?

      The following night help:

      http://www.research.att.com/sw/tools/xmill/

      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@...>
      To: <decentralization@yahoogroups.com>
      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
      whole
      > : slew of reasons not worth going into here, but is not _necessarily_ the
      bes
      > : road (given considerations of performance and problem domain).
      >
      > There are two reasonable approaches I know of for resolving the XML
      performance
      > problem:
      >
      > 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
      > (2).
      >
      > 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,
      > please.
      >
      > 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
      the
      > : 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
      benefit
      > : from a standard sort of encrypted message format, perhaps along the
      lines o
      > : an OpenPGP-like standard tailored to the P2P problem domain/environment?
      >
      > S/MIME
      >
      > 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:
      > decentralization-unsubscribe@egroups.com
      >
      >
      >
    • Ben Houston
      ... Probably going to SHA-1 isn t too big of a problem. I ll bring it up with those that I know. Interestingly, there are ways to add file hashes within the
      Message 55 of 55 , Feb 20 1:37 AM
      • 0 Attachment
        Justin Chapweske said:
        > ... switch to SHA-1.
        >
        > 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
        > list?

        Probably going to SHA-1 isn't too big of a problem. I'll bring it up with
        those that I know. Interestingly, there are ways to add file hashes within
        the existing protocol specifications - it should even be backwards
        compatible.

        Cheers,
        -ben houston
        http://www.exocortex.org/~ben
      Your message has been successfully submitted and would be delivered to recipients shortly.