Object-Oriented Networking

February 9, 2011

Computer languages become widely used if they are good at solving particular problems.

There have been several new or existing languages that have gained enormously in popularity over the past 15 years because they were well suited to solving problems related to the Internet:

  • Perl
  • PHP
  • Python
  • JavaScript
  • HTML
  • CSS

Perl is an *interesting* language with verbs like “die”, “croak”, “confess”, and “bless”. It is not *elegant* (like Pascal) but it certainly is *useful*.

Same thing for PHP which can mix HTML and code in very creative ways.

And Python (after “Monty Python”) with its minimal syntax and lots of time-saving shortcuts.

These three languages are hugely popular and share several things in common:

  • they were created for solving *real world* problems
  • they were originally created by single programmers, not committees
  • they are open source
  • they developed new programming styles to fit new environments
  • they weren’t afraid to experiment and evolve

Smalltalk enthusiasts want their language to become more popular.

IMHO, the secret to doing this is finding the correct problem to be solved – a problem that can be solved better by Smalltalk than any other programming language.

Consider how the Internet is evolving. Starting in 1969, solutions were developed for connecting large networks of machines (IP, TCP/IP, FTP, etc). Then, after 1989, the “World Wide Web” introduced several innovations that made the Internet usable for much larger numbers of people (DNS, URL, HTTP, HTML, CSS, etc).

Now, in 2011, the W3 “page-oriented” model is becoming outdated:

  1. users want real-time interactivity
  2. users want graphical, interactive interfaces
  3. there are new types of devices like smart-phones and iPads with different form factors
  4. many users want to share some data with friends (social networking)
  5. interfaces are becoming much more complex (work collaboration, etc)

So, I propose a new model for developing user applications which I call “Object-Oriented Networking”.

In O2N, serialized Smalltalk messages are exchanged amongst clients and servers. And we can specify standard ways to transmit and receive objects – say NetIn and NetOut (like UNIX).

The list of challenges (1-5) above are much easier to address in Smalltalk than any of the other currently available solutions.

And QuickSilver is small, fast, open source, and able to run in any of the billon+ Internet devices that support JavaScript.

New environments require new solutions – or old solutions (like Lisp and Smalltalk) that have been rediscovered.

— Peter


11 Responses to “Object-Oriented Networking”

  1. Andy Burnett Says:

    I think that is a great list. I would add two more thoughts:
    1. people want to be able to easily ‘mashup’ data from elsewhere. I know point 4 covers sharing data, but I am talking about being able to reprocess and integrate it. This is one of the things that really excites me about SST being able to generate javascript which could offer a collection of objects for e.g. pulling in Google Spreadsheet data seamlessly.

    2. Security. Let’s get it right this time :-). Let’s make sure that all network traffic is encrypted, and authenticated. Let’s make that absolutely fundamental to how SST works. So, that it just isn’t possible to write a program that ignores security (OK, that might be a bit ambitious, but it is still a nice thing to shoot for!).

    Ideally, I would like to see strong crypto built right into all message sends. Collaboration with your colleagues then involves exchanging public keys, and you are away.

    • Peter Fisk Says:

      Yes, those are good points.

      I was thinking that the NetIn object could redirect incoming messages based on the sender and/or subject. Very fine-grained integration.

      You are right about security. Object-oriented networks are really ad hoc private networks and they should be secure as much as possible from eavesdropping.

      — Peter

  2. Jose Says:

    Do you know REST?


    Please I don’t build another: RPC, CORBA, EJB, SOAP,…

    If you see REST/HTTP you can discover the best distributed system of the world:

  3. Jose Says:

    In the past, method (message) centric architectures failed (RPC, CORBA, EJB, SOAP).

    Other architecture, as REST, allows:

    · Javascript/AJAX: allows real-time interactivity.

    · allows communication based on content-type negotiation, with language independence (for example: a javascript client can request data/object on json format and java server can generate objects in that format).

    note: client can request any data format and encoding (javascript/json , text/csv, text/xml, text/html…) only using http headers.

    · Security: you can use HTTPS (SSL) with mutual (server & client) certification authorisation => your web-server do it for you.

    · using query-string (findBy… criteria) and http-body on any format (javascript/json , text/csv, text/xml, text/html…) to send data/parameters.

    · force to you to think on resources (URIs) that you, or your application, offers to clients.

    · http methods (GET, POST, PUT, DELETE) are not a limitation.

    HTTP is “old” communication protocol that is new again…

  4. Jose Says:

    Of course, I think on any distributed system, including Client-Server, on any language (Smalltalk-to-Smalltalk is one possibility).

    Imagine a “transparent comunication” between client (browser with QST) and server (REST framework on QST) that use RESTfull comunication (AJAX+JSON)…

    ** Java has REST on JSR311 (JAX-RS) based on anotations (I love it) => reference implementation http://jersey.java.net/

  5. Peter Fisk Says:

    Initially, I will be using http between QST and Google App Engine’s ChannelAPI.

    Testing will start tomorrow.

    — Peter

  6. Jose Says:

    After read some on ChannelAPI, is good on conversational communications between end-to-end users…

    · Your client acts as consumer (or listener) of events recived via channel from generators.
    · Your client acts as event generator via http post.

    —— * only supported by google servers?

  7. Jesús Díaz Says:

    I’ve just been aware of Smaltalk while reading Martin Fowler’s UML distilled and would like to ask one simple -perhaps innocent- question: can Smalltalk applications be inserted or embedded in HTML or PHP code as Java applets or Flash movies can?

    Thanks a lot.

    Sorry my (Java based: http://doremitutor.com) site is still under construction and only in spanish yet.

  8. Peter Fisk Says:

    Hi Jesus,

    QuickSilver Smalltalk can be used anywhere that JavaScript can be used.

    That would include embedding it in HTML and PHP code.

    — Peter

  9. Jesús Díaz Says:

    Sounds wonderful to me, Peter.

    That makes learning SmallTalk one of my next projects.

    Thanks a lot. I’ll keep visiting you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: