Re: OpenMoko light web server

[Tim Newsom]

On Mon, 16 Apr 2007 13:58, Matthew S. Hamrick wrote:

Okay.. a few points:




Q. javascript? on a phone? Isn't that going to suck down the power?

A. in a word, yes. But I think the main problem will not be the added 
overhead of using javascript, it's going to be the frequent request / 
response. In the old days when we bundled ORBs with browsers, we could 
execute java (and presumably have a javascript interface) that would 
receive asynchronous messages from the server. Why is this important? 
Because the phone (on the other side of the http interface) is going to 
ring or receive an sms message or the signal is going to go up or down. 
And these are things that occur outside the context of a client 
request. So, if you want to see if the phone just rang, you have to 
keep pinging the web server every second or so, and if it responds with 
"I'm ringing," you fire off the javascript that draws the "I'm ringing" 
icon on the interface. All in all this is pretty substandard.




Ok.. Well this is probably somewhat browser specific, but in the 
XMLHttpRequest methods there is a synchronous or asynchronous flag.  
Synchronously will behave in the normal request response method and wait 
for a return before continuing to execute... Async will allow the code 
to continue executing and then fire the response once it sees it.  I 
don't know if there are timeouts or not and I have not played around 
with it much, but it seems like you could build several request 
objects... One might be dedicated to the ringing function.. Then place a 
timer on it and if there is no response by the timeout you could reset.  
All the request would do is ask if the phone rang and wait.. Then your 
cgi code could sit for the period of the timeout waiting for either a 
request (to cover the situation of the phone ringing between requests) 
or responding when the phone rings...


This should be more like the subscription model where you ask to be 
notified and at any point it could happen.  But, like I said, it may be 
browser specific. /shrug

Just something to look into maybe.
--Tim

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Florent THIERY]

Q. is an XSS worm on the way?
A. not unless you make your interface susceptible to known web app
vulnerabilities: XSS, SQL Injection, session hijacking, etc.


Don't misunderstand me, i am 100% for mixing web & local app through a
web interface: I am very interested in netvibe's "universal" widget
API ( http://dev.netvibes.com/ ), as well as openkapow
(http://openkapow.org/ ) which could allow to compose your OS
following your needs. You could even port the local widgets back (if
they follow the API) and use them (in a limited fashion) on your
desktop...


I'm doing to prevent it. 1) I'm going to run my code through an automated
scanner. I recommend these things to everyone. [...]


Glad to see that you had security in mind from the beginning ! I mean
the question had to be asked, as you are doing GUI experimentation :)


So, if you want to see
if the phone just rang, you have to keep pinging the web server every second
or so, and if it responds with "I'm ringing," you fire off the javascript
that draws the "I'm ringing" icon on the interface.


No, this doesn't seem very energy-sparing...


stinkin' feature, it is. But IIOP with a Java or Smalltalk BOA can be
implemented fairly easily and without bloat.


Talking about squeak, what about http://www.seaside.st ?

Florent

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Matthew S. Hamrick]

Okay.. a few points:

Q. is an XSS worm on the way?
A. not unless you make your interface susceptible to known web app  
vulnerabilities: XSS, SQL Injection, session hijacking, etc. Of  
course, it's very hard to disprove the existence of a vulnerability,  
but I can say what I'm doing to prevent it. 1) I'm going to run my  
code through an automated scanner. I recommend these things to  
everyone. They're great in helping you spot overlooked  
vulnerabilities. 2) I'm going to use an XML Post interface where the  
client constructs XML and each message is MAC'ed. What I don't have  
working yet is the hash chain code to prevent replay attacks. But...  
I am thinking about it. This helps prevent XSS because I don't use  
cookies. XSS tends to require a cookie-based login/session paradigm.  
I suspect it's still possible for a bad guy to mail you some  
javascript that could be executed in the same browser after you've  
logged in, so I won't discount the possibility. But I have actually  
been thinking about the security of this thing.


Q. Only on the same host? I.e. - will you only be able to access the  
interface through 127.0.0.1?
A. Hey! Where's the fun in that! One of the things I would like to do  
is have a platform where we can experiment with new ways of thinking  
about mobile devices. If you're frightened by the security  
implications... well... there's nothing I can do about that. But...  
I'll tell you what... I'll ship everything with defaults setup to not  
allow remote connections (so you would have to ssh in to change this  
default.)


