Object Oriented Internet

Some interesting questions:

Is the WorldWideWeb ObjectOriented?
Should it be?

Is the WWW OO?

Points For:

UniformResourceIdentifiers serve a similar role to object references.
POST in HTTP serves a similar role to message-passing.
Remote services offer encapsulation and information hiding.

Points Against:

No effective support for 'classes' or 'inheritance'.
The best properties of the web are achieved via RESTful data sharing (AskDontTell?). Compare: common OO advice is TellDontAsk.
We are not offered the illusion of a unique relationship between URIs and objects. For example, everyone sees a different 'iGoogle', and 'forms' with a shared URI are not shared forms (no collaborative editing). (See DocumentDefinitions for some different visions here.)
We cannot effectively share a URI and API to a particular document object (such as a particular <div>) in a browser, even though TimBernersLee did dream of it.
We rarely use OOP idioms or SoftwareDesignPatterns on the internet. I.e. when was the last time you created an intermediate web-object (with a unique URI) that supported a StrategyPattern or StatePattern? As of 2011, the answer is probably never even heard, seen, or thought about it, excepting as you mentioned it just now.
In OOP, we build useful applications mostly by creating new objects. In WWW, we build useful applications mostly by gluing or orchestrating existing objects.
Referenced objects in the web rarely control their own state. They push it to a shared database, subject to many other views.
The most flexible and efficient StateOfTheArt SecurityModel is ObjectOriented - the ObjectCapabilityModel. Guess what? The web doesn't use it. Instead, the modern web uses a non-composable, inefficient, weak SecurityModel - i.e. your content is only as secure as your least trusted CertificateAuthority, including the intermediates. (You might trust VeriSign, but do you trust everyone Verisign trusts?)

Should the WWW be OO?

The use of URIs to uniquely name and identify resources is not a necessary condition for the web to exist.

Another possibility is ContentCentricNetworking, the ability to link sites relationally, based on content or data - i.e. given one site about cats, you can find other sites about cats. SearchEngines sort of build this model atop the web as it exists, but this idea could easily be built in at a more fundamental level. Solutions to discovery and dependency management are commonly based around content - i.e. "find me a service that does XYZ with a given API". This is much more robust and resilient than identifying services by specific name, because it means we can fall-back to alternative services if the first choice is disrupted or deprecated.

We could live in a world without named content at all - i.e. where references are universally replaced by potentially ambiguous descriptions. That ambiguity isn't a bad thing, since it allows fallback. For security, we could trust content based on signatures... though, unfortunately, this still has many composition and performance problems.

Personally, I think ObjectCapabilityModel is the only thing OOP has to offer to the Internet. We could, for example, share content via a network of fine-grained registries. We can separate the ability to publish to a registry from the ability to read it. If we start getting spammed, we simply revoke the spammer's capability. This gives us our trusted network of content (though we can choose to trust a 'global' search engine in some cases), yet allows developers to focus on the content.

In summary, I would answer both questions with 'No'.

Before you conclude, reconsider the question without the legacy ClientServer model and implementing a PeerToPeer network utilizing a UnifiedDataModel to make a DataEcosystem. But otherwise you're right: the current motley universe of internet "objects" is too personal, unstable, and un-reusable. -- MarkJanssen

Is the WWW Object Oriented? [from ScalingOopDiscussion]

As far as "The web being OOP", I disagree. It is navigational, but not OO. And a relational wrapper can be put around it. Relational does not define implementation, thus having a billion "records" scattered physically all over the world does not mean they are not "relational". It merely means implementation is slow as hell. Thus, your web example fails. - t

Relational restricts implementation. To be "relational", you'd need to guarantee properties that are assumed by the RelationalModel and by a RelationalAlgebra or RelationalCalculus. Otherwise it simply ain't relational. You cannot do that with the web. You could probably provide query-access to some of the web - whatever you can reach with an HTTP:GET command, perhaps, since those are supposed to not have side-effects - but the web has much more than 'GET' commands, you aren't even beginning to consider use of cookies or streaming data, and you'll still fail to achieve the RelationalModel integrity properties even for the read-only operations. Web-pages, for example, will change without waiting for transactional permission from your relational 'wrapper'.

I'm not a purist, like some people are. If one has to dirty up relational a bit to fit the requirements or emulation, so be it. Further, the reader (query writer) may not know if the force changing web pages is another DB user or not.

This coming from a guy who continuously asks for 'objective and unambiguous' definitions? That's quite some hypocrisy, TopMind. Dirty reads, done dirt cheap? Reads with arbitrary side-effects? Writes inconsistent with any relational model? Complete inability to maintain any sort of integrity? Random inability to locate certain data? Sweet! I'll call it "relational". What's that sound? that couldn't possibly be EfCodd rolling over in his grave...

ACID is not part of RelationalAlgebra. It's a nice tool/feature, but it's also nice to be able to switch it off in exchange for certain performance gains. Re: "Dirty reads, done dirt cheap". Catchy, I like. - t

It is true that ACID is not part of the RelationalAlgebra, but it is also not 'merely' a "nice tool/feature". ACID is used to ensure integrity with the RelationalModel in the face of concurrency (Isolation) and partial-failure (Atomicity). The Consistency and Durability properties are irrelevant to RelationalAlgebra in general, but are somewhat useful for a DBMS. Fundamentally, you are not using RelationalAlgebra if the result of computations are not the same as what the RelationalAlgebra mathematics say it should be. You're instead using some ad-hoc not-quite-relational algebra. That's probably GoodEnough for some applications - such as browsing the web - but the more compromises you make the less relational-like you are. (And I can't take credit for the 'dirty reads' phrase.)

And the web isn't OO because one can put an OO-wrapper around it. It's OO because that's how developers of web systems - such as web servers, applications, etc. - organize the web. It's a collection of objects, named by URI or IP:PORT, to which you can send messages. These objects process the messages and act accordingly. The Web currently lacks the sort of 'smart network' (i.e. ability to filter, transform, route by content) needed to claim 'dataflow language' properties, though those have been implemented to a lesser degree by careful use of objects. The web isn't at all organized by use of the relational model... not even if one 'could' put a relational wrapper on it, which one can't.

"Collection of objects" is too wide to have any real meaning.

Then it's a good thing I didn't use that term by itself as though it were a complete descriptor, ain't it?

The web is more like navigational predicates than objects. There's no object identity (state) in HTTP. As far as "UniformResourceIdentifiers? serve a similar role to object references", they identify unique method names, but not object instances. - t