[ANN] pyjamas 0.7 released

[Luke Kenneth Casson Leighton]

pyjamas - the stand-alone python-to-javascript compiler, and separate
GUI Widget Toolkit, has its 0.7 release, today. this has been much
delayed, in order to allow the community plenty of time between the
0.7pre2 release and the final release, to review and test all the
examples.

pyjamas allows developers to create applications that will run either
in any modern web browser (with no plugins required) or as a
stand-alone cross-platform desktop application (like PyQT4 or PyGTK2),
WITHOUT requiring modifications to the original python source. this
concept is singularly unique in the free software python world, but is
conceptually similar to Adobe AIR and Silverlight - without the
massive plugins required.

there has been significant improvements, features and libraries added
in between 0.6 and 0.7: please see the README in the distribution for
details. for fits and giggles, to show what's possible in only 400
lines of python, here is a game of asteroids, written by joe rumsey.
yes, it runs under pyjamas-desktop too.

http://pyjs.org/examples/asteroids/public/Space.html

For more information, see:

http://pyjs.org
http://pyjs.org/FAQ.html
http://pyjs.org/features.html

http://groups.google.com/group/pyjamas-dev

downloads:

http://pypi.python.org/pypi/Pyjamas
http://code.google.com/p/pyjamas
http://sf.net/projects/pyjamas

known major bugs: http://code.google.com/p/pyjamas/issues
#391 (google chrome beta)
#384 (text selection on opera 10.51)

contributions and investigations by community members to fix these and
other issues welcomed and encouraged.

 

[Alf P. Steinbach]

* Luke Kenneth Casson Leighton:

http://pyjs.org/examples/asteroids/public/Space.html

<result>
An error has been encountered in accessing this page.

1. Server: pyjs.org
2. URL path: /examples/asteroids/public/examples/asteroids/public/bootstrap.js
3. Error notes: NONE
4. Error type: 404
5. Request method: GET
6. Request query string: NONE
7. Time: 2010-04-25 19:55:16 UTC (1272225316)

Reporting this problem: The problem you have encountered is with a project web
site hosted by SourceForge.net. This issue should be reported to the
SourceForge.net-hosted project (not to SourceForge.net).

If this is a severe or recurring/persistent problem, please do one of the
following, and provide the error text (numbered 1 through 7, above):

1. Contact the project via their designated support resources.
2. Contact the project administrators of this project via email (see the
upper right-hand corner of the Project Summary page for their usernames) at
(e-mail address removed)

If you are a maintainer of this web content, please refer to the Site
Documentation regarding web services for further assistance.

NOTE: As of 2008-10-23 directory index display has been disabled by default.
This option may be re-enabled by the project by placing a file with the name
".htaccess" with this line:

Options +Indexes
</result>


Cheers & hth.,

- Alf

 

[Patrick Maupin]

pyjamas - the stand-alone python-to-javascript compiler, and separate
GUI Widget Toolkit, has its 0.7 release, today.  this has been much
delayed, in order to allow the community plenty of time between the
0.7pre2 release and the final release, to review and test all the
examples.

I know I'm a Luddite, but what I'd really love to see to go with this
is an easy way for the application, the browser, and the user to all
agree that this particular application can read and write arbitrary
files in a particular local directory.

A Python program you don't have to install, that executes really fast
on one of the newer JavaScript JIT engines, with its own purely local
data in files in a simple text format in a directory specified by the
user, instead of being all tangled up in a database with data from a
lot of different applications and buried deep in some multi-gigabyte
browser cache directory -- now that would be a platform worth
targeting.

 

[lkcl]

I know I'm a Luddite, but what I'd really love to see to go with this
is an easy way for the application, the browser, and the user to all
agree that this particular application can read and write arbitrary
files in a particular local directory.

you'll have to be a bit clearer about what you mean, because it's
probably perfectly possible with one of the pyjamas-desktop ports, but
that would leave the browsers "out in the cold", thus defeating the
purpose of pyjamas being cross-platform, cross-browser, cross-desktop
and cross-widget-set.

A Python program you don't have to install, that executes really fast
on one of the newer JavaScript JIT engines, with its own purely local
data in files in a simple text format in a directory specified by the
user,

the purpose of browsers is to isolate the application, restrict its
access to the rest of the desktop and OS, so that random applications
cannot go digging around on your private data.

many browsers _used_ to allow access to local files etc. but ...
yeah.

so i think you will be able to do what you describe _if_ you provide
a browser plugin which adds the required functionality.

google gears would be a good place to start (i've part-ported GWT
Gears to pyjamas - the SQL storage modules - to demonstrate what's
needed).

if however you completely ignore browsers from the equation, by
virtue of having to piss about writing c code, then yes, you can use
pyjamas-desktop. at that point, you have _full_ access to the entire
OS and system, because you're firing up the web browser engine as a
python application.

i've done something like this with pyjdwm - http://sf.net/projects/pyjdwm

l.

 

[Patrick Maupin]

 the purpose of browsers is to isolate the application, restrict its
access to the rest of the desktop and OS, so that random applications
cannot go digging around on your private data.

Well, I would agree that a "requirement" for the browser is to help
insure the user's safety, but would argue that the *purpose* is
somewhat more functional than that

 many browsers _used_ to allow access to local files etc. but ...
yeah.

I know. But, with most browsers, you can say "yes, I know I'm
downloading this Java program. I know it can have its way with my hard
drive. Trust me; I know what I'm doing here." Same thing with Adobe
or Microsoft stuff: silverlight, AIR, flash, PDFs. Basically, the
browser delegates ALL security control at that point. I just think it
would be nice if the browser could delegate a _little_ security
control to the user ("allow this JavaScript program to read/write
arbitrary files in this directory"; possibly with a total file size
limitation) for programs that can run inside the browser.

 so i think you will be able to do what you describe _if_ you provide
a browser plugin which adds the required functionality.

Agreed. Alternatively, of course, you could have code to let the user
"download" to a local file from the application's local storage area
for backup purposes, but that seems suboptimal.

 google gears would be a good place to start (i've part-ported GWT
Gears to pyjamas - the SQL storage modules - to demonstrate what's
needed).

I think even gears assumes a database under the browser's control; not
an arbitrary node in the filesystem. Also, I think gears is no longer
being developed. Of course, gears could be OK as a starting point,
but really what you are saying is that everybody wanting to use this
new file local storage feature would need an add-on. I agree that's
probable, but in that case it's only really worth doing if a lot of
projects would use it. I'm not sure if that will come to pass or not
-- it would need a lot of programmers to think that it was a great
thing.

OTOH, if a particular browser supported this functionality natively,
then it might be a competitive advantage if applications did develop
to support it.

 if however you completely ignore browsers from the equation, by
virtue of having to piss about writing c code, then yes, you can use
pyjamas-desktop.  at that point, you have _full_ access to the entire
OS and system, because you're firing up the web browser engine as a
python application.

That's understood (and a great thing). But if programmers could use
pyjamas in the browser without an extra download to get to all the
desktop features (which is how it *appears* to most users when they
use flash or something like that), that would be a great win.
Alternatively, a single small download of a broswer add-on package to
bring pyjamas desktop features into the browser (maybe even just for
mozilla for now) would be awesome, as well.

Regards,
Pat

 

[lkcl]

Well, I would agree that a "requirement" for the browser is to help
insure the user's safety, but would argue that the *purpose* is
somewhat more functional than that

we knowwwww

I know.  But, with most browsers, you can say "yes, I know I'm
downloading this Java program.

... which requires a java plugin

I know it can have its way with my hard
drive.  Trust me; I know what I'm doing here."  Same thing with Adobe
or Microsoft stuff:  silverlight,

plugin

AIR,

aka webkit (modified) plus plugins

flash,

plugin

PDFs.

often done as a plugin (e.g. mozplugger for firefox)

 Basically, the
browser delegates ALL security control at that point.  I just think it
would be nice if the browser could delegate a _little_ security
control to the user ("allow this JavaScript program to read/write
arbitrary files in this directory"; possibly with a total file size
limitation) for programs that can run inside the browser.

on IE, this is already possible - without needing plugins. "active
scripting". however, it requires security settings that people simply
aren't equipped to correctly modify.

Agreed.  Alternatively, of course, you could have code to let the user
"download" to a local file from the application's local storage area
for backup purposes, but that seems suboptimal.


I think even gears assumes a database under the browser's control; not
an arbitrary node in the filesystem.  Also, I think gears is no longer
being developed.  Of course, gears could be OK as a starting point,
but really what you are saying is that everybody wanting to use this
new file local storage feature would need an add-on.  I agree that's
probable, but in that case it's only really worth doing if a lot of
projects would use it.

preeeciselyyy. which is why nobody does it.

and, given that you can use AJAX (e.g. JSONRPC) to communicate with a
server-side component, installed on 127.0.0.1 and effectively do the
exact same thing, nobody bothers.

