On 9/17/09 10:49 AM, Pavel Krivanek wrote:

> The reason I write you is to inform you that there are such activities
> and I'm pretty sure that some other remote XUL frameworks for the
> other programming languages may appear. I would like to ask you if
> there is some possibility that remote XUL will find official support
> in XULRunner. That means that there will be some proper well described
> way how local XULRunner application will be able to communicate with
> remote HTTP server without security restrictions. In other words, we
> need some way how to define in the application configuration trusted
> remote source.


No. The programming model where you give a remote website complete
access to
your local computer is really crazy, especially if you're not using
HTTPS
and being very cautious about certificate continuity... any MITM
attack can
own your computer! If you want an app with complete control, it should
be
installed locally. It is possible to grant specific privileges to
remote web
apps, and we're working on making that more extensible as part of the
JetPack project.

By the way, this really doesn't have anything to do with XUL: you
could
write your local app in HTML, or your remote app in XUL, and it has
the same
domain security applied to it regardless of the language.

If you want an editor, use standard HTML editor techniques such as
contentEditable or various libraries (see FCKeditor or TinyMCE).

Also, private email is probably not the best way to discuss this sort
of
question: use the mozilla.dev.extensions newsgroup.

ORIGINAL MESSAGE:
=================

Hi Benjamin,

I would like to discuss with you some aspects and issues of less
common XULRunner usage - as a remote client for the HTTP server.

There are three ways how to run remote XUL:
- open it directly in Firefox
- use XULRunner
- use Firefox with .ini file in the -app argument.

The application configurations contain something like this:

pref("toolkit.defaultChromeURI",
"http://localhost:8888/seaside/SeasideXUL%20Periodic%20Table/");

However XUL generated this way has a lot of security related
limitations. Very limiting is non-operational Editor element, you
cannot open next windows etc. Mozilla offers three ways how to obtain
security rights however no-one is working in practice.

- The first way is to use signed scripts and other source files placed
in a jar archive. So you need a certificate and you cannot create
dynamical user interface. Moreover this way should be disabled in
future.
- The second way is to create configuration files of the application
and register them to chrome. This would be useful but only local files
can be registered (file:///).
- The third and recommended way is to create own extension that
communicates with the remote server. Useless for my goals.

I found the next way but I cannot get rid of the feeling that it is
only an ugly hack and it may stop work in the next versions and I may
only hope that if this will happen, there will be some useful
alternative to it. Here it is:

In the file chrome.mainfest you write an anchor to local files and you
create an overlay that points to the server. For example

content myapp file:content/
overlay chrome://myapp/content/main.xul http://localhost:8888/seaside/SeasideXUL

As the next step you create in local XUL files a file main.xul that
creates the main window without any content - it only defines a title
and size of the window. Finally you create this file as the entering
point for the application in prefs.js

pref("toolkit.defaultChromeURI", "chrome://myapp/content/main.xul");

Sample code of such application configuration is here:
http://seasidexul.googlecode.com/files/launcher.zip

I would like to share with you the motivation for all of this. It is
very elegant solution to have the application logic in form of the
HTTP server where a client connects to the server with a browser that
doesn't show web page but it shows regular native user interface. It
is very handy for intranet applications and all you have to do as the
server is to generate some XML code.

In 2008 I focused on generation of the XUL code from Seaside
(www.seaside.st) for Smalltalk and solve this way the never ending
question of native platform independent Smalltalk GUI with the
standard Look&Feel. Seaside is very sophisticated continuation and
component based web framework. I don't know if you are familiar with
Smalltalk so I will not go in detail. Here's one example how to create
a button with callback function that will get user information from a
login form and then process it in some next component.

xul button
label: 'login';
onCommand: (xul ajax callback: [
| user |
user := self call: LoginComponent new.
self call: (UserInfoComponent new user: user) ]).

Continuations enable to stop executed method anywhere and save call
stack for future restoring. That is very useful feature for HTTP
processing.

As the result I created the project
http://code.google.com/p/seasidexul/. The use of remote dynamic XUL
enables to generate whole Smalltalk IDE so it shows that this way is
viable. However we still have to hope that nothing will break in
Mozilla products.

The reason I write you is to inform you that there are such activities
and I'm pretty sure that some other remote XUL frameworks for the
other programming languages may appear. I would like to ask you if
there is some possibility that remote XUL will find official support
in XULRunner. That means that there will be some proper well described
way how local XULRunner application will be able to communicate with
remote HTTP server without security restrictions. In other words, we
need some way how to define in the application configuration trusted
remote source.

During the development of the SeasideXUL I had to fight some other
minor issues (mainly different behavior in different versions and
platforms) but the most painful is this one of security restrictions
because a lot of basic operations must be solved with very ugly hacks.
I would like to continue after a year pause with SeasideXUL
development but this worries me.

Yours sincerely
-- Pavel Krivanek