[SVHMPC] 0K Re: OpenMoko light web server

[Matthew S. Hamrick]

On Apr 17, 2007, at 4:46 PM, Paul Lambert wrote:

>
>
> Cool ... Comments:
>
> 1) I don't see the widget container and ECMAScript engine.  If  
> we're using
> HTML for display rendering, the architecture needs to include explicit
> considerations for a few core technologies.
>

It's implied that the browser on the desktop device will have a  
javascript engine.

> 2) The use of D-Bus creates an internal communication model that is
> different than the external.  Seems like some creative API mapping  
> could
> make the two types of communication similar.
>

yup. but you don't have to use it. It's included as an example. If  
you wanted to put an XML interface on Process Space A, and have  
Process Space B use that interface by talking XML over HTTP to  
127.0.0.1, that works too.

> 3) Why is there a browser on your server side picture?
>

Look closer, the legend is "Desktop Device or Server." Besides,  
servers sometimes have browsers on them if they're not configured  
properly. You'll generally only have a browser on a desktop device,  
but you might have custom apps that know how to speak XML over HTTP  
on either a server or a desktop device. I was too lazy to draw two  
boxes.

So you could say that this isn't an architecture diagram, but an  
example of an implementation of the architecture. The proper  
"abstract" architecture would replace "DBUS" with "Internal Inter- 
Object-Graph Access Mechanism" and "XML OVER HTTP" with "External  
Inter-Object-Graph Access Mechanism" and "Desktop Device or Server"  
with "Remote System." Mobile devices should be able to access other  
mobile devices using the External IOGAM.


> Paul
>
>
>
>
> Paul A. Lambert
> CTO, Picomobile Networks Inc.
> 256 Gibraltar Drive, Ste 108
> Sunnyvale, CA, 94089
> cell: +1-650-787-9141
> skype: paulatpico
>
>> -----Original Message-----
>> From: svhmpc-bounces at telefono.revejo.org [mailto:svhmpc-
>> bounces at telefono.revejo.org] On Behalf Of Matthew S. Hamrick
>> Sent: Tuesday, April 17, 2007 4:07 PM
>> To: SVHMPC; OpenMoko Community List
>> Subject: Re: [SVHMPC] 0K Re: OpenMoko light web server
>>
>> I think some of the context didn't get forwarded to one or both
>> lists. Here's a simple graphical overview of the "003 Software
>> Architecture." (003 is the next bit of software I'll be working on
>> for the myPhone.)
>>
>> Basically what you've got going here is that an "application" is
>> simply a collection of related objects in an object graph. Note they
>> may (or may not) all be in the same process space. When an object
>> wants to talk to another object in it's own process space, it simply
>> accesses it using features provided by the language or run-time
>> library. When it wants to access an object outside of it's address
>> space, it uses something like DBUS. But if you like OpenBinder or
>> CORBA, erase DBUS and write in the object middle ware of your choice.
>> (Extra points if you use a pointer in a single-address-space
>> operating-system.)
>>
>> When you want to provide a service to an "off device" machine (like a
>> server or a desktop device) you have an interface that maps the
>> object graph to an XML document. Queries are made to the device using
>> HTTP GET's where the path portion of the URI is an XPath
>> specification. Deletions use HTTP Deletes. Additions to collections
>> use POSTs with the path portion of the URI being an XPath
>> specification and the contents being the XML that represents an
>> object that modifies the state of the object graph.
>>
>> So if you queried this interface directly from your browser, you
>> would get an XML document back. So, for off device access, you might
>> want to have a page served off a server somewhere that then does
>> XMLHttpRequest() to the mobile device. Or, you could have the XML
>> interface on the device reference an xsl stylesheet somewhere.
>>
>> Note that I'm totally ignoring security in this document, but rest
>> assured I am thinking about various security concepts including TLS,
>> message oriented security over HTTP and coarse or fine-grained access
>> control to individual objects in the object graph based on user,
>> network or application credentials.
>>
>> -Cheers
>