RongChen

As of this month, we finally come to code freeze of Elastos after six long years. I can't help but thinking Elastos and Mozilla really designed to complement each other. Elastos is an infrastructure (aka operating system), and Mozilla is a browser (for lack of a better word). Together, they form the next generation of infrastructure technologies.

Rong Chen

==

Why Elastos?

==

6-1-2006

The opportunities for Elastos 3rd generation Internet

    (1st - Email, 2nd - Browser, 3rd - WEB Services), 3rd generation programming paradigm
    (1st - structure oriented, 2nd - object oriented, 3rd - WEB Services), 3rd generation operating system
    (1st - DOS, 2nd - Windows, 3rd - WEB Services),

3rd generation mobile phone and

    (1st analog, 2nd - digital, 3rd - wireless broadband) 3rd generation digital TV markets
    (1st - Black-n-white, 2nd - Color, 3rd - HDTV with broadband cable)

Four key Elastos' technologies: (1) Replacing program file names with URLs (2) Using XML+JavaScript to write GUI (3) C++ classes are automatically scriptable (4) Cross platforms, such as Windows, Linux, etc.

Of course, we also implemented a full powered, component based OS in C/C++.

Next are 10 problems we solved along the way:

(1) Seamless computing Problem: c:\windows\system32\drivers\tcpip.sys

Solution: //www.elastos.com/car/drivers/tcpip.dll

(2) No software installation Problem:

      registry

Solution:

      manifest

(3) Binary code versioning Problem:

      allocating memory on stack

Solution:

      allocate memory on heap

(4) Binary module interoperability Problem:

      naked binary or incompatible symbols

Solution:

      contract/interface based programming
      and meta-class

(5) TCP/IP is irrelevant to programming paradigm Problem:

      X-Window died

Solution:

      WEB Services and dynamic proxy

(6) Windows as an obsolete programming paradigm Problem:

      WinProc() assumes source code
      availability

Solution:

      function callback table & design
      mouse-move-over et al as aspects

(7) Avoid explicit message passing Problem:

      polling can't extend to distributed
      computing

Solution:

      asynchronous pushing events

(8) Scripting GUI vs. codec engines Problem:

      scripts are flexible but slow;
      computations are limited to fixed API set

Solution:

      directly scripting codec engines with
      reflection

(9) Unified storage model Problem:

      application data files are isolated

Solution:

      XML and database

(10) Software manufacturing at runtime Problem:

      C/C++ objects are source code bound

Solution:

     component aggregates aspects to
     form assembly in context

Q & A What is Elastos?

     A software platform for the Internet programming era.

Why do we invent Elastos?

     To answer above 10 questions with a simple solution.

When do we have Elastos available for partners?

     2006.6.

Who do we target Elastos?

     Embedded software ISVs and design houses.

How do we categorize Elastos?

     Enabling very efficient WEB services in native binary code, complementing WEB services of JAVA or .NET.

1. I have download the Yahoo! Widget and can I assume what you are talking about is very similar to it ?

[chenrong] They only look similar on the surface. We both have XML+JavaScript in common, which confirmed what we have been doing for XML+the last six years. Yahoo!Widgets themselves, on the other hand, are developed by many people from all over the world. We copied a few of their pictures to make our widgets attractive. But underline Widget Engine infrastructure are very much different. We have done a real OS, capable to do everything that a computer could do, whereas Yahoo!Widget Engine is much like toy which could only do 300 tags or so, and their widgets are limited to only what the tags could do. Yahoo!Widget Engine is not very extendable especially not by other ISV's, that is why they would have a hard time to move to they phone market, if not impossible, for example.

2. once you have several tasks running on the mobile phone to periodically pulling the information from different URLs on the server I assume it would make entire phone running very slow because every tasks in competing the cpu and communication (event is 3G) bandwidth?

[chenrong] All we are doing is to enable XML+JavaScript to render UI, which can be done in C language as well, in case performance is an issue. LSB services are within a browser like application. We have finished our sample phone, and our performance is on par, if not better, than the phone which OS was replaced by us. XML enabling is by choice. URL to replace C: drive file path has no performance impact by itself. If URL always match what on your local drive, you don't have to go on line either. In C: drive case, all software must preinstall on the C: drive. Again, we give people a choice, if you have network and happen to not having the code you need, the application addressed by URL still works. The power of unified programming model, like browsers for data access model, is the key to our technology.

3. is this kind of new operating system on the mobile phone so it needs new industry standard if not, how easy do you think every mobile phone makers would be willing to install this?

[chenrong] We reply on the same infrastructure such as HTTP, XML, HTML, TCP/IP etc. But in the future, I think when more P2P like infrastructures are available, Elastos will demonstrate more flexibility and power. For example, people may play games on a train, without having to have a cell phone connection at all. Only when people do not want to preinstall games or other programs, and they want to use URL to transparently access them, then they have to have our OS or middleware installed on their phone. We are in the process of implementing Elastos VM for WinCE, Windows and Linux. You may compare us with Java. You only need Java when you play Java games. The difference between Java and us is that we use native code and Java uses byte code. I believe performance, driver installation, and XML will prove our solution has advantages. We support Java, by the way. And 95% or more phones are ARM based so byte code and native code will all run. Yet we run faster!

4. Assume this is something quite like Yahoo! Widget on the PC there are going to be more 1000 of them and with such small screen of mobile phone would that be a problem for user experience?

[chenrong] User plays with one widget at a time. He downloads widget just like downloading ring tones. Widgets could be anything, whether they look like widget or not as long as they are composed with XML and JavaScript. For example, a stop watch looks like a real stop watch, and a calculator looks like a calculator on our phone. It is cool, but not have to be more useful than other stop watches or calculators. It's a fashion thing. Again, we provide choices that current smartphones do not give to people. And we enable advertisements if people would like to pay less for their phone bill.