I'm surprised nobody here is talking about JXTA...
For all its flaws (and I'd like to go over some of those, below), JXTA is quite significant - if only for Sun's realisation that decentralised systems are a wide-reaching new paradigm for systems-building. But, for peple on this list, is it something you'll plan to use?
I posted my initial impressions to groovelog,
http://groovelog.agora.co.uk/groove+log/groovelog.nsf/($All)/2EECD73542660FE080256A3B0041708A
and they need some revision or at least justification.
XML
===
I like the use of XML throughout jxta, but it's a very half-hearted effort. When the wire data protocol is "nearly XML but not", and endpoints are not expected to contain a parser, then the whole system can't take advantage of XML's portability. From the jxta_spec.pdf, (p.6)
The representation on the wire of the JXTA peer endpoint messages is as follows. It is important to point out that the
message representation is not a well-formed and valid XML document. To improve efficiency, the intent is to NOT
require XML at the low-level peer endpoint message layer.
and (tech_overview.pdf p7, monstrous)
If the world decides to abandon XML tomorrow and uses YML instead, JXTA can be simply re-defined and re-coded
to use the YML format.
but on the other hand (spec, p.10)
All XML advertisements are strongly typed and validated using XML schemas. Only valid XML documents that
descend from the base XML advertisement types are accepted by peers supporting the various protocols requiring that
advertisements be exchanged in messages.
there's a very mixed message. To my mind, you either use XML or you don't. If you do use XML, then the XML specification takes responsibility for all the detail of byte-ordering, character encoding and so on. If endpoints don't require a conformant XML parser, the spec needs to say which character encodings are acceptable, whether internal and external entities can be used, whether whitespace is significant, and so on. Otherwise there's no chance of interop.
APIs vs protocols
=================
I'm in the "standardise APIs as well as wire protocols" camp, because that's the level at which I want to build portable code. Does this matter?
Purposes of JXTA
================
What is JXTA for? Is it just a stronger backbone for gnutella (and infrasearch)? Is it a candidate foundation layer for distributed computing systems such as AppliedMeta? Is it a candidate for other p2p applications' transports, such as Groove? Is it intended as a generic p2p infrastructure layer? All the intentions seem to be for the last of these, but I don't think the spec bears this out.
What sort of interop is useful anyway, if everyone used JXTA for their abstraction of peers, peer groups and piped communications? Are application developers expected to extend the core services and hence only really interop with other peers which implement those extensions? The "pipes" part of jxta seems to me the most interesting. Is this really smart? Since the power lies in a service-based model, why doesn't JXTA leverage the SOAP or XML-RPC service protocols which already exist? Or, is jxta obsessing on the "pipes" model to the exclusion of a "services" model which the rest of the world is getting excited about?
A little more detail on the "generality" comments above. I find it hard to understand some of the spec's detail if it's meant to be very general.
Content, for example, is shared amongst group members, but then hacked to death with "Each content copy may reside on a different peer in the peer group. The only difference between the copies may be their encoding type (HTML or WML, for example). These copies will have the same ContentID". If you want to manage content, then why say that differently-formatted content can have the same canonical name? What counts as "different"? If I go applying arbitrary XSL transformations to content and re-advertising it with the same canonical ID, will content consumers really accept that?
Another little example: uptime. The ping response message has a mandatory field "uptime" (how long this peer has been alive). That's probably important in some scenarios, but I can't think of any. I would be more interested in "idle time" for instant messaging-capable peers; or "average load", or whatever.
I'm surprised nobody here is talking about JXTA... For all its flaws (and I'd like to go over some of those, below), JXTA is quite significant - if only for...
hpyle@...
Apr 28, 2001 2:00 pm
Hugh, thanks for this overview. It raises interesting questions, I'd also like to know how Jxta compares with Jabber, what problems it proposes to solve that...
Dave Winer
dave@...
Apr 28, 2001 3:59 pm
It doesn't seem that JXTA has brought into the p2p field any tangible technical innovation, such as new distributed algorithms, new techniques/technologies. ...
egroup@...
Apr 28, 2001 6:15 pm
... Not conventions from Sun. The biggest problem with JXTA at this point is its plasticity -- it is an environment that puts peer discovery and...
Clay Shirky
clay@...
Apr 29, 2001 3:25 am
... That would be true if one assumes that the required distributed systems technologies (e.g. the distributed database & search algorithms, multipont...
egroup@...
Apr 29, 2001 8:26 am
Clay I think XML and HTTP are givens in any new networks that are built from here-out, much as mice and menus were givens at the time the Web came along. A web...
Dave Winer
dave@...
Apr 29, 2001 5:59 am
... Besides the obvious problems of bandwidth waste associated with excessively verbose humanly readable ascii protocols, there are more fundamental problems...
egroup@...
Apr 29, 2001 9:03 am
... and yet, it has been these wasteful human-readable ascii protocols that have really taken off. (but sometimes it is fun to think about how much bandwidth...
Jim Winstead
jimw-yahoo@...
Apr 29, 2001 4:20 pm
... That was the point of the distributed example above -- to show the fundamental limitation in the 1-to-1 type reliable protocols when dealing with reliable...
egroup@...
Apr 29, 2001 5:09 pm
... thank you thank you thank you. its amazing, 7 years into the web, how little this lesson has sunk in. -clay...
Clay Shirky
clay@...
Apr 29, 2001 7:27 pm
... You and me both -- I'm having exactly this argument on jxta-discuss right now, because Sun thinks XML is a given, but http not. Grrrr. One of the JXTA...
Clay Shirky
clay@...
Apr 29, 2001 7:34 pm
But HTTP isn't a given unless you assume that every node is at least a PC-class device. Think /dev/null: it's a useful node, but it makes no sense to send ...
Lucas Gonze
lucas@...
Apr 29, 2001 8:00 pm
... This is Marc Hedlund's argument, and I believe that it is right, but just because something does not exist in the base spec does not mean that it has to be...
Clay Shirky
clay@...
Apr 29, 2001 8:13 pm
... got it, though I'm not sure that I agree. What's wrong with thinking of a PC as a very bulky keyring? A thought about upward negotiation: think of a node...
Lucas Gonze
lucas@...
Apr 29, 2001 8:42 pm
... a monitor a keyboard and a mouse, for starters, not to mention more processor power, non-volatile memory and high bandwidth net connections. ... i'm...
Clay Shirky
clay@...
Apr 29, 2001 11:20 pm
Dave, Generally I might agree with you but it isn't clear to me that XML and HTTP are givens. I'm still doubtful that everything can be done using either of ...
C Wegrzyn
wegrzyn@...
Apr 30, 2001 1:23 pm
Chuck -- reason one for XML: self-documenting messages allow for object-oriented extension. If receiver A of a message knows about the format <msg> ...
Lucas Gonze
lucas@...
Apr 30, 2001 3:29 pm
... Worrying too much about the packet format is like hand-optimizing code: sometimes it's necessary, but usually the benefit is much less than if one stepped...
Jeff Darcy
egroups@...
Apr 29, 2001 5:14 pm
... Yes, I know, we (the hotcomm project, still in the skunkworks/semi-stealth mode) did our initial small scale prototype using TCP and conventional style...
egroup@...
Apr 29, 2001 6:50 pm
This assertion comes up so frequently Besides the obvious problems of bandwidth waste associated with excessively verbose humanly readable ascii protocols, and...
Clay Shirky
clay@...
Apr 29, 2001 7:26 pm
... The verbose humanly readable (i.e. readable in raw form without viewing tools) packet formats are certainly wrong objective to give a high pririty. It is...
egroup@...
Apr 29, 2001 9:56 pm
... I'd offer the medium in which we are having this conversation as a counter-example. Email has a small set of standard headers, and what's more, it was...
Clay Shirky
clay@...
Apr 30, 2001 2:16 am
Oops. The previous message quoted from "egroup@..." not Jim Winstead. IRTE....
Jeff Darcy
egroups@...
Apr 29, 2001 5:15 pm
... Note that A and Z might not have direct connectivity. There might be a good reason for having them communicate results along the reverse path that the ...
Jeff Darcy
egroups@...
Apr 29, 2001 5:32 pm
This is the oldest argument, we've been through it on every XML-oriented list. Do some tests, publish some numbers, that would be a new wrinkle. In the...
Dave Winer
dave@...
Apr 29, 2001 5:35 pm
... T/TCP. ... It's really only the short messages that are wasteful. But the more fine-grained parallel tasks tend to generate lots of them. I think it was a...
Tony Kimball
alk@...
Apr 29, 2001 6:04 pm
What are you doing with all those sockets? Try looser coupling, depend more on resources on the desktop. What about the poor Internet, god help us if your...
Dave Winer
dave@...
Apr 29, 2001 6:54 pm
... It is the structural stability requirement (needed for the efficient [i.e. using of the order log(N) elemental transactions] distributed searches, routing,...
egroup@...
Apr 29, 2001 7:14 pm
... now, because Sun thinks XML is a given, but http not. Of course Sun thinks HTTP is not a given. If it was there would be no lock-in possible for them. The...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Send Email