Mark said...
> They've been ahead of 1.1 for almost a year. They had their own
> serialization mechanism before Javasoft.
Which unfortunately means they are currently incompatible with Java's
serialization. Now they'll have to destroy the village in order to save
it.
> Necessity is the mother of invention, so they say.
Yeah, necessity is a mother all right.
> > The state of the execution stacks and program counters of the threads
> > owned by the aglet are not serialized. Object serialization touches
> > only data on the heap, not the stacks or the program counters.
> There was a recent discussion on the Aglets mailing list about just
> this topic. It might require some major rework of JVM implementations,
> but from the developer's point of view, Thread just needs to implement
> Serializeable (I think that's all that would be required).
Interesting. I thought Sun was through mucking with the JVM, but maybe
they've only just begun.
On to Ron...
> >In particular, we argue that HTTP can and will be extended to cover
> >more of this space than any of its predecessors. New developments in Web
> >infrastructure point the way towards "push" HTTP transmissions, streaming
> >data, and integration with distributed object RPC systems.
> Presumably by this latter you mean that http can be integrated with the likes
> of CORBA IIOP, DCOM and Java RMI: all IP based, all "distributed object
> RPC systems".
Actually, that's a *different* paper. This paper is backwards-looking,
in reviewing previous protocols and saying how HTTP does that body of
work some good.
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.
> I've been of the opinion that some or all of these 3 are, in fact, the
> "right TP"s on which to really build a solid infrastructure for a
> wired future, and that http is really just one more in the long list
> you mention of ultimately unsatisfactory attempts.
This is why HTTP is one of the best-kept secrets in the business. :)
> In its original conception, it's stateless, it has no amortization of
> connections, it's insecure, etc. Sure, it's being spiffed up to deal
> with such issues (there's cookies, after all :-). But is it really the
> 'right' foundation to start from, given where we want to end up? (Or
> maybe we just plan to end up in different places....)
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. :)
> As I said, it's an opinion, and I can be swayed by good argumentation.
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...
> I know that you and Adam are hardly oblivious to the merits of DOs,
But of course! DOs are the future. And the future is almost now.
> so you must have good reason for rejecting their TPs in favour of http
> as a starting point. Care to share?
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. :)
And bringing the frustration up one level is Ernie "Georgia Tech isn't
on the east coast is it?" Prabhakar...
> Subject: HTTP vs IIOP
> Yeah, what he said.
Rut roh. The native methods are restless, Rohit.
> 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. :)
> 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...
> 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...
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...
> (sorry for the telnet typos)
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