Visions in Pyjamas: The e-Merging of unified app development

Posted 18 Feb 2007 at 17:00 UTC (updated 25 Feb 2007 at 08:42 UTC) by lkcl Share This

first came "The Desktop". then came "The Web". Somewhere along the way, Shit Happened. mostly in the form of a cancer on society called 'capitalism' that allowed a two-bit company, that couldn't (by law!) care one bit about anything but profit, to take over nearly every desktop computer in the world. Everybody but us free software people is living in a nightmare monoculture world, devoid of innovation, for nearly fifteen going on twenty years.

With the advent and maturing of free software, the excitement and innovation is coming back, along with the freedom and encouragement and enjoyment of expression of creativity. And pyjamas and the original Google Web Kit are classic examples that have the potential to accelerate that process even more: making the web browser into just a desktop window, or even bypassing the web server and web browser altogether. all without having to know anything about HTML or the web, at all.

This article shows why that is, and outlines how and what needs to be done to make it happen.

What's the fuss about, and what's pyjamas, and what the hell's python?

How can i put this best... pyjamas is possibly the most significant free software applications development tool that i've ever encountered. On my radar, which is pretty sensitive to 'Significant, Archaic, Esoteric, Obscure and/or Elegant and/or Beautiful Technology', it's like glowing and overloading circuits.

Pyjamas (and GWT) is, basically, a compiler tool. You take python (or JAVA) as the input, and you compile it, and out pops pure HTML and Javascript. The neat thing is that if you want to access data, you do so from your application using a JSON plugin (or any other plugin that you care to create, to be honest). And the JSON library is, again, implemented in Javascript (actually, AJAX).

To give you an example: i struggled to do my old site for ten days trying to research all of the necessary techniques and skills that are required to place web content in the layout that i wanted. What i wanted was this: seven blocks in three rows (2-3-2), everything in the middle of the screen, and if you resize your browser, it reconfigures so that you don't need to go onto the horizontal scrollbar, as i consider that to be extremely lame. The new site looks exactly the same: it took me about 40 minutes to convert to pyjamas, most of which was spent going 'errr' as i cut/paste bits of the kitchen sink example and the warm words of my old site into one joyous beautiful over-colourful site. and hooray! now i can do those popups that i wanted to do on each colour block, without having that sinking feeling!

python, as you know, is one of the most powerful, flexible, compact, elegant programming languages ever designed. there are more elegant languages; there are more powerful ones; there are more flexible ones, but no programming language that i know of has all those attributes, and a lot more besides.

modula-3 for example - but who the hell uses modula-3.

sqlobject and the tantalising prospect of seamless desktop / web

some time in 2002/2003, i encountered SQLobject, one of the first python free software object-orientated 'meta-sql' building blocks, which pissed all over my 'DPyDB' code - a 2nd generation relational database sql-building toolkit. ian bicking's SQLobject, a 3rd generation object-orientated sql-building toolkit, has morphed into the most powerful database tool i know - but, it must use meta-classes which aren't supported in python 2.1, which is a pity.

oh - and by the way: those guys who are doing sqlalchemy are bloody idiots, because they didn't bother to check whether ian had written sqlobject. and they're basically reimplementing sqlobject, and doing a piss-poor job of it. they've no idea why ian added in object cacheing and transaction rollbacks, for example, stupid idiots. all they really had to do was look at putting an Object-Orientated syntax on top of SQLbuilder (utilising python syntax, the key 'feature' of sqlalchemy).

anyway. ian was talking with andy dustman, the author of python-mysql, and andy was developing a classes system which had two modes:

1) output HTML

2) run on the desktop

basically, from the same code, which would be from building blocks that matched nearly 100% in classes like Table, Input, Form, all of the attributes of HTML, you could move the HTML library out the way, and the web server, and the web browser, substitute a different library, and end up with a desktop application (!)

the code even generated CSS stylesheets (remember - no AJAX at the time, at least, not by anyone but the most esoteric and brilliant of web programmers: it generated straight HTML with CSS) in 'html' mode.

and i never found out whether it was a TCL/TK or a QT3 or whatever thing in 'desktop' mode.

now, he had an agreement with the people he was working for that within one year he would be able to release all this code as free software.

within six months, the company was bought up. and the new owners refused to honour the agreement.

so, rather than lose the contract and the possibility of work over a bun-fight, he backed down.

the code never made it out of the clutches of those stupid assholes.

good ideas come around again... five years later in this case...

however - the idea has stuck with me ever since: have an application that runs on the desktop and can run as a web application without having to friggin rewrite and redesign the bloody thing.

that's just stupid.

imagine my delight when i discovered gwt last year. a tool that auto-generates html! and does AJAX! and would therefore take away all the pain because the expertise is all 'hidden' yet focussed on and refined by lots of applications writers debugging it on many many different browsers.

and ... very quickly i was bitterly disappointed because it uses java - and, i'm sorry to have to say this, but java really is shit. people who love it - it's great. but if you know lots of programming languages, you'll know that it's too close to c++ to be worthwhile bothering with (you might as well use c++), and as a compiled language, it's too far away from object-orientated scripting languages to be worthwhile bothering with (you might as well use python, or *shudder* perl or ruby or even lisp would be better). anyway - end of rant, i think...

so. when i encountered pyjamas, i went NUTS. because, i made an attempt, last year, to develop a similar framework. and, i got about 25% to 30% of the way there (and then the project went all weird or more specifically the business people i was working with went paranoid due to lack of experience and i stopped).

the framework that i developed, written as a mod_python site, had a couple of requirements: 1) do AJAX 2) do straight < noscript > HTML and i was trying to design it so that i could do a 'desktop' version later - but that was eating a bit too much of my time.

you can maybe start to see why i'm so excited about pyjamas...

anyway.

the 'specification' files - the python code that you pass to the pyjamas compiler - is actually very similar to code for python-qt, python-tk etc. (and even superkaramba, or KDE 4's in-development 'plasma' !)

it really would not be difficult to actually put in a framework where that code gets executed and you end up with a desktop application.

the only bit that appears to be hard is the 'event' loop - the bit where you normally have to access a 'web' page which returns you JSON data.

and, that's where my work with the mod_python-based site i developed last year comes in.

the holy grail of supporting all browsers (and desktops!)

the basic principle of mod_python - in fact any web site framework - is that you specify a web page by name (which represents a function) and you give it a query string (which represents the function parameters). it's just that in mod_python, and zope, and in fact in all of the decent web development environments, the relationship between the HTTP POST or GET and the function which generates the HTML response is that much clearer. (this is one of the fundamental reasons why i despise PHP, PSP and other web scripting languages so much, because it's so easy to be ignorant of all of the things that make good, stable and maintainable web sites - but i digress...)

what i did was, instead of specifying the web page as a string (but, to be honest, you could still leave it as a string and parse it like you would in a cgi script) i specified it as a dictionary of lists (before being passed through cgi.urlargs basically) plus a 'module' name - the name of a function which was executed by mod_python.

the HTML page (or, more often as not, the HTML fragment as returned by AJAX) is returned as a parameter, which would then be substituted as text back into the function ... you can see where this is going, right?

basically, in the 'AJAX' mode (the point which is equivalent to where in pyjamas you go off and do JSON things) you construct a div tag with a unique id and match it with a small amount of javascript which, when executed, does an AJAX call (this is a standard AJAX trick, by the way - i'm describing nothing new here). when this HTML fragment is returned from mod_python to the web browser, it instructs the user's browser to do an AJAX call (with the parameters to the web page that i mentioned at the beginning of the paragraph above!) which ends up substituting that div tag with the HTML that comes back from the new web page (and there's a really simple example dlink that i found on someone's site, linked further down on this page, that demonstrates this principle. use babelfish to translate the japanese!).

in this way, the web page is constructed layer by layer by repeated calls to the web server, and the nice thing is that you can use this to avoid duplicating code or duplicating entire sections of your web site, server-side, because each 'function' has its own screen area where the HTML... you get the idea :)

