f



in-client web server

Hi,

I am working on a thick-client application that serves
a lot of content as locally generated and modified
web pages.

I'm beginning to look at serving (and updating, via AJAX)
these pages from a web server running within the client
(mostly to provide a more natural and powerful way of
interacting with the browser control).

For a first cut I imagine just starting a web server within
the client and serving the pages from localhost:<someport>.

I have a couple questions for anyone with experience with
this sort of architecture:

 * First, are there any existing open source libraries that
   exemplify this approach?  I have a vague recollection that
   TurboGears started out based on a project with this kind
   of architecture, but I haven't been able to find anything
   so far.

 * Second, are there any gotchas you would point out?  In
   particular I'm wondering if even this localhost connection
   will be a problem with many users' firewalls.

In case it matters, the application is being developed in python
2.5.x with wxPython 2.8.x, aimed first at a Windows platform,
but intended to be portable to Linux and Mac ASAP.

Thanks for any pointers,
David
0
12/16/2007 12:39:33 AM
comp.lang.python 77058 articles. 6 followers. Post Follow

2 Replies
638 Views

Similar Articles

[PageSpeed] 0

David Montgomery wrote:
> Hi,
> 
> I am working on a thick-client application that serves
> a lot of content as locally generated and modified
> web pages.
> 
> I'm beginning to look at serving (and updating, via AJAX)
> these pages from a web server running within the client
> (mostly to provide a more natural and powerful way of
> interacting with the browser control).
> 
> For a first cut I imagine just starting a web server within
> the client and serving the pages from localhost:<someport>.
> 
> I have a couple questions for anyone with experience with
> this sort of architecture:
> 
>  * First, are there any existing open source libraries that
>    exemplify this approach?  I have a vague recollection that
>    TurboGears started out based on a project with this kind
>    of architecture, but I haven't been able to find anything
>    so far.
> 
>  * Second, are there any gotchas you would point out?  In
>    particular I'm wondering if even this localhost connection
>    will be a problem with many users' firewalls.
> 
> In case it matters, the application is being developed in python
> 2.5.x with wxPython 2.8.x, aimed first at a Windows platform,
> but intended to be portable to Linux and Mac ASAP.
> 
> Thanks for any pointers,
> David

If I understand you correctly, I did something like this recently.  I wanted to 
monitor a long running process via web browser.  I used twisted to create 
simplehttpserver and ran the long running process in another process. 
Periodically I would update information in a python dictionary that was visible 
to the httpserver to generate a proper HTML page by merging a template and the 
progress data upon a request from web browser.  Does this sound at all like what 
you are looking for?  No firewall issues and I even tunneled ports securely over 
ssh and it worked flawlessly.

-Larry
0
larry.bates (889)
12/17/2007 12:15:35 AM
I've done something reasonably similar using CherryPy as the
webserver.  The main application I wrote stored data in a sqlite3
database.  A separate thread then ran the CherryPy server process.
Each web browser call is mapped (by CherryPy) to a class method which
dealt with connecting to the sqlite3 database, collecting the
appropriate data and then generating the page.  You can have much
tighter integration between the webserver and the application if
required.  I found cherrytemplate to be a usable and lightweight HTML
page templating system that was appropriate for what I wanted but
there are lots of others.

I haven't gone down the full AJAX/DHTML line with CherryPy but from
what I've seen of it, it seems quite capable of delivering.  Neither
have I come across any issues with firewalls or proxy configurations -
I just set CherryPy to bind to 127.0.0.1 at a suitably high port
number and it's always worked so far.

  Matthew.
0
12/17/2007 11:04:22 AM
Reply: