[SVHMPC] 0K Re: OpenMoko light web server

[Matthew S. Hamrick]

Just assume that process space "B" is the browser

On Apr 17, 2007, at 5:52 PM, Paul Lambert wrote:

>
>
>
>
>> -----Original Message-----
>> 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.
>
> Yes ... but I meant on the mobile device.  I'm still on the widget  
> driven
> GUI concept.  Having a single common rendering approach using HTML/ 
> Widgets
> would provide some interesting advantages.
>
> Paul
>
>
>
>
>
>>
>>> 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
>>>
>>
>>
>> _______________________________________________
>> SVHMPC mailing list
>> SVHMPC at telefono.revejo.org
>> http://telefono.revejo.org/mailman/listinfo/ 
>> svhmpc_telefono.revejo.org
>
>
> Paul A. Lambert
> CTO, Picomobile Networks Inc.
> 256 Gibraltar Drive, Ste 108
> Sunnyvale, CA, 94089
> cell: +1-650-787-9141
> skype: paulatpico
>