effectively, it modularises a web page design, allowing you to reuse and combine components, even hierarchically. and because you can pass in parameters (and cookies - the equivalent of global variables), you can get those components to dynamically and completely reconfigure themselves. for example, on the left hand side you can have menu options which tell the centre portion to 'redraw' to display email (menu option 1) or instant messages (menu option 2) etc.

and in the 'plain HTML' mode, what happens in the mod_python code is that that AJAX call i mentioned is cut out completely from the loop, and instead my code calls the function DIRECTLY, and actually returns the HTML code fragment DIRECTLY!!!

so you end up hierarchically constructing the same web page, to be returned only once as a complete page, that, in the 'AJAX' mode is constructed by repeated calls back-and-forth by the user's web browser to exactly the same functions!!! as a result, the page looks EXACTLY the same in noscript mode as it does if you have a javascript-capable web browser. FROM THE SAME WEB SITE. WRITTEN ONLY ONCE! :)

these two techniques are the two missing techniques from the GWT and the Pyjamas code of the three (mainly three) ways in which you can do web programming:

1) pure AJAX. everything's on the user's browser, already. the only thing that's loaded is data. other than loading the HTML and the javascript, the web server is never contacted again, other than via JSON, to get data which the html+javascript 'application' needs.

2) hybrid AJAX. HTML is loaded in tiny fragments, and substituted into div tags through repeated calls. it requires that you do a lot of frickin about to make the HTML executable if it contains < script > sections with further AJAX in it. but - after a lot of pissing about and a lot of research, i found some hack techniques. oh, and also some techniques for making CSS stylesheets actually work, too, when they are downloaded via AJAX.

3) plain HTML. no AJAX. everything is generated server-side. we know aalllll about this one, and have done for years, so i won't go into it in detail, other than to say this: this is the one where you can support people who have text-only browsers, and also it's the one where you can solve the problem of google ads not being able to ad-walk your site properly because it's an AJAX application! but - remember, that still doesn't help you because the stupid terms and conditions of the stupid google ad system only allow you to 'cut and paste' a stupid bit of javascript, and the techniques described in here go WAY beyond the impracticality of manually cutting-and-pasting stupid bits of javascript into stupid unmaintainable and effectively useless static web pages. i'll leave it at that - because it's beyond the scope of this article.

4) plain HTML using frames or iframes to construct the hierarchy of the site. this is quite neat, as it is a variation of the hybrid AJAX with all the advantages of 2) with the added advantage of full support for non-javascript-capable web browsers from 3).

the hybrid approach 2) is a nice one, because it's the best of both worlds. the user's browser does minimal work (only doing multiple AJAX calls), and the server does minimal work (only serving up bits of page that need changing - not the whole damn lot).

the hybrid approach: it's FAST! i mean - REALLY fast!

there's no significant delay downloading a larrrrrge initial html + javascript application, and, also, quite often, the javascript application is so big and unwieldy that it makes the user's entire computer run like a dog.

gmail is a good example of this.

my 1.2ghz 512mb TravelMate C110 runs so slowly and so unreliably with firefox 1.5 under linux that, whenever i run gmail, i have one chance to skip to the 'plain html' mode, whereupon everything not only suddenly runs 5 times faster, but also it actually... well... works.

if i even attempt to use the gmail application, it falls over in a heap.

anyway - that's another story, plus my setup is very weird, and always has been, and i've found bugs and problems that nobody else seems to be able to replicate... *sigh*....

where was i...

GWT and pyjamas are examples of 1)

my mod_python web framework is a duality-mode thing which does both 2) and 3) and i considered doing 4) and wished i had time to do 5)

andy dustman's code was a duality-mode thing which did 3) and 5) - 5) being a desktop application.

the bottom line is: with very little extra coding effort, it's possible to make pyjamas cover ALL FIVE CASES. thereby making it a truly unified application development environment.

oh yes: one other thing...

the refresh 'Thing' of ajax applications.

the most annoying thing about AJAX web applications is that the history of 'where you were' when you do a 'page refresh' is completely forgotten.

i fixed that.

basically what i did was: you remember where that function call returns some AJAX to get the browser to come back and reload that HTML fragment? well, part of my mod_python framework's job is to record that hierarchical information in a cookie! the only thing you have to watch is: in a big site, that would be a big damn cookie.

also, what i found was that when clicking through the site rapidly, sometimes the same area would get overwritten (think of menu options on the left hand side updating the main screen area by setting one of the 'parameters' of the web function to say 'the purpose of this area is now to display email. return HTML containing email!')

but, because it's a cookie, and because when you click on that area it's AJAX, what happens is that two asynchronous browser threads get set up, and the slower one will 'win'. this gets very odd, very quickly - but i am not entirely sure what to do about it...

but, basically: that cookie contains all of the information that is required to reconstruct the web page. the alternative approach would be to have a session cookie which refers to some information stored in a database - but that is left as an exercise to the reader. the neat thing is that this complements the GWT 'history cache' concept. remember: an AJAX application breaks nastily when you do 'Back' button, and the GWT 'cache' stores a copy of the DOM model of the web page, and captures the forward/back button and 'replays' the requested 'cached' content.

but - that still doesn't help you if you hit 'refresh', and that's what my little trick of storing the hierarchy of the last displayed page-fragments in a cookie solves.

the vision of the holy grail of applications environment

so: concept-for-concept, we have a near perfect match between recognised and well-known desktop development environments and their web equivalents, thanks to google web kit and pyjamas, as seen through my rosy farscape-tinted glasses. for completeness, let's enumerate them here:

1) global variables. your application needs global variables or at least per-session information: in web-speak, these are cookies.

2) event-loop notifications and callbacks. every desktop environment has these: onResize, onShow etc. GWT and pyjamas makes these easy to use, as if you were developing a desktop application.

3) widgets. plain widgets and extendible widgets! in the GWT examples, there is even a 2D drawing package, which spews forth stuff onto a 'canvas'! it's fantastic!

4) separating the look-and-feel from the data-crunching hard work. pyjamas and GWT, due to limitations, of the framework and the fact that it comes from a web background, forces the applications writer to separate out the layout portion from the back-end which supplies the data. this can only be a good thing to encourage, and there is enough scope to put in a stand-alone JSON (python-simplejson package) threaded server which can seamlessly be accessed by the 'desktop version' of the JSON proxy.

5) providing other communications methods / plugins to fetch data. your alternative to JSON only need to implement two callbacks (remember, this is client/server Remote Procedure Call architecture, not plain vanilla desktop architecture). one: 'did it succeed, gimme all the data' and two: 'it failed miserably, let the poor buggers know'.

the wishlist, always the wishlist...