Q. javascript? on a phone? Isn't that going to suck down the power?
A. in a word, yes. But I think the main problem will not be the added  
overhead of using javascript, it's going to be the frequent request /  
response. In the old days when we bundled ORBs with browsers, we  
could execute java (and presumably have a javascript interface) that  
would receive asynchronous messages from the server. Why is this  
important? Because the phone (on the other side of the http  
interface) is going to ring or receive an sms message or the signal  
is going to go up or down. And these are things that occur outside  
the context of a client request. So, if you want to see if the phone  
just rang, you have to keep pinging the web server every second or  
so, and if it responds with "I'm ringing," you fire off the  
javascript that draws the "I'm ringing" icon on the interface. All in  
all this is pretty substandard.


Q. Did you just say you're going to put CORBA on my beautiful phone?
A. No. I was just using it as an example. Everyone has this  
idea that CORBA is big and blobular and fat. Well... if you implement  
every stinkin' feature, it is. But IIOP with a Java or Smalltalk BOA  
can be implemented fairly easily and without bloat. And it can be  
made reasonably secure with IIOP over TLS or CORBASec level 2 if  
you're a masochist. I would like to use CORBA on one of my devices,  
and I probably will. But every time I mention it, people who have  
never used it wretch violently and wax poetic about SOAP. No... I'm  
going to do something much worse than CORBA, I'm going to use RPC.  
No... not XML-RPC, honest to God XDL/Sun/No way to secure it RPC. So  
there!


Okay I'm better now. But seriously, I think the added complexity  
of forcing a request/response model on top of an application that  
clearly must require support for asynchronous events is the worst  
problem we're going to face. I've sorta thought that a custom  
application, and not a browser, will be the primary consumer of the  
XML generated by jowles or 003 (003 is a follow-on to jowles.) So we  
might be able to take a few liberties with HTTP. Like keeping the  
HTTP connection up between requests and allowing the server to send  
responses that aren't bound to requests when asynch events occur.  
It's a hack, and it will probably break the javascript version of the  
interface, but hey! it's probably better than trying to get everyone  
on the list to put their brain-stems around CORBA (or even SOAP.)


Q. Widgets. Why is it always Widgets?
A. Yes. I like widgets. jowles won't be a widget infrastructure, but  
003, it's successor will be.



On Apr 16, 2007, at 12:47 PM, Frank Coenen wrote:

I agree. I don't fancy giving any acces to the phone from a remote  
location. Exept via SSH or something.


Locally 'installed' web-apps would be great though.
http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX  
and iPhone widgets, SuperKaramba)
http + CSS + Javascript + some kind of plug-in that has excess to  
the phones hardware = widgets on steroids.
Making it much easier to write applications (widgets) with exotic  
interfaces, you're no longer tied to OpenMoko/GTK+ toolkit.


It will of course drain more recourse's than native code, in stead  
of run time stuff like javascript.



On 4/16/07, Frank Coenen < [EMAIL PROTECTED]> wrote:
I agree. I don't fancy giving any acc

Fwd: OpenMoko light web server

[Richard Boehme]

Locally 'installed' web-apps would be great though.


My thought was that I have two standalone apps, one on the phone
displayed via the phone's web server that's restricted to localhost,
and one which is running on a normal copy of Apache. However, I only
have to maintain one display code base.

Thanks.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Frank Coenen]

I agree. I don't fancy giving any acces to the phone from a remote location.
Exept via SSH or something.

Locally 'installed' web-apps would be great though.
http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX and
iPhone widgets, SuperKaramba)
http + CSS + Javascript + some kind of plug-in that has excess to the phones
hardware = widgets on steroids.
Making it much easier to write applications (widgets) with exotic
interfaces, you're no longer tied to OpenMoko/GTK+ toolkit.

It will of course drain more recourse's than native code, in stead of run
time stuff like javascript.


On 4/16/07, Frank Coenen <[EMAIL PROTECTED]> wrote:


I agree. I don't fancy giving any acces to the phone from a remote
location. Exept via SSH or something.

Locally 'installed' web-apps would be great though.
http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX and
iPhone widgets, SuperKaramba)
http + CSS + Javascript + some kind of plug-in that has excess to the
phones hardware = widgets on steroids.
Making it much easier to write applications (widgets)
with exotic interfaces, you're no longer tied to OpenMoko/GTK+ toolkit.

It will of course drain more recourse's than native code, in stead of run
time stuff like javascript.

On 4/16/07, Florent THIERY < [EMAIL PROTECTED]> wrote:

> If the GUI is web-based, then we can mix offline and online apps at
> will, transparently ! Yet, if you want a "sexy" interface, you'd want to use
> AJAX, right?
>
> Quite frightening in terms of security... An XSS dialer worm on it's
> way? :)
>
>
> Cheers
>
> Florent
>
> ___
> OpenMoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Florent THIERY]

