TCC is a small, fast, optimizing C compiler, linker, and loader. And the cool thing for dynamic language implementations...
With libtcc, you can use TCC as a backend for dynamic code generation.
This is very interesting. About 8 times faster than GCC. Why spend time on a virtual machine instruction set?
TCC can also automatically generate memory and bound checks while allowing all C pointers operations.
Quick thoughts before the weekend about what's next. After a web services foundation is in place, what do you set out to do with it? What metaphors guide your vision?
One metaphor is formulating: Conversations. Maybe in one sense something like Conversation for Action.
Another question, what current systems and applications most closely embody these thoughts, or your own thoughts about what's next?
Sam Ruby responds to my interest in WS-xxx...
[W]hat I most would like to explore is what is next. After Web Services.
I occasionally hear talk of an Internet Operating System. And as a group we obsess on what is the optimal design of an individual neuron.
Something nagging in me tells me that these are the wrong metaphors and that we are [on] the wrong meta-level. There is no brain operating system. The emergent behavior of a brain can't completely be understood by looking at how individual neurons operate.
The future is multi-cellular. The cell walls aren't necessarily distance, but represent trust boundaries. It will never be the case that all data will be directly addressible. We wouldn't want it to be.
I like this. For anyone inspired by this description, I'd like to organanize some conversations around this. There are all kinds of dots that can be connected.
Let me know if you'll be in Portland the second week in July (OSCON, Applied XML DevCon) and I can set up a "What's Next?" discussion if there's interest. Meanwhile I'll be thinking out loud here and I'll be looking for other responses to this query.
From Sam Ruby's comments pages, on SOAP, WS-xxx, and CORBA...
Sam writes: What I like about the WS stack is that if all you need is SOAP document literal, all you need to implement is extremely small.
Reply: Yes, a great boon for adoption.
Dave Winer writes: SOAP was created by people who develop applications, so it didn't suffer from a lack of applications to pull it through.
Reply: Yes, a great boon for adoption! 8^) You folks were not about to create a CORBA first and then build apps later.
And this is a problem, as far as I can see, with the WS-xxx stuff taking place today, which is more like CORBA than it is like XML-RPC. Shouldn't the WS-xxx folks be working with OMG on that stuff? Why isn't "Enterprise Web Services" simply the next CORBA 4.0 release with SOAP optionally (but efficiently) slipped into the stack? There are high performance, open source implementations of much of CORBA 3.0.
I can think of at least one reason why not, but it's not a good reason.
From The Institution of Electrical Engineers (IEE) Proceedings Software, "View-centric reasoning for linda and tuple space computation" (PDF)...
Abstract: In contrast to sequential computation, concurrent computation gives rise to parallel events. Efforts to translate the history of concurrent computations into sequential event traces result in the potential uncertainty of the observed order of these events. Loosely coupled dis- tributed systems complicate this uncertainty even further by introducing the element of multiple imperfect observers of these parallel events. Properties of such systems are difficult to reason about, and in some cases, attempts to prove safety or liveness lead to ambiguities. We present a survey of challenges of reasoning about properties of concurrent systems. We then propose a new approach, view-centric reasoning, that avoids the problem of translating concurrency into a sequential representation. Finally. we demonstrate the usefulness of view-centric reasoning as a framework for disambiguating the meaning of tuple space predicate operations, versions of which exist commercially in IBM's T Spaces and Sun's JavaSpaces.
From an Infoworld interview with Bob Metcalfe...
Ethernet didn’t seem to have the problems that bedeviled IBM's Token Ring and ArcNet. Did this play a role in Ethernet's success?
Yes. Ethernet was simpler than its alternatives. It didn’t, for example, rely on the circulation and maintenance of the token. And Token Ring mathematically and, I think, sometimes unrealistically had advantages over Ethernet as long as the token was humming along. But if that token ever got lost or duplicated to create a storm, then things went to hell in a hand basket pretty quickly. The simplicity also allowed the implementations of Ethernet to be simpler and cheaper and come to market sooner. I mean, Ethernet beat Token Ring to market by five years. So that’s quite a lead. That’s probably what saved Ethernet from the IBM juggernaut.