one final thing: i have a wishlist item for pyjamas (and if it makes it into GWT, then that'd be great, too)

treeview menus. you need a dynamic treeview menu widget. why? because some databases contain many thousands of entries, and are four to five levels of hierarchy deep, and you sure as hell ain't gonna load that into javascript in one go, which is what you get in pyjamas and GWT. yes it's fast to display, but there's no way it can cope with 2,500 database entries - the javascript would take FOREVER to load up.

now, i've had to do this already (in straight python / ajax) and so i know what's needed, and it doesn't take long to write, and it's only about... *thinks*... 200 lines of python, and probably a lot less AJAX than i'm using because what i'm using is old-school manual AJAX crud.

the original dynamic-treeview-menu example that i used was this:

http://jsgt.org/ajax/ref/test/dlink/test1.htm

and i absolutely love that example because it's so trivial. and it was what i based the 'hybrid' stuff on that i mentioned above.

in the treeview case, you need:

  • a get-me-children-by-parent function (to get the next level)
  • a count-my-children function (to tell you when to stop recursing!)
  • a get-my-details-by-id function (to obtain the item to display)
  • a 'display-my-details' function (to actually display the item)

and a few others (minor but very important things!) which i forget off the top of my head. you need to pass in a plus-or-minus option. just like you can see in the dlink example (ignore all the japanese crud)

the desktop becomes the web, or vice-versa? who cares, it's all the same!

the future for pyjamas and GWT as i envisage it provides enough for developers to write extremely powerful applications ... like... you could write a desktop app for browsing filesystems (any number of files / subdirectories, any levels deep...) that then oh look, the files all got moved onto the backup server, and oh look, there's a web application that looks exactly like my desktop app and .... err.... where does browser and where does deskop actually begin and end, and what, really, is the damn difference any more???

and... remind me again: why the bloody hell am i running a 200 watt computer with a 3Ghz P4 that costs me $150 per year at domestic rates and in some countries over fives times that in business rates, in power consumption alone??

i'll leave you with something that'll fry your brains for good. with pyjamas, and KDE 4's plasma, there's the tantalising possibility to turn the entire thing on its head:

remove qt3 and put in a drop-in replacement that communicates with a web browser, to run a KDE desktop or any other qt application on a web browser - in AJAX and HTML!!!

now that's gotta flip people out and make steve ballmer turn in his grave oh damn he's not dead yet, somebody gimme a gun and get me diplomatic immunity, for all our sake's.

sakes., posted 18 Feb 2007 at 20:16 UTC by ncm » (Master)

I'm not sure I understood much of that. Is this technique fundamentally separable from Python? Python is great for one-off scripts, but generating pages on a heavily loaded server with a language that uses 1000 times as many cycles as it needs to is arguably immoral.

absolutely., posted 18 Feb 2007 at 22:23 UTC by lkcl » (Master)

sorry, ncm :)

yeh: pyjamas, and the google-web-kit, are _compilers_. you don't actually end up executing any of the code _on the server_ - at all. it's all javascript and html (approach number 1).

and that means that it's AJAX that communicates with the server - and the server responds, as long as it's in JSON format (see json.org for the spec, it's real simple) then the webkit-auto-generated html+javascript doesn't _care_.

for example, i like python-simplejson - but you could equally well use a php json implementation (god help you) or the ruby one or - whatever.

and i hate to have to be the one that tells you this, but there do exist million-line-python projects (mostly commercial). also, python's speed varies between 99% of c and 1% of c, depending on which bits you use.

for example, if all of your functions take dictionaries (variably-named arguments - like varargs in c, only not just a _list_ of varargs but also an optional _named_ list of varargs) then you get absolutely hammered, obviously.

and, mod_python pages can be in amongst the top fastest web sites around. i've seen statistics showing mod_python serving 600 pages per second and static web pages being 650 (!) zope i think came in at around 300 pages per second.

p.s., posted 18 Feb 2007 at 22:28 UTC by lkcl » (Master)

it's difficult for me to express how excited and elated i am about pyjamas. it's ... it's... programming is an art form (yes, i'm going to do an article about that, some time :) ) and this is one of those _really_ exciting breakthroughs when you know that this reallly cool bit of code can be morphed into something that opens up so many more possibilities.

Generated?, posted 19 Feb 2007 at 00:50 UTC by ncm » (Master)

So, Python's role is in generating the web site itself, not in generating the server's responses? And, the intelligence in the web server might be limited to sending files (some containing generated javascript) by name and, perhaps, in validating and performing database operations?

yes - that's it., posted 19 Feb 2007 at 01:43 UTC by lkcl » (Master)

