Adam wrote (most of my stuff deleted):
>
>
> It's like a tag team around here. Thanks a lot for spilling the beans
> before prime time, Rohit. Now we have to deal with all these bean
> STALKERS... (I figured a bad pun oughta wipe out half of the FoRK
> readership.)
You Don't Know Jack (as in beanstalk...) about getting rid of us bean twerps!
OpenDoc is dead! Long live whatever comes next!
BTW, did you know that we asexually reproduce? Oh, sorry, wrong list....:-)
...and ruminated....
>
> We don't want to step into the trap of different object and remote
> invocation models just yet, but I'm sure in finishing this paper, those
> issues will become more apparent as well.
>
.... and wrote...
> This is why HTTP is one of the best-kept secrets in the business. :)
... and taken out of context wrote...
>
> I could tell you the answer, but I'd have to kill you. Let's just say
> that we have ideas for dealing with all of those issues. :)
>
...To which I respond...
Oh yeah smarty pants? And how about dealing with reliable multicast?
Pretty much all point-to-point protocols (and this includes iip, http,
rmi,..) start on tcp, implying a limitation *to* point-to-point. They
can't (readily) expand to multicast, because that means starting with
udp (or raw ip) and building the notions of a reliable n-way session
from the ground up. In a world of gazillions of objects (gawd, where
is this stuff *coming* from?) , you're going to want to efficiently share
reliable state amongst collections of these things. Starting on tcp?
not bloody likely. mbone is an interesting start here, but it's really
geared more to one-way streaming broadcasts for content (eg audio)
transmission. What about fully cooperative peer-group based messaging?
How do you build that starting with http? (or iiop for that matter...)
... and wasted a few bits on bad Monty Python rendering...
>
> And I'm not ready for an Argument yet. Actually, I came to this room for
> Abuse, but now I realize that's down the hall and to the left. Either
> Abuse, or Beating Beat Over the Head lessons, that's what I want...
>
... and here's something we agree on....
>
> But of course! DOs are the future. And the future is almost now.
>
... and acted the part of god...
> Oh sure, we tell you, and you tell two friends, and so on, and so on,
> and so on... we're still arguing over the details, but believe me, once
> we have it articulated in a way that makes us both happy, FoRK will be
> the first to know.
>
> > While I'm on this theme, how do clueful folks justify a future for
> > html in a componentized world?
>
> I have answers for this one, too... but not yet. :)
>
In short, lots of words, plenty of fun and games , but damn little substance.
At least Ernie pried a bit more out of you:
> > C'mon Adam and Rohit, spill your guts. Why is HTTP the right answer and
> > IIOP the wrong answer?
>
> First off, you have to ask yourself, what is the question.
> Truth will come in time, grasshopper. :)
oh piss off with the attitude ;-)
>
> > I know you've been cooking this in the back of your devious little
> > minds for years, when're you gonna let the rest of us in on your secret?
>
> When we ourselves have articulated the secret to the point that we are
> comfortable sharing. There are still some hunches and assumptions to
> work out, right Rohit?
>
> > The only clue I've ever heard is the distinction between object-based
> > vs. message-based systems. The basic issue is one of coupling - a
> > synchornous function call vs. an asynchornous request. The technology
> > is basically the same, but the metaphors and communities are largely
> > distinct.
>
> True, but it runs deeper than the fact that the two communities have
> worked pretty much independently of each other.
>
> In some sense, it has to do with two communities looking at the glass,
> and one calling it "half full" and the other calling it "too much glass
> for the liquid() method to consume" - when really they are in fact
> viewing through the same-looking glass...
>
Now this at least I can Argue with you, or at least Beat you over the
Head with. I'm no huge fan of formalistic self-reflexive OO
either. But I think the protocol issue is a step below whether
**components** are bona fide objects: polymorphic multi-inheritable
blah blah, vs. just chunks of software goddammit. (And this is
one area where I think the criticisms of OLE/COM are misplaced. Who cares
if ActiveX isn't real objects? It works, right? So it's components.
Move on. Gasp! What? grudging
praise for Missy on FoRK? Impossible! Whatever happened to that
JoeII guy anyway? Turned into a lurker, or did Rohit cut him off?
See, no staying power in those MS types :-)
Anyway, back to protocols: IIOP and RMI and gang couldn't really
care much about whether it's 'real objects' on top or not.
In the end, the 'successful' technologies won't be the ones you
or I or anyone wants them or wishes them to be: they'll be whatever
catches on. Granted, http is certainly 'on' today.
But I hope your pro-http paper is more than just 'the web is cool and
we're on the bandwagon'.
Maybe http lasts, maybe
it doesn't. Maybe iiop is a winner, maybe not. Maybe the
karma-rk-tp, named for its omniscient creator and his frequently
flying buddy catches on , maybe not.
Me? I really don't care. I have no allegiance to iiop, http or
anything else. My only allegiance is to the notion that everything
is going distributed, and that we need some 'tp' that everyone
can agree on (sort of like picking 110V/60Hz once and for all
so we can all start making toasters. although we blew that one
what with 220V/50Hz on half the globe).
I say model your domain objects (or whatever
you want to call them) way up high, and let the protocol engineers
fight the other wars below. Eventually the market will pick its winners.
Just make sure your objects up high have distributed semantics
and you're homefree! (well, maybe not that easy...)
As to the 'separate communities' business. Yeah, design-by-commitee
CORBA is pretty different than T-B-L singlehandedly inventing the WWW.,
so granted there are differences between the 'established' standards-driven
types in 'real software development' vs. the gunslingers like T-B-L
and Linus Torvalds popularized in Internet lore. And, sure, we all
identify with the gunslingers (or would like to :-). But let's not forget
the role of the boring side of the fence (and what role is that...?umm..)
You get the drift. Also, it's not always clear what's 'establishment'
vs. what's 'gunslinger'. Eg, what are the Berkeley folks who first ported
TCP/IP to Unix? How about Sun RPC and NFS, developed 'at the establishment',
but distributed freely, Internet-gunslinger style?
Ditto for Java. Note that Sun RPC is a 'tp'
(to use your terminology), and with NFS riding on top of it, perhaps the
most successful tp of all, at least until http.
> > So, are you going to let usknow, or are you saving your logic for some
> > fabulous paper which will win you wordwide fame, fortune, and beautiful
> > women (well, maybe not that, Adam already has one:).
>
> Fame. Fortune. Women. A Jedi knight craves not these things. :)
> We are driven by a higher Force...
>
Yeah. Hawaii.
> And again, we're not hiding anything yet. We just want to cross our t's
> and dot our lowercase j's before going public...
>
as in joekiniry, he of the broken shiftkey/
Well I'm just not going to wait, so there nyah nyah.
> > (sorry for the telnet typos)
That's no excuse Ernie. I type telnet transatlantic (no kidding:
telnet across 7 timezones to Toronto. Talk about latency:-) I know,
I'm an idiot. But I *like* it this way).
>
> No sweat.
>
> ----
> adam@cs.caltech.edu
>
> Empire had the betting ending. I mean, Luke gets his hand cut off,
> finds out Vader is his father, uh, Han gets frozen and taken away by
> Boba Fett. It ends on such a down note. I mean, that's what life is:
> a series of down endings. All Jedi had was a bunch of muppets.
> -- Clerks
>
>
Ron.
"In other words: there's an Orb-like thingie in just about everything,
supporting a queryable BO that can do meaningful things ?"
--Sandor Spruit