If the GUI is web-based, then we can mix offline and online apps at will,
transparently ! Yet, if you want a "sexy" interface, you'd want to use AJAX,
right?

Quite frightening in terms of security... An XSS dialer worm on it's way? :)


Cheers

Florent
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Neo1973 With Screen On at PopSci!

[Chris Fazekas]

Maybe you could scan the article int .pdf for a Media section of the
Wiki?  I don't get Popular Science, but would love to see any real
media on openmoko!

Cheers,

Chris



On 4/15/07, Mike Hodson <[EMAIL PROTECTED]> wrote:

On 2/23/07, Bryan Fink <[EMAIL PROTECTED]> wrote:
> Hi All.  I was just browsing for Neo1973 pictures, as I do every few
> days, and finally found pictures of a Neo with the screen on!  Check
> out Popular Science's 10-photo gallery:


Sorry to rehash quite an old thread, but today I received my copy of
Popular Science magazine for the month of May 07, and the Neo1973 is
on the front cover, headline "iPhone's Open-Source Rival"

The full-page article starts off this month's "What's New" section,
and goes on to include a wonderful hi-res image of the phone mockup.
The story talks about how providers control the content on your phone,
and gives some speculation of new apps that will be invented: "Imagine
if the phone's microphone could tell you are having an in-person
conversation and hold all calls" among others.

This is great!

Mike

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: OpenMoko light web server

[Dean Collins]

Yep, I love when I first started talking about 3rd party off-device
commercial applications 6 months ago everyone said "bo"

 

Now people are truly understanding what I was talking about with Savaje
at Javaone 2006 and now with Openmoko. www.Collins.net.pr/blog

 

The device isn't the exciting part here guys, it's what you can do
off-device with network apps that's exciting.

 

 

Cheers,

Dean Collins
[EMAIL PROTECTED] 

+1-212-203-4357 Ph
+61-2-9016-5642 (Sydney in-dial).

    
 


> -Original Message-

> From: [EMAIL PROTECTED] [mailto:community-

> [EMAIL PROTECTED] On Behalf Of Matthew S. Hamrick

> Sent: Monday, 16 April 2007 1:12 PM

> To: Richard Boehme

> Cc: community@lists.openmoko.org

> Subject: Re: OpenMoko light web server

> 

> Yeah... there's been some discussion of this already on the SVHMPC
list.

> 

> At first people rejected the idea as being "silly." I mean seriously,

> why would you ever want to put a web server on an embedded device,

> right?

> 



image001.gif
Description: image001.gif
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Matthew S. Hamrick]

I didn't realize busybox had a httpd daemon.

I've been concentrating on boa (lightweight web server), jowlesd (a  
daemon to communicate with the GSM module), and jowlesc (the cgi-bin  
client that simply forwards XML to jowlesd over a named pipe.)


If you're httpd daemon can handle CGI (passing request metadata in  
environment variables and the body of the request to stdin) then you  
should be okay with the jowles stuff. I'm trying as hard as I can to  
be httpd server agnostic as I like using apache on my mac and there's  
talk from the gumstix community about moving away from boa. Also...  
if my Nokia 770 has busybox with a httpd server, then I could use it  
as another test platform.


-Cheers!
-Matt H.

On Apr 16, 2007, at 10:13 AM, Al Johnson wrote:

Would the httpd in busybox be sufficient? I'm assuming (perhaps  
wrongly) that
busybox will be present since it's in most embedded linux  
installations.


On Monday 16 April 2007 17:35, Richard Boehme wrote:

It would be really nice if OpenMoko had a light web server so that we
could write CGI scripts that would have an OpenMoko stylesheet  
applied

to them. That way, we could make OpenMoko apps that we would be able
to also deploy on normal web servers without having to maintain a
"OpenMoko" GUI and a web interface.

Thoughts?

Thanks.

Richard Boehme

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[michael]

On Mon, 16 Apr 2007, Richard Boehme wrote:


It would be really nice if OpenMoko had a light web server so that we
could write CGI scripts that would have an OpenMoko stylesheet applied
to them. That way, we could make OpenMoko apps that we would be able
to also deploy on normal web servers without having to maintain a
"OpenMoko" GUI and a web interface.

Thoughts?

Thanks.

Richard Boehme


Funny, they just had a related discussion on the SVHMPC list. You didn't come
from there, did you? :-)

