[SVHMPC] 0K Re: OpenMoko light web server

Paul Lambert Paul at PicoMobileNet.com
Wed Apr 18 02:52:37 CEST 2007





> -----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





More information about the community mailing list