pyjamas 0.7 released

[lkcl]

On Apr 26, 6:52 pm, Patrick Maupin <pmau... at gmail.com> wrote:
> On Apr 26, 8:44 am, lkcl <luke.leigh... at googlemail.com> wrote:
>
> >  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 :-)

 we knowwwww :)

> >  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.

 ... 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.


> >  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 topyjamas- 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.

 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... )


> >  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 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.