There was a long discussion on the merits and (what's the opposite of merits?)
of doing a UI this way, but at the end of the day I (and a few others) agree
this is a very interesting and useful idea. I personally like the ability to
quickly create a GUI without having to code a GUI or link to any GUI library.

There are many lightweight web servers available, and many should port to
OpenMoko with no difficulty. If I were you, I would add this to the list of
requested apps. To help move it along, you can also do a quick survey of small
footprint embedded web servers (tinyhttpd comes to mind) and provide a list of
candidates. If CGI support is not automatic in all servers (I know very little
about that area) then you can help by identifying servers that support this,
and whatever other features you require. (I would list servers that don't
provide what you need, so that others will know why you didn't recommend their
favorite server)

Michael

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Al Johnson]

Would the httpd in busybox be sufficient? I'm assuming (perhaps wrongly) that 
busybox will be present since it's in most embedded linux installations.

On Monday 16 April 2007 17:35, Richard Boehme wrote:
> It would be really nice if OpenMoko had a light web server so that we
> could write CGI scripts that would have an OpenMoko stylesheet applied
> to them. That way, we could make OpenMoko apps that we would be able
> to also deploy on normal web servers without having to maintain a
> "OpenMoko" GUI and a web interface.
>
> Thoughts?
>
> Thanks.
>
> Richard Boehme
>
> ___
> OpenMoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko light web server

[Matthew S. Hamrick]

Yeah... there's been some discussion of this already on the SVHMPC list.

At first people rejected the idea as being "silly." I mean seriously,  
why would you ever want to put a web server on an embedded device,  
right?


Then we started thinking about the tools that are available to web  
developers and realized it wasn't _THAT_ silly of an idea.


I'm actually working on a simple XML/XHTML based interface onboard a  
GumStix based homebrew mobile. You can see an early experiment at  
http://hbmobile.org/jowles/ .


The jowles interface has html and javascript as the front end and a  
cgi script that receives XML Posts as requests to do things (like  
query status, dial the phone, etc.) The server spits back XML which  
the javascript parses and displays.


The idea here is that the myPhone ( http://www.hbmobile.org/wiki/ 
index.php?title=MyPhone ) is going to be a linux device, so while  
some people are off doing the hardware, we can start developing a  
simple interface on our Unix systems that are plugged into Telit  
modules ( http://www.sparkfun.com/commerce/product_info.php? 
products_id=280 ).


Why is this apropos to OpenMoko? Well... after doing the Vulcan mind  
meld with Sean over beers at eTel, it dawned on a lot of us myPhone  
guys that we're really all on the same side here... and many of us  
are interested in porting OpenMoko to our open myPhone hardware.


So... what we're looking at building in the next week or so is...

* a gumstix hooked to a telit module via a serial port
* a PC / Macintosh hooked to the gumstix via a USB cable

and then the software:

* Firefox on the PC talking to the boa server on the Gumstix
* boa handing off to our custom GGI-BIN that parses and produces XML  
to control (and query the state of) the telit module

* javascript and HTML that provides a UI to control the phone.

at some point I would love for this to develop into a wonderfully  
componentized system where application developers can drag and drop  
components into a container, hit the "deploy" button and miraculously  
the software on your phone is updated. But for now it's just a simple  
C app.


also... I would love to have this stuff work well with the OpenMoko  
components instead of just libgsmc. maybe in the future we'll define  
a component architecture so app developers could define an XML  
interface that jowles could use to control things other than just the  
dialer.


-Cheers!
-Matt H.

On Apr 16, 2007, at 9:35 AM, Richard Boehme wrote:


It would be really nice if OpenMoko had a light web server so that we
could write CGI scripts that would have an OpenMoko stylesheet applied
to them. That way, we could make OpenMoko apps that we would be able
to also deploy on normal web servers without having to maintain a
"OpenMoko" GUI and a web interface.

Thoughts?

Thanks.

Richard Boehme

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

OpenMoko light web server

[Richard Boehme]

It would be really nice if OpenMoko had a light web server so that we
could write CGI scripts that would have an OpenMoko stylesheet applied
to them. That way, we could make OpenMoko apps that we would be able
to also deploy on normal web servers without having to maintain a
"OpenMoko" GUI and a web interface.

Thoughts?

Thanks.

Richard Boehme

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: CrossPlatform Programming

[adrian cockcroft]

There is a comparison of GTK+ and QT for mobile applications at this URL

http://www.hbmobile.org/wiki/index.php?title=GUI_Frameworks

Adrian

On 4/15/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote:

xnike writes:
>I just want to know is it good idea to use qt4 (not Qtopia) for
>OpenMoko's apps?

Probably not, unless you've got a compelling reason to use it.
Openmoko itself is GTK-based, so a non-GTK application will require
lots of extra libraries on a platform that really doesn't have much
room for them.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community