>But Java and linking together the data types solves this component
>service composition model using programming language technology. XML
>doesn't because it's still just data.
BJ doesn't get it. Data lives forever. Programs are only mortal. Data
standards matter more... and a little more respect for one's enemies
(.NET, in his case) couldn't hurt... Rohit
=================================================================
O'Reilly: So what do you think about .NET?
Joy: I don't know, they had to do something. It's imperial
overstretch. It's just way too much. It's a top-down design, where
they weren't even clear - the problem is they need a strategy, not
... the goal is total world domination and they invented something
really complicated and messy.
O'Reilly: So SOAP and XML-RPC - things like that - are in some sense
relatively simple. Do you see them ...
Joy: But Java and linking together the data types solves this
component service composition model using programming language
technology. XML doesn't because it's still just data. You still have
to have a type system to plug the things together and essentially,
dynamic linking, and you don't find that in XML just by itself. So
you need Java and you essentially need what Jini does - whether
you're hooked together with Jini RPC or an XML-formatted RPC is
really kind of irrelevant. You still need the moral equivalent of
dynamic linking if you're to have rich things that connect to each
other. People will eventually realize that you need to do something
like Jini.
O'Reilly: I wouldn't necessarily disagree with that. On the other
hand, I would argue that from a pragmatic point of view, systems that
don't have all the features often beat systems that do. You know the
Web was sort of ...
Joy: Well, but either you can compose components with behavior or you
can't. It's like the evolution of multi-cellular creatures. You can
go along with single-cell organisms but at some point you will come
up with a multi-cellular body plan. And you either can do it or you
can't. And the problem is that without the ability to plug together
behavior, you're basically stuck in these single cellular things. You
end up with 1,000 different XML-based thingies that don't ever really
compose to do anything together. You don't have composable things
because you don't have the algebra to put things together.
I think WAP is an example of a similar problem. Why did WAP fail?
Because it's boring, and it's boring because it's static, because it
didn't have any behavior. The screen is small and there's no way to
really do much of anything dynamic. And so what you needed is
downloadable behavior. You need basically a scripting language or
Java or something in the handset to make it interesting.
I think a similar problem here is XML. Yeah, you can do a few little
things, but you're going to quickly run into the fact that you need
behavior, not just data formats, because otherwise everything is too
static and brittle. As long as there's no alternative, it's fine, but
then you quickly discover things get to be kind of messy.
O'Reilly: I'm not sure I agree with you there. I think you can in fact ...
Joy: I know. The market doesn't agree with me, either. We'll come
back in five years and find out.
O'Reilly: Well, but is it really either-or? There really isn't ...
Joy: Yes, I think ultimately these data-driven things will prove to
be unsatisfactory. If anything, what we need is procedural component
things plugging together using a more biological metaphor rather than
-- Java is an engineered connection and what we really would like is
some sort of constraint-based list-like connection which is, you
know, rather difficult. We really wanted something that's beyond the
state of the art, even goes beyond Java to do things in a much more
organic-biological kind of way.
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:18:31 PDT