python is used purely as a compiler tool, to turn a subset-of-python functionality into javascript.

if you don't need any data, and just need static web pages, then you don't even need even the database operations.

and if you _did_ need to return some data, then yes. a JSON-aware service performs the validation (in case someone tries to attack it). the JSON-aware service is what calls the functions to the database and then converts the database queries into JSON responses.

it's a really sophisticated setup, made extremely simple, requiring only a few lines of code.

and unlike ruby on rails, you're _not_ restricted to a particular set of rules where if you want to go outside of the framework you need hundreds of lines of code to do it.

Exciting, posted 19 Feb 2007 at 03:05 UTC by ncm » (Master)

OK, now I understand your excitement. This does look significant.

It might be revolutionary if writers of javascript (or whatever gets translated to javascript) could be counted on not to code infinite loops.

Interesting..., posted 19 Feb 2007 at 10:12 UTC by salmoni » (Master)

I've just checked out the Pyjamas website and the code examples they have. Although I'm not qualified to comment on it as a web development tool, this looks like it could be a fun thing to work with! Thanks for the heads-up lkcl

fun!, posted 19 Feb 2007 at 17:25 UTC by lkcl » (Master)

ok - the problem is: i got carried away with writing up the material. it's so exciting that i'm overusing emphasis. ho hum. major rewrite needed. time to talk to steven to see if that article edit thing needs adding - or perhaps...

can i ask people if they could help in rewriting this article into something a little more sane?

:)

code examples, posted 19 Feb 2007 at 17:37 UTC by lkcl » (Master)

salmoni: the code examples are from the google web kit - just ported straight over.

some kind person then contributed the 'canvas' examples, having ported _those_ from java to python.

which is nice.

