Skip to main content
Welcome guest. | Register | Login | Post

What would you recommend one call the new XUL, Lighthttpd, SQLIte, PHP Rich Client Framework?

XSLP
0% (0 votes)
XPLS
0% (0 votes)
XULPHP
0% (0 votes)
SLXP
40% (2 votes)
Slick PHP
0% (0 votes)
XSPL
40% (2 votes)
RichPHP
0% (0 votes)
RPHP
0% (0 votes)
XUL-Rich
0% (0 votes)
Other
20% (1 vote)
Total votes: 5

Comments

New Rich Client Framework Poll

There is a new rich client framework that some of us have discovered that combines Mozilla XUL, Lighthttpd, SQLite, and PHP. This could be named various things. I wanted to call it to a vote.

OK I voted XSPL as it sounds like a rememberable acronym. Maybe RichPHP would be good as well since it's actually like a word and might be even more rememberable.

Btw, could someone explain in summary and in a newbies language what does that framework mean anyway? What is its purpose and how is it special?

Thanks Smiling

Okay, in newbie-ese:

If you want to build something with a GUI in Linux, you have the following somewhat mature and popular languages:

PHP
Perl
Python
Tcl
C

...and the following set of widget GUI component APIs to interact with:

GTK2
Tk
WxWidgets
Qt

The sad thing is, however, that no matter how you mix these, the GUI is not easy to interact with. Besides, the world has gone web on us. Wouldn't it be great to leverage what you know about the web in building standalone GUI applications on workstations?

That's where this new rich framework comes in. A rich client is a fuller client -- a standalone program that requires no server, and which usually has a GUI. It is also called a thick client or fat client. Your typical OpenOffice app is a rich client. Well, a new rich client framework is now possible thanks to something new in Firefox, when combined with an embeddable web server and database server. These components are: Firefox XUL, Lighthttpd, SQLite, and PHP.

The Firefox XUL script loads the "GUI", but what you really have is a little web browser. This then connects back to itself, not a remote server, to attach to a local web server hosted through Lighthttpd. Once there, this server can host the PHP language. The PHP language can then do what normal PHP can do. However, an embeddable database with a small disk and memory footprint is necessary. That's where SQLite comes in.

A gameplan that I have is to combine all of these into an SDK so that you could download the tar.gz, deb, rpm, cvs it, or apt it, and be off and running with the framework, ready to build your apps.

If the SDK were pre-built for you, then all you would have to do is make some very small changes to your XUL file, create your tables in SQLite, and then start editing the PHP pages to make your application.

Thanks, I think I understand now. That really sounds exciting!

I imagine that since I am beginning to first learn mostly web programming languages that I would welcome something like this to use my knowledge with to create real GUI apps, almost as if I was creating actual websites.

Sounds great!

Thanks

You might want to replace lighthttpd by something else, such as fnord, and instead of PHP you could use Perl or Python. It will be a different framework, but the same idea: local http, SQLite, one of the P-languages and XUL.

so my vote is LSPX - Local Sql/P*/Xul

I just realized not all scripting languages have names that start with 'P'. The special thing here is CGI.

LCSX - okay, that's just impossible to pronounce
RLC - Rich Local CGI... I like that one.

By the way, this seems an excellent solution for small companies if you add user management to your framework. One could simply attach a computer to the local ethernet and let it serve an XUL desktop with a few applications to the whole office.

Even better, you could sell small computers with this framework preinstalled!

"tbuitenh" wrote:

You might want to replace lighthttpd by something else, such as fnord, and instead of PHP you could use Perl or Python. It will be a different framework, but the same idea: local http, SQLite, one of the P-languages and XUL.

so my vote is LSPX - Local Sql/P*/Xul

Is fnord dead? How long ago was it last updated? There are more backers behind Lighthttpd and SQLite, I'm afraid. Those are winning a popularity contest.

Actually, if multiple scripting languages and now possibly even multiple databases can be used for this same concept, maybe it shouldn't be an acronym consisted of their names at all. Maybe you should think of a name you would give to this concept, something that signifies it's most important likely purpose or what makes it different from other frameworks and then acronymize that.

Alternatively you could just think of a cool name to give it, anything, something funny and catchy that might have some remote relation to what this framework is.

Am I right to assume that SQLite is the database of choice for this framework? It has the popularity, the right kind of license, consumes little memory, requires no running "service", uses little disk space, and can handle an extremely large table size (although only a moderate row size). MySQL and PostgreSQL are great, but they're for a more robust, client/server platform than this.

"tbuitenh" wrote:

By the way, this seems an excellent solution for small companies if you add user management to your framework. One could simply attach a computer to the local ethernet and let it serve an XUL desktop with a few applications to the whole office.

If I'm going to do that, I might as well make a full-blown web app and serve that up.

However, perhaps you would be interested in seeing these samples, which is something else, separate from what I'm interested in making into a full-blown framework:

http://www.georgenava.com/applauncher.php

Well, SQLite sounds good for standardizing this framework on..

But then we're still left with a choice of scripting languages besides php and others that start with P.

"supermike" wrote:

If I'm going to do that, I might as well make a full-blown web app and serve that up.

You're already doing that, only you're making the server as lightweight as possible, which is why I'm talking about a small single office company instead of big company or open web. It would fit nicely in the same kind of place that uses a network attached disk and a shared single ADSL connection to the net.

If you're not going to take advantage of the http server bit you have, I think you're better off not using it at all for security reasons. I mean what advantage does it have over, say, glade+python+SQLite? If there's no good reason for having that http server, it's useless bloat.

Comment viewing options