> -----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 telefono.revejo.org
[mailto:svhmpc-
> >> bouncestelefono.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
> SVHMPCtelefono.revejo.org
> http://telefono.revejo.org/mailman/listinf
o/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
_______________________________________________
OpenMoko community mailing list
communitylists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
|