It's worth thinking about what scales and what doesn't scale so well. For example, names are relatively local conventions. We could expect to have to find better ways to describe resources, or perhaps "send processes rather than messages". Think about what's really interesting about the way Parc used what became Postscript instead of trying to define a file format for "documents" for printers ... (a programming language can have far few conventions and be more powerful, so ...)
Granted, names have their problems. But as a tactical solution URLs can be used to send high-level messages or at least as a name resolution scheme to initiate communication between two or more OO systems. And URLs are just names... (credit where it is due: I first heard the thought expressed by you and it gets the job done until something better comes along)
Admittedly this does not (directly) address the issue of sending processes (which could be handled indirectly as payload.) Or am I missing the bigger picture you're driving at here?
My example definitely presumed things like service discovery which gets you to URLs. But I think I see the larger point you make about what if you don't even know what kind services are available (which my example assumes you already know) and once told of their existence how do you negotiate their capabilities and usage (my example, as I envisioned it, completely falls apart here without some major plumbing which might require running an open sewage line through the kitchen. i.e. probably not the best way to do it)
P.S. I have found the team's work on STEPS quite thought provoking. If anyone could find the time once things settle down, it would be most appreciated if some quick docs re: how to reproduce (i.e. build) the Frank environment could be put together. (if they already exist, a pointer to them would be helpful)
Thanks, Alan. I guess sometimes is hard to think about that level of scaling when working on the industry... or at least in projects that are not that massive.
I assume your are talking in the lines of "call by meaning" when you mention that names are relatively local, right?
As for "send processes rather than messages", isn't that what objects are about?
I mean...sending the real thing, not just "data" as part of a message. That reminds me of the Burroughs 220 and "delivering video + codec together" example you mention in your talks.
Im afraid I'm missing the point about "sending processes rather than messages".
The modularity thing sounds pretty much to well designed objects to me, but it seems that you're trying to make a difference between that and processes.
What do you have in mind or, better said, which could be a concrete example of it?
Re. consider "send processes rather than messages"
Interesting thought to ponder!... What came to mind is Smalltalk-80 kind of did that, though the processes (blocks) were not in the "driver's seat" of the interaction. They came as "payload."
Smalltalk is very long in the tooth these days, but it is still "rather object-oriented in good ways".
Erlang and its derivatives are fun and good to help that kind of thinking.