the JSONRPC stuff is pretty trivial (if annoying by the fact that
it's asynchronous function calls, client-side) - and there are half a
dozen server-side implementations. the ones we recommend people use
with pyjamas are actually damn good: decorators turn an "ordinary"
function into a JSONRPC service with a single import and a single line
of code (decorator) per function. that's _it_. the actual
implementation, aside from "apt-get install simplejson" is about
_thirty_ lines of code (incredibly) for joining up JSONRPC to django
or web2py etc. etc.

it's so small an amount of code that the django developers are
refusing to include it in the standard distribution, because it
doesn't look scarily complicated enough, doesn't make programming with
JSONRPC difficult enough for them, and generally makes life "too
easy". i love it when programmers get scared by code that appears to
be "too easy" and "not stressful enough to be acceptable", because
then they stay away from me, thank goodness.

but - yeah: JSONRPC's definitely your most sensible pragmatic
option. server-side you can then do absolutely anything. if you use
pyjs, you then have the advantage that the application will still work
as pure python under pyjd _even_ though it uses HTTPRequest, because i
made damn sure that the XmlHTTPRequest objects which you _expect_ to
use "javascript-only" _still_ work even under the three ports
(pywebkitgtk, xulrunner and MSHTML). (that was fun-and-games and
there's still massive repercussions with the fucking crack-heads from
the webkit team over the access to XmlHTTPRequest from glib/gobject...
just don't ask for details... )

That's understood (and a great thing).  But if programmers could usepyjamas in the browser without an extra download to get to all the
desktop features (which is how it *appears* to most users when they
use flash or something like that),

no - it's not going to happen: it's _required_ to install the flash
plugin.

that would be a great win.

yes. if you can "tolerate" the plugin download, firefox does
actually have python-in-its-entirety as a plugin (a whopping 10mb
one). it includes xpcom apparently so that you can not only do <
script language="python" /> ... but also you can access the full
browser DOM features just like you can from javascript. i haven't
investigated this yet because it's easier to do pyjd.

then there's also iron-python inside silverlight / moonlight.

then there's also... darn it, what's it called... someone made it
easy to do python and ruby ahhh yes appcelerator. they _claim_ you
only need a 150k download but actually you need the entire
silverlight / moonlight plugin _first_...

Alternatively, a single small download of a broswer add-on package to
bring pyjamas desktop features into the browser (maybe even just for
mozilla for now) would be awesome, as well.

on debian/testing: "apt-get install hulahop python-xpcom" - actually
you just do "apt-get install pyjamas-desktop" because hulahop, python-
xpcom are dependencies and xulrunner is a sub-dependency.

on win32: it's an additional 350k install: python "comtypes". that's
_it_ - that's all - and you're done: everything else is already there
(MSHTML.DLL is the key but you need the MSXML dll as well, but, duhh,
those come pre-installed with the OS, duhh)

otherwise, you'd need that whopping 10mb python-inside-a-plugin, and
i'd need to port pyjd to it. loovely. i look forward to receiving
sponsorship to do that (probably about 2 weeks work: it's not rocket
science, now that there's 4 pyjd ports).

l.

 

[Patrick Maupin]

 and, given that you can use AJAX (e.g. JSONRPC) to communicate with a
server-side component, installed on 127.0.0.1 and effectively do the
exact same thing, nobody bothers.

I suppose, but again, that pushes off the security thing. There are a
lot of obvious ways to make unintended security holes in a 127.0.0.1
application, so I'm sure there are also a lot of ways that would be
unobvious to this security non-expert. And, of course, the real
dealbreaker is, it still requires a separate install.

 no - it's not going to happen: it's _required_ to install the flash
plugin.

Yeah, but *everybody knows* you have to have the flash plugin. It's a
given. Even if you write an exciting new flash app, probably only
0.01% of your userbase will need to install flash; everybody else will
already have it installed.

 on debian/testing: "apt-get install hulahop python-xpcom" - actually
you just do "apt-get install pyjamas-desktop" because hulahop, python-
xpcom are dependencies and xulrunner is a sub-dependency.

 on win32: it's an additional 350k install: python "comtypes".  that's
_it_ - that's all - and you're done: everything else is already there
(MSHTML.DLL is the key but you need the MSXML dll as well, but, duhh,
those come pre-installed with the OS, duhh)

 otherwise, you'd need that whopping 10mb python-inside-a-plugin, and
i'd need to port pyjd to it. loovely.  i look forward to receiving
sponsorship to do that (probably about 2 weeks work: it's not rocket
science, now that there's 4 pyjd ports).

I really appreciate your thoughts and these suggestions. But if you
could extend "look, here's this awesome asteroids game, and you don't
have to install anything!" to "look, here's this <arbitrary business
app> and it stores all its data on your local machine, and you don't
have to install anything!" that would be effing awesome.

Next best would be the python-in-a-plugin. I think if someone steps
up to the plate and supports your development of that, it would make a
great delivery mechanism for programs.

Best regards,
Pat

 

[lkcl]

I suppose, but again, that pushes off the security thing.  There are a
lot of obvious ways to make unintended security holes in a 127.0.0.1
application,

not to an experienced web developer. by starting the browser at a
URL which can only used once, you can effectively do the same trick
that X-Server X-Auth "magic cookies" does.

so I'm sure there are also a lot of ways that would be
unobvious to this security non-expert.  And, of course, the real
dealbreaker is, it still requires a separate install.

not necessarily. luis pamirez created pygtkweb (a reimplementation
of gtk widgets, to be compiled to javascript, to run in a web browser)
and he created it as a stand-alone app that 1) fired off a web browser
2) ran a small cgi-bin-esque web service 3) served static (pre-
compiled) pages 4) served AJAX to the compiled app.

with pyjd, that "step 1" can be bypassed or more specifically step 1
and 2 can be combined into the _one_ python app (two threads /
processes); you effectively combine the "start the window with the
browser engine in it" step with the "start a mini web server" step.

so it can be done: it's just not "immediately obvious".

l.