the only bug i've spotted is a weird one - it's not exactly a bug. java derived class initialisation is 'automatic' whereas in python you have to do it explicitly (BaseClass.__init__(self, ...).

and the semantics that have been ported over to pyjamas are those of _java_ ...

anyway.

salmoni: trust me on this one. good web development requires a level of expertise well beyond most normal people's time, ability and _especially_ well beyond the amount of money that customers are prepared to pay.

"it's the internet! it should just damn well work! fire that sucker who's charging a fortune and get your kid brother in to do the job for free!"

i know it sounds funny, but as anyone who's tried to quote for doing web sites, this is extremely common practice - to be competing against the teenager who can use DweamWeaver or Micwosoft Fwont Page, simply because the client cannot comprehend that anything beyond (or even anything that _is_!) a static web page costs a hell of a lot of time and therefore money to do _correctly_.

and it's the "correctly" that's the killer.

consequently you have cowboys and rip-off merchants charging $EUR 2,000 to do a flash or java web site because they learned real quick that it avoids all of the stupid problems that you get with HTML/Javascript, and they also learned real quick that they can charge a lot of money for doing very little work because it's a seller's market.

so the sooner that that f4l.sf.net (flash 4 linux) project as well as pyjamas and GWT take off, the better.

what about Xaraya?, posted 19 Feb 2007 at 20:01 UTC by badvogato » (Master)

what about Xaraya ? Has it been on anyone's radar before?

I believe it is geared towards OO PHP

content management systems v applications tool., posted 19 Feb 2007 at 21:35 UTC by lkcl » (Master)

badvo - thank you for mentioning xaraya.

GWK and pyjamas are actually _applications_ toolkits: they turn the web into just 'another application window'.

xaraya is written in php which, to me, is a bad sign, right from the start. preliminary analysis of their site - specifically the tour - leads me to believe that it provides you with 'high-level' components, like 'a diary', 'a document manager', 'a user manager' which are separated from the 'templates' which is the way that information, irrespective of what it is, is displayed on-screen.

so you can 'customise' the look-and-feel of 'a user manager'.

there probably _is_ a set of widgets, underneath, but they're not promoted prominently as being part of the 'benefit' of using xaraya.

GWT and pyjamas are solely and exclusively an 'applications' framework. generic. bog-standard. nothing-actually-really-to-do-with-web-at-all framework.

GWT and pyjamas are actually more like a distributed applications framework, or a client/server architecture. they have more in common with DCE/RPC and other RPC systems, due to the recommended use of JSON, than they do with 'web' applications.

which is _well_ cool (and is the primary reason why i found it difficult to keep calm when writing the article).

the thing that primarily makes this possible is that the GWT has effectively abandoned - transcended - HTML almost entirely, and gone 'direct' to manipulating the DOM model of the browser, using Javascript.

it's what i wanted to do (i mention in my diary about 6 months back how frustrating it was to design my current lkcl.net html site design, by hand) and i'm so horrendously relieved that someone's done it. but more than that, i'm absolutely _delighted_ that it's been done in python.

advocacy, posted 20 Feb 2007 at 16:46 UTC by lkcl » (Master)

btw - regarding my comments on xaraya being in php: i unreservedly apologise for letting my opinion of php cloud my judgement. xaraya may _well_ be an excellent object-orientated toolkit, and if anyone knows anything about it, please do say so!

in the meantime, please _do_ ignore my bias - especially if you are stupid enough to like php.

questions, posted 21 Feb 2007 at 20:13 UTC by lkcl » (Master)

i got an email from someone without an account here on advogato, who had some questions. they're good questions, so i post them here. i apologise to people for not having written a particularly good article: i was flying pie-in-the-sky the day i wrote it... :) 




 > So, does this mean that you have to deploy Apache + mod_python along 
> with your desktop app?


  no - the output from the compiler tool, which happens to be written in 
 python, is pure html and javascript.


  it has _nothing_ to do with web "servers" whatsoever.  it is the 
 _front_ end - the "client" in "client-server" architecture.


  you can put in _any_ "server" - even in visual basic as a CGI script if
 you like (as long as it reads XML and spews out JSON as an HTTP response )


  this is what people seem to have the most difficult with.


  it's using HTTP as a transport for an RPC mechanism, (remote procedure 
 call) where the 'request' procedure parameters are encoded in XML,
 and the 'response' procedure parameters are encoded in JSON.


  but you could if you wanted to replace this entirely with something
 else (for the desktop version)  dce/rpc (freedce) for example.  your
 own stupidly-demented-time-wasting-but-essential-learning-curve
 home-grown RPC system.



 > You know, the one you wrote for your Granny?


  the ones in heaven? :)


 > Do you think that some sort embedded web-server could be cobbled 
> together that could invisibly take the place of Apache etc...


  dude - you could run it in lisp on a PDP-11 if you really wanted to, as
 long as it received the JSON xml query and responded with JSON
 (javascript Object notation) data.


 > How about Karrigel plus something for JSON?


  yep.  whatever the hell you like - literally!


  python-simplejson.


  look it up (install it under debian: apt-get install python-simplejson)

replies to questions, posted 24 Feb 2007 at 12:36 UTC by lkcl » (Master)


Ok thanks.  I think I understand this now and I am going to try to build
some Python desktop apps that use the browser as an interface driven by
Pyjamas and/or GWT.


 This is very exiting:  the prospect of being able to code once for an
app that is portable across hardware, OSes and web or desktop.  If this
works out then why isn't everybody doing this?

he he. web operating systems been done with youos.com and several other companies. but not 'combined' desktop.

the answer to your question is quite simple: when i said that microsoft's domination of the desktop has set computing back by nearly 20 years i REALLY MEANT IT. and i'm not the first nor the last to be pointing this out.

but don't worry: the insatiable drive for profits has pushed computing so far ahead that a simple AMD geode processor running at the same clock speed as computers used to run, ten years ago, can piss all over a 3ghz dual-core intel, for 'everyday' tasks such as telephone, television, video and internet.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page