Re:Using PHP on a professional site
on
Professional PHP4
·
· Score: 2
MVC is just an object-oriented design concept. There's no reason you can't do it with PHP. And, if you want a "middle tier" for PHP (persistent objects/connections, brokering, etc...), check out http://www.vl-srm.net/
I will have to agree that Cordwainer Smith is one of the few sci-fi writers I have read who's writing itself I would consider "riveting".
The science itself wasn't very strong, but the sheer imagination he poured into hist stories was incredible. And often hilarious. What other sci-fi writer would have thought of having of oneself freeze-dried, chopped up and shipped to earth to be "reconstituted" at the other end, as a means of escaping a manhunt?
Although a lot of his scientific ideas are odd, even macabre, the books aren't really about the science, but about characters, personalities, and some very intriguing psychological, philosophical, and political ideas. In that sense, his writing reminds me of one other forgotten sci-fi writer: Jack Vance (http://www.vanceintegral.com/)
By the way, Cordwainer Smith's real name was Paul Linebarger, and part of the reason he didn't write that many sci-fi books is that he actually had a very interesting life of his own (http://www.catch22.com/SF/ARB/SFS/Smith,Cordwaine r.php3).
among other things, he was the writer of the non-fiction "Psychological Warfare", which is apparently considered an a definitive work in that area. It is studied by the CIA, among other government agencies. (Don't yet know whether I consider that a Good Thing...)
I agree that the documentation could be presented much better. Better searching, better user interface, better examples, etc...
The whole structure of your database (and many other details) are available inside the pg_* system tables. Once your learn how these work, you can just make queries against these, which can return any aspect of the table structure. (in a far more sophisticated way than MySQL, by the way)
Also, I have to comment on the date/time issue. I found out, through a very painful piece of experience (a project that was all about dates), that it is impossible to rely on MySQL to manage dates properly. Mainly this is because MySQL doesn't support proper constraints for date column types. Any year can have a 0 month, as well as a 1-12 month. Any month can have a 0 day, as well as 1-31 (notice, it doesn't deal with differences in the number of days in each month). The result, A year can actually have 13 months, and every month can have up to 32 days. This just begs for data corruption!!
PostgreSQL's approach to date manipulation is more complex. That's because it is CORRECT. Every aspect of date/time management is available, including the all-important INTERVAL datatype, which is a dream for serious time-related projects. (and it is probably a dream to imagine it will ever appear in MySQL's TODO list)
By the way, casting to INTERVAL is the correct way to deal with your "elapsed days" problem:
(now() - mydate)::interval
This is usually all you need when dealing with this, if you are using it for other date calculations. But, if you really want to get just the days as an integer, without the chance of seeing '1 year 2 months' in the output, then your above expression should be updated to:
int4(extract(epoch from (now()-mydate))/ 60/60/24)
This is still somewhat ugly, but here is the beauty of a true DBMS: just use it to create a function (stored procedure) that you can call anytime, which could look something like:
Having played with each of the methods you describe above, I can't imagine how to make data storage simpler than SQL (except for a better relational language, perhaps). Heirarchical data storage is a disaster waiting to happen. (And I mean XML, too).
I mean, of course anything can be argued to the point of stupidiy. If you just want to store a few flat lists of items, then sure: use a text file, but once you go beyond that (and you always will), standardization is your friend.
And we're not talking about hundreds of megabytes of 3rd-party software. Really, the PostgreSQL install footprint is a few megabytes. Or try Interbase/Firebird, which is only about a 3 MB download these days. Both of these DBMS's use ANSI standard SQL, so if you just learn SQL once, you pretty much can use the basics anywhere.
Of course, different DBMS's have different advanced/complex capabilities, but by the time you start needing advanced capabilities, it is still quicker to learn a DBMS than create your own advanced data storage.
i never really found a clear reason on which was better performance-wise, though i suspect the filesystem-based way is. i also found it to be less of a hassle to implement. any intelligent thoughts?
The only intelligent thought I can add to this is: sometimes performance isn't the only factor. Yes, of course--all things being equal-- the filesystem is faster, but filesystems can't enforce data integrity constraints.
I agree that it is ludicrous to store non-critical images in the database, such as standard website graphics, photo albums, etc...
BUT, if you are creating a document management system, and you want to make sure that scanned document X cannot be deleted unless user Y has viewed it, then a database is often the most sensible solution. Otherwise, your code will have to enforce constraints in two places. And what happens if the IT dept wants another application to play with the same data? If it's all in the database, and your constraints are in the database, then you sleep a little easier.
For remote access, all the server has to do is send XML data to Mozilla. Also, Mozilla natively supports the SOAP API, so it can access any SOAP data source. Cool, huh?
It's a little different if you are talking about accessing client-side data sources. Mozilla/XUL is (kind of) a virtual machine (VM), meaning it doesn't intrude too much upon the client's OS. But, XUL/XPCOM has bindings for all kinds of programming languages, such as C, C++, Perl, Python, Ruby, and the list keeps getting longer (Good intro here). Thus, on the client-side you can use the database capability of any of these to talk to the Mozilla elements. I'm sure it wouldn't be too hard to whip up just a little communication between Mozilla and ODBC;-).
> How close is this Mozilla thing to supporting that?
Probably as close as it gets, without replacing every computer in the world with exactly the same OS. Fire up Mozilla and browse http://www.xulplanet.com/tutorials/xultu/
I really think Javascript is an under-appreciated resource. Your reservations about intepreter bugs, version differences, etc... all apply to any distributed application. If the client is version X.1, and you upgrade all clients to X.1.1, but one person misses the upgrade, what do you do? You detect when that person finally logs in, and instruct him/her to get the upgrade.
And since we are not talking about an attempt at cross-browser Javascript, I foresee even less difficulty.
Anyway the Javascript feature to update form elements is the oldest, most _core_ part of Javascript, ever since Javascript first came out. Any browser from Netscape 2 to Internet Explorer 3 supports that basic ability.
I don't have screenshots of my implementation at the moment, but I explain a very basic example: I had a client who wanted to implement a browser-based chat system (I know... ugh..). I know most of these involve auto-refresh headers, and the cleverer ones separate out the non-updating parts with frames. I took it one step further. I used three frames. The top frame was the entry , and the bottom frame was the output area, which contained the text from both participants. The third frame was hidden, and had absolutely no HTML for display, just a basic refresh meta-tag, and a section. The block simply received the latest incoming chat text, set it as a javascript variable, and called a javascript function in the upper frame, which appended it to the element in the lower frame. Most requests in that hidden frame were tiny, averaging about 120 bytes, getting nothing more than the raw text of the message, plus about 40 bytes of HTML/Javascript.
Extremely simple, but effective. I have since worked on some other ways of communicating between the server-side and Javascript _without_ even requiring a hidden frame. See my comments as member 'rycamor' at this Devshed thread: http://forums.devshed.com/showthread.php?s=&thread id=16326
I have recently become very interested in XUL/XPCOM, which seems to have matured a lot in the past year. I actually read with interest your SCGUI concepts a few months ago, and I think its quite possible that this could be implemented in the Mozilla XUL/XPCOM framework.
I agree that the term "webservices" is just a way to overhype what is essentially a very simple concept. The only real complexity comes from the laughable attempt to turn XML into both a database platform and a programming language, when it is really just a data interchange format (and an inefficient one at that). As Fabian Pascal says, this is what you get when you have a protocol "Invented by text publishers without any understanding of database management."
But anyway, It seems that XUL is one of the few good examples of a use for XML: custom tags to create truly functional GUI components. The only thing it is lacking is your concept that each element should be able to "requery" it's status from the server, without downloading the whole document again. Well, I have already implemented that capability with simple Javascript and regular HTML, so I doubt that it would really be a challenge to to it with Mozilla/XUL, which is in many ways more Javascript-friendly.
> XUL is one of my least favourite inventions ever
Why does everyone keep knocking XUL. Everything I have seen about it tells me _this_ is the way I want to be developing web apps. No more screwing around with DHTML menus, and Javascript trees that don't expand/collapse properly. Yes, its not cross-browser, but it is completely cross-platform.
And its really capable of being more than just a web application framework, but a real distributed app framework. This thing is the answer to the client side of.NET before.NET was invented. It even has a SOAP API all ready for use (http://www.oreillynet.com/pub/a/javascript/synd/2 002/08/30/mozillasoapapi.html). Not to mention, it has already been used to develop some pretty cool stand-alone applications, such as Komodo by ActiveState.
Fire up Mozilla or Phoenix and spend some time at http://www.xulplanet.com/tutorials/xultu/ or browse the list at http://www.mozdev.org/projects.html
Also, O'Reilly has already devoted a whole section to Mozilla XUL/XPCOM development (http://www.oreillynet.com/mozilla/).
XUL/XPCOM has bindings for Perl and Python, by the way. This is one bandwagon I don't mind jumping on, personally. Much more fun than.NET or Java.
I'm with you all the way;-). I personally think XUL is a great thing (shows great promise for distributed apps in general).
Mozilla performs just fine on my PII 600 (Win2K), my AMD 550 (Win98) and my Celeron 500 (Slackware). Phoenix (lite Mozilla) performs even better, beats IE hands down.
And I think the skinnable thing is a perfect way to have a little fun, and relieve the gray boredom of computing. My wife (not a computer geek) loves Mozilla. Everyone I know who is not a computer whiz still thinks Mozilla is great when I show them.
What kills me is this elitist "no fun" attitude I see programmers so often take: as if the interface always needs to be so dumbed down that it's just made for Granny, and there can _never_ be even the slightest deviation from the standardized desktop. Well, if it's only good for Granny, then it's no good to anyone else. People are complex. No one I know is "Granny". My mother is probably the most technophobic person I know, and even she can handle the concept that a button might look a little different. I personally think different things _should_ look different (a little line I stole from Larry Wall).
And anyway, if you want a browser for Granny, XUL is the perfect way to roll an ultra-simple layout, with big typeface, etc... Granny is hardly the one who is going to care if a widget takes an extra half second to pop up.
I understand the desire to streamline, and get XUL out of the browser's own interface.
However, I also see the promise that XUL has for application developers. It's a dream for distributed applications, especially for corporate intranet stuff.
So, my question is: even if you remove XUL from the browser UI, as with Galeon, will the Gecko rendering engine still render XUL that I might want to load via HTTP?
If so, I see this as a Good Thing: we can have a hundred different browsers, but each will correctly render complex GUI widgets, which are a mess to handle with DHTML/Javascript, and each of which can be queried and updated at will. Sounds like a perfect answer to.NET on the client side.
Anyone with a little more knowledge who can clarify things here?
Wrong. There are many more at MozDev, as well as links to other Mozilla/XUL sites. Also Komodo , a commercial product was written with Mozilla. Activestate is actually making money with this.
O'reilly is taking this seriously. Maybe they know something you don't;-)?
I don't really think it is about Netscape or AOL. The people who worked on the Mozilla project were not necessarily working on a specific corporate project; they were working on an open-source _idea_, which has some far-reaching benefits.
Yes, I agree that there needs to be more organization, documentation, and in general more attention paid to this project for it to catch on. That's why I am posting this. I hope more of you reading this will realize the potential that is here, and maybe contribute some...
As for it's usefulness as an application dev platform, at least one company has made a pretty nifty commercial product out of it. ActiveState's Komodo was written with the Mozilla framework. It is not a toy: it is actually a fairly capable programmer's IDE and text editor. I was surprised. Yes it is not as fast as a native C++ app, but it is definitely better than an IDE using Java for it's GUI engine (Zend, anyone?).
One great thing about this framework is that it doesn't try to be everything, like so many other frameworks out there. It concentrates on client-side UI, letting you do server-side, or even client-side logic in whatever language you want. Since it is XML-based, it is a natural for any language with XML/XSLT capabilities, which is just about every server-side scripting language these days.
The other thing that kills me about these types of "mini articles" is the abysmal lack of knowledge of these IT reporters. You would think that a journalist for the computer industry should understand:
- database != DBMS (a database is the instance, a DBMS is the management tool)
- there is no such thing as a "transactional database". Who comes up with this lingo?
- "the database-feature war is over". Who, even with a _little_ knowledge of database theory, could say this without embarassment? I'm sure the reporter thought he was being helpful by distilling Mickos' statements down to that, but it's obvious he just doesn't have a clue. If Mickos really said that phrase (which I doubt), he is being patently dishonest here.
- According to the third paragraph, you would think that the only things that matter about an enterprise DBMS are 1) number of users, 2) quantity of data, and 3) connectivity options. None of these are even central to what a DBMS should provide, in the area of querying capability, logical constraints, data integrity, etc...
- And no, PostgreSQL didn't suffer a "setback". It is going stronger than ever.
This is because the Mozilla project is _more_ than just a browser. It is an application framework. (see http://www.mozilla.org/projects/). The scope of what they have taken on is amazing.
I personally think the XUL think was a very far-thinking investment in developer mind-share. Yes, it hasn't paid off yet, but have you actually taken a look at what XUL can do? (point Mozilla at http://www.xulplanet.com/tutorials/xultu/). This is a dream for web-based apps. I am so sick of the standard DHTML/Javascript cruft that I have to use to get a decent GUI. If Mozilla/XPToolkit/XUL (http://www.mozilla.org/xpfe/) become a standard, then I will be the happiest developer on earth. It really is kind of the answer to client-side.NET even before.NET was invented.
Yes, at first it was kind of slow, but that is because thay worked on features first, performance last. Honestly, with the hardware that is available nowadays, is performance really a problem? The average user can have a machine that only 5 years ago would have been considered a supercomputer, capable of rendering fullscreen realtime 3D at 30 fps, or better, so what's the problem compiling a little Javascript? On my "older" PIII 600, or my AMD 550, or even my Celeron 500, Mozilla seems to perform well, in both Windows and Linux. I personally don't see where the problem is. 1.5 Ghz machines now don't even cost $600.
There is always a trade-off between performance and features, but I think the Mozilla project took the long view, and I hope we will eventually see an XUL-type interface available for any GUI, on any platform. Goodbye.NET!!
Whenever I do that, IE crawls even more. All the test I have done show Mozilla winning for "many nested tables" rendering (WTF anyone wants that anyway?). I am using a PIII 600, with the bloatsome Windows 2000, and Mozilla 1.1 regularly beats IE.
Isn't this just grand? 1 hour to "warm up". Florida being a Microsoft-friendly kind of state (low-tech businesses), I'm willing to bet this was some horrid ASP/VB/IE/Activex/COM implementation.
And the same thing could have been accomplished with a Perl script running in terminal mode on Linux or FreeBSD. Hardware would be cheap, and the thing could boot and be ready for business in 25 seconds. You don't need a full graphical windowing environment for people to make a series of pre-defined choices.
Actually, the porn thing is the one that baffles me. We are talking about the same internet where people trade music all the time for free, but for some reason they don't get that concept with porn? (But then again, I have never even desired to be a member of a porn site, so maybe I am missing something about the motivations involved)
As to the gullibility of American folk, I can attest: I knew one family friend who had a six-figure inheritance from her dead husband, and immediately spent 11,000 on one of those "own your own internet business" deals by Amway spin-off Quixtar. What this boiled down to was that she had pre-purchased "space" on the servers for 20 websites, or some ridiculous number, and now all she had to do was find 20 customers willing to spend 700+ for a cheesy prefab website. Success is guaranteed!!!
The same woman also spent several thousand on a scam in Miami, Florida (where I live), in which people would purchase "raw materials" to build necklaces at home, which were then "bought back" by the company. For a few weeks, these gullibles seemed to be turning a handy little profit, so they kept coming back for more, spending more money each time (get it?). When a critical mass of suckers was begging to the chance to purchase the gems, suddenly the company management disappeared with the "raw material" cash, leaving 15,000 bewildered "investors". (At one point it was said that there were enough of these necklaces floating around in Miami that everyone could buy one). In a typical Miami twist, the state attorney's office decided to auction off the left-over gems, which were actually worth some money. The winning bidders, who disappeared with the gems, turned out to be the scam's perpetrators (Unique Gems International).
Great Bridge was most decidedly NOT a parent company to PostgreSQL. Just a joint venture partner. PostgreSQL is not a commercial enterprise. It is a classic open source effort, with developers from all over the world joining in.
Great Bridge did not go out of business because PostgreSQL "sucked". They went out of business because they had a bad business plan, just like all the other companies around 1999-2000 that thought "open source" was somehow magically going to provide them an income. There was very little critical thinking applied to these business ideas at the time, because the tech market was still coasting off the stock boom of the 90s.
What Great Bridge didn't stop to think about was that the typical PostgreSQL user is savvy enough to just download the source for free, compile, and read the excellent pgsql-* newsgroups for support that is better than any commercial product I have seen yet. So there was really no compelling reason why these guys should suddenly spend money on PostgreSQL.
Even though Great Bridge went out of business, the PostgreSQL team kept right on improving it, to the point where it is only a couple of features away from directly competing with the large commercial DBMS's.
Actually, yes. See http://www.howstuffworks.com/question295.htm
If you see the dcumentary of the making of "The Matrix", you can see the actual setup. It doesn't take hundreds of cameras, though. Film operates at 24 frames per second, so 2 seconds worth of "fly around" would only need 48 cameras, give or take.
I'm sure it would be possible to use tweening to assist in the motion, but hardly necessary. This effect has been around for a few years, definitely before video and filmmaking went completely digital.
Slashdot Mirror
MVC is just an object-oriented design concept. There's no reason you can't do it with PHP. And, if you want a "middle tier" for PHP (persistent objects/connections, brokering, etc...), check out http://www.vl-srm.net/
I will have to agree that Cordwainer Smith is one of the few sci-fi writers I have read who's writing itself I would consider "riveting".
e r.php3).
The science itself wasn't very strong, but the sheer imagination he poured into hist stories was incredible. And often hilarious. What other sci-fi writer would have thought of having of oneself freeze-dried, chopped up and shipped to earth to be "reconstituted" at the other end, as a means of escaping a manhunt?
Although a lot of his scientific ideas are odd, even macabre, the books aren't really about the science, but about characters, personalities, and some very intriguing psychological, philosophical, and political ideas. In that sense, his writing reminds me of one other forgotten sci-fi writer: Jack Vance (http://www.vanceintegral.com/)
By the way, Cordwainer Smith's real name was Paul Linebarger, and part of the reason he didn't write that many sci-fi books is that he actually had a very interesting life of his own (http://www.catch22.com/SF/ARB/SFS/Smith,Cordwain
among other things, he was the writer of the non-fiction "Psychological Warfare", which is apparently considered an a definitive work in that area. It is studied by the CIA, among other government agencies. (Don't yet know whether I consider that a Good Thing...)
I agree that the documentation could be presented much better. Better searching, better user interface, better examples, etc...
The whole structure of your database (and many other details) are available inside the pg_* system tables. Once your learn how these work, you can just make queries against these, which can return any aspect of the table structure. (in a far more sophisticated way than MySQL, by the way)
Also, I have to comment on the date/time issue. I found out, through a very painful piece of experience (a project that was all about dates), that it is impossible to rely on MySQL to manage dates properly. Mainly this is because MySQL doesn't support proper constraints for date column types. Any year can have a 0 month, as well as a 1-12 month. Any month can have a 0 day, as well as 1-31 (notice, it doesn't deal with differences in the number of days in each month). The result, A year can actually have 13 months, and every month can have up to 32 days. This just begs for data corruption!!
PostgreSQL's approach to date manipulation is more complex. That's because it is CORRECT. Every aspect of date/time management is available, including the all-important INTERVAL datatype, which is a dream for serious time-related projects. (and it is probably a dream to imagine it will ever appear in MySQL's TODO list)
By the way, casting to INTERVAL is the correct way to deal with your "elapsed days" problem:
(now() - mydate)::interval
This is usually all you need when dealing with this, if you are using it for other date calculations. But, if you really want to get just the days as an integer, without the chance of seeing '1 year 2 months' in the output, then your above expression should be updated to:
int4(extract(epoch from (now()-mydate))/ 60/60/24)
This is still somewhat ugly, but here is the beauty of a true DBMS: just use it to create a function (stored procedure) that you can call anytime, which could look something like:
days_elapsed(now(),mydate);
Now, is everybody happy?
Having played with each of the methods you describe above, I can't imagine how to make data storage simpler than SQL (except for a better relational language, perhaps). Heirarchical data storage is a disaster waiting to happen. (And I mean XML, too).
I mean, of course anything can be argued to the point of stupidiy. If you just want to store a few flat lists of items, then sure: use a text file, but once you go beyond that (and you always will), standardization is your friend.
And we're not talking about hundreds of megabytes of 3rd-party software. Really, the PostgreSQL install footprint is a few megabytes. Or try Interbase/Firebird, which is only about a 3 MB download these days. Both of these DBMS's use ANSI standard SQL, so if you just learn SQL once, you pretty much can use the basics anywhere.
Of course, different DBMS's have different advanced/complex capabilities, but by the time you start needing advanced capabilities, it is still quicker to learn a DBMS than create your own advanced data storage.
For remote access, all the server has to do is send XML data to Mozilla. Also, Mozilla natively supports the SOAP API, so it can access any SOAP data source. Cool, huh?
;-).
It's a little different if you are talking about accessing client-side data sources. Mozilla/XUL is (kind of) a virtual machine (VM), meaning it doesn't intrude too much upon the client's OS. But, XUL/XPCOM has bindings for all kinds of programming languages, such as C, C++, Perl, Python, Ruby, and the list keeps getting longer (Good intro here). Thus, on the client-side you can use the database capability of any of these to talk to the Mozilla elements. I'm sure it wouldn't be too hard to whip up just a little communication between Mozilla and ODBC
I have, and it's nowhere near as capable.
> How close is this Mozilla thing to supporting that?
Probably as close as it gets, without replacing every computer in the world with exactly the same OS. Fire up Mozilla and browse http://www.xulplanet.com/tutorials/xultu/
> all mozilla needs now is support for more than just Javascript.
/ library/co-xpcom.html
Oh, I see you are talking about Mozilla's XPCOM:
C++
Perl
Python
Ruby
Also see http://www-106.ibm.com/developerworks/webservices
I really think Javascript is an under-appreciated resource. Your reservations about intepreter bugs, version differences, etc... all apply to any distributed application. If the client is version X.1, and you upgrade all clients to X.1.1, but one person misses the upgrade, what do you do? You detect when that person finally logs in, and instruct him/her to get the upgrade.
d id=16326
;-).
And since we are not talking about an attempt at cross-browser Javascript, I foresee even less difficulty.
Anyway the Javascript feature to update form elements is the oldest, most _core_ part of Javascript, ever since Javascript first came out. Any browser from Netscape 2 to Internet Explorer 3 supports that basic ability.
I don't have screenshots of my implementation at the moment, but I explain a very basic example: I had a client who wanted to implement a browser-based chat system (I know... ugh..). I know most of these involve auto-refresh headers, and the cleverer ones separate out the non-updating parts with frames. I took it one step further. I used three frames. The top frame was the entry , and the bottom frame was the output area, which contained the text from both participants. The third frame was hidden, and had absolutely no HTML for display, just a basic refresh meta-tag, and a section. The block simply received the latest incoming chat text, set it as a javascript variable, and called a javascript function in the upper frame, which appended it to the element in the lower frame. Most requests in that hidden frame were tiny, averaging about 120 bytes, getting nothing more than the raw text of the message, plus about 40 bytes of HTML/Javascript.
Extremely simple, but effective. I have since worked on some other ways of communicating between the server-side and Javascript _without_ even requiring a hidden frame. See my comments as member 'rycamor' at this Devshed thread: http://forums.devshed.com/showthread.php?s=&threa
I'll email you to discuss this further
Hey Tablizer,
I have recently become very interested in XUL/XPCOM, which seems to have matured a lot in the past year. I actually read with interest your SCGUI concepts a few months ago, and I think its quite possible that this could be implemented in the Mozilla XUL/XPCOM framework.
I agree that the term "webservices" is just a way to overhype what is essentially a very simple concept. The only real complexity comes from the laughable attempt to turn XML into both a database platform and a programming language, when it is really just a data interchange format (and an inefficient one at that). As Fabian Pascal says, this is what you get when you have a protocol "Invented by text publishers without any understanding of database management."
But anyway, It seems that XUL is one of the few good examples of a use for XML: custom tags to create truly functional GUI components. The only thing it is lacking is your concept that each element should be able to "requery" it's status from the server, without downloading the whole document again. Well, I have already implemented that capability with simple Javascript and regular HTML, so I doubt that it would really be a challenge to to it with Mozilla/XUL, which is in many ways more Javascript-friendly.
Your thoughts?
> XUL is one of my least favourite inventions ever
.NET before .NET was invented. It even has a SOAP API all ready for use (http://www.oreillynet.com/pub/a/javascript/synd/2 002/08/30/mozillasoapapi.html). Not to mention, it has already been used to develop some pretty cool stand-alone applications, such as Komodo by ActiveState.
.NET or Java.
Why does everyone keep knocking XUL. Everything I have seen about it tells me _this_ is the way I want to be developing web apps. No more screwing around with DHTML menus, and Javascript trees that don't expand/collapse properly. Yes, its not cross-browser, but it is completely cross-platform.
And its really capable of being more than just a web application framework, but a real distributed app framework. This thing is the answer to the client side of
Fire up Mozilla or Phoenix and spend some time at http://www.xulplanet.com/tutorials/xultu/ or browse the list at http://www.mozdev.org/projects.html
Also, O'Reilly has already devoted a whole section to Mozilla XUL/XPCOM development (http://www.oreillynet.com/mozilla/).
XUL/XPCOM has bindings for Perl and Python, by the way. This is one bandwagon I don't mind jumping on, personally. Much more fun than
Fark.com rendered nice and fast in Phoenix 0.2. At least 2 or 3 times as fast as IE 5.5.
I'm with you all the way ;-). I personally think XUL is a great thing (shows great promise for distributed apps in general).
Mozilla performs just fine on my PII 600 (Win2K), my AMD 550 (Win98) and my Celeron 500 (Slackware). Phoenix (lite Mozilla) performs even better, beats IE hands down.
And I think the skinnable thing is a perfect way to have a little fun, and relieve the gray boredom of computing. My wife (not a computer geek) loves Mozilla. Everyone I know who is not a computer whiz still thinks Mozilla is great when I show them.
What kills me is this elitist "no fun" attitude I see programmers so often take: as if the interface always needs to be so dumbed down that it's just made for Granny, and there can _never_ be even the slightest deviation from the standardized desktop. Well, if it's only good for Granny, then it's no good to anyone else. People are complex. No one I know is "Granny". My mother is probably the most technophobic person I know, and even she can handle the concept that a button might look a little different. I personally think different things _should_ look different (a little line I stole from Larry Wall).
And anyway, if you want a browser for Granny, XUL is the perfect way to roll an ultra-simple layout, with big typeface, etc... Granny is hardly the one who is going to care if a widget takes an extra half second to pop up.
I understand the desire to streamline, and get XUL out of the browser's own interface.
.NET on the client side.
However, I also see the promise that XUL has for application developers. It's a dream for distributed applications, especially for corporate intranet stuff.
So, my question is: even if you remove XUL from the browser UI, as with Galeon, will the Gecko rendering engine still render XUL that I might want to load via HTTP?
If so, I see this as a Good Thing: we can have a hundred different browsers, but each will correctly render complex GUI widgets, which are a mess to handle with DHTML/Javascript, and each of which can be queried and updated at will. Sounds like a perfect answer to
Anyone with a little more knowledge who can clarify things here?
Thanks.
Wrong. There are many more at MozDev, as well as links to other Mozilla/XUL sites. Also Komodo , a commercial product was written with Mozilla. Activestate is actually making money with this.
;-)?
O'reilly is taking this seriously. Maybe they know something you don't
I don't really think it is about Netscape or AOL. The people who worked on the Mozilla project were not necessarily working on a specific corporate project; they were working on an open-source _idea_, which has some far-reaching benefits.
Yes, I agree that there needs to be more organization, documentation, and in general more attention paid to this project for it to catch on. That's why I am posting this. I hope more of you reading this will realize the potential that is here, and maybe contribute some...
As for it's usefulness as an application dev platform, at least one company has made a pretty nifty commercial product out of it. ActiveState's Komodo was written with the Mozilla framework. It is not a toy: it is actually a fairly capable programmer's IDE and text editor. I was surprised. Yes it is not as fast as a native C++ app, but it is definitely better than an IDE using Java for it's GUI engine (Zend, anyone?).
One great thing about this framework is that it doesn't try to be everything, like so many other frameworks out there. It concentrates on client-side UI, letting you do server-side, or even client-side logic in whatever language you want. Since it is XML-based, it is a natural for any language with XML/XSLT capabilities, which is just about every server-side scripting language these days.
The other thing that kills me about these types of "mini articles" is the abysmal lack of knowledge of these IT reporters. You would think that a journalist for the computer industry should understand:
- database != DBMS (a database is the instance, a DBMS is the management tool)
- there is no such thing as a "transactional database". Who comes up with this lingo?
- "the database-feature war is over". Who, even with a _little_ knowledge of database theory, could say this without embarassment? I'm sure the reporter thought he was being helpful by distilling Mickos' statements down to that, but it's obvious he just doesn't have a clue. If Mickos really said that phrase (which I doubt), he is being patently dishonest here.
- According to the third paragraph, you would think that the only things that matter about an enterprise DBMS are 1) number of users, 2) quantity of data, and 3) connectivity options. None of these are even central to what a DBMS should provide, in the area of querying capability, logical constraints, data integrity, etc...
- And no, PostgreSQL didn't suffer a "setback". It is going stronger than ever.
This is because the Mozilla project is _more_ than just a browser. It is an application framework. (see http://www.mozilla.org/projects/). The scope of what they have taken on is amazing.
.NET even before .NET was invented.
.NET!!
I personally think the XUL think was a very far-thinking investment in developer mind-share. Yes, it hasn't paid off yet, but have you actually taken a look at what XUL can do? (point Mozilla at http://www.xulplanet.com/tutorials/xultu/). This is a dream for web-based apps. I am so sick of the standard DHTML/Javascript cruft that I have to use to get a decent GUI. If Mozilla/XPToolkit/XUL (http://www.mozilla.org/xpfe/) become a standard, then I will be the happiest developer on earth. It really is kind of the answer to client-side
Yes, at first it was kind of slow, but that is because thay worked on features first, performance last. Honestly, with the hardware that is available nowadays, is performance really a problem? The average user can have a machine that only 5 years ago would have been considered a supercomputer, capable of rendering fullscreen realtime 3D at 30 fps, or better, so what's the problem compiling a little Javascript? On my "older" PIII 600, or my AMD 550, or even my Celeron 500, Mozilla seems to perform well, in both Windows and Linux. I personally don't see where the problem is. 1.5 Ghz machines now don't even cost $600.
There is always a trade-off between performance and features, but I think the Mozilla project took the long view, and I hope we will eventually see an XUL-type interface available for any GUI, on any platform. Goodbye
Whenever I do that, IE crawls even more. All the test I have done show Mozilla winning for "many nested tables" rendering (WTF anyone wants that anyway?). I am using a PIII 600, with the bloatsome Windows 2000, and Mozilla 1.1 regularly beats IE.
Isn't this just grand? 1 hour to "warm up". Florida being a Microsoft-friendly kind of state (low-tech businesses), I'm willing to bet this was some horrid ASP/VB/IE/Activex/COM implementation.
And the same thing could have been accomplished with a Perl script running in terminal mode on Linux or FreeBSD. Hardware would be cheap, and the thing could boot and be ready for business in 25 seconds. You don't need a full graphical windowing environment for people to make a series of pre-defined choices.
Tablizer, your tireless persistence is somehow gratifying ;-)
Has any OS ever implemented a set/predicate-oriented filesystem, instead of a heirarchical one?
I like these ideas, although I'm not sure I see all the ramifications.
"byte the bullet" -- cute
Actually, the porn thing is the one that baffles me. We are talking about the same internet where people trade music all the time for free, but for some reason they don't get that concept with porn? (But then again, I have never even desired to be a member of a porn site, so maybe I am missing something about the motivations involved)
As to the gullibility of American folk, I can attest: I knew one family friend who had a six-figure inheritance from her dead husband, and immediately spent 11,000 on one of those "own your own internet business" deals by Amway spin-off Quixtar. What this boiled down to was that she had pre-purchased "space" on the servers for 20 websites, or some ridiculous number, and now all she had to do was find 20 customers willing to spend 700+ for a cheesy prefab website. Success is guaranteed!!!
The same woman also spent several thousand on a scam in Miami, Florida (where I live), in which people would purchase "raw materials" to build necklaces at home, which were then "bought back" by the company. For a few weeks, these gullibles seemed to be turning a handy little profit, so they kept coming back for more, spending more money each time (get it?). When a critical mass of suckers was begging to the chance to purchase the gems, suddenly the company management disappeared with the "raw material" cash, leaving 15,000 bewildered "investors". (At one point it was said that there were enough of these necklaces floating around in Miami that everyone could buy one). In a typical Miami twist, the state attorney's office decided to auction off the left-over gems, which were actually worth some money. The winning bidders, who disappeared with the gems, turned out to be the scam's perpetrators (Unique Gems International).
"their product"? (not there)
Great Bridge was most decidedly NOT a parent company to PostgreSQL. Just a joint venture partner. PostgreSQL is not a commercial enterprise. It is a classic open source effort, with developers from all over the world joining in.
Great Bridge did not go out of business because PostgreSQL "sucked". They went out of business because they had a bad business plan, just like all the other companies around 1999-2000 that thought "open source" was somehow magically going to provide them an income. There was very little critical thinking applied to these business ideas at the time, because the tech market was still coasting off the stock boom of the 90s.
What Great Bridge didn't stop to think about was that the typical PostgreSQL user is savvy enough to just download the source for free, compile, and read the excellent pgsql-* newsgroups for support that is better than any commercial product I have seen yet. So there was really no compelling reason why these guys should suddenly spend money on PostgreSQL.
Even though Great Bridge went out of business, the PostgreSQL team kept right on improving it, to the point where it is only a couple of features away from directly competing with the large commercial DBMS's.
Actually, yes. See http://www.howstuffworks.com/question295.htm
If you see the dcumentary of the making of "The Matrix", you can see the actual setup. It doesn't take hundreds of cameras, though. Film operates at 24 frames per second, so 2 seconds worth of "fly around" would only need 48 cameras, give or take.
I'm sure it would be possible to use tweening to assist in the motion, but hardly necessary. This effect has been around for a few years, definitely before video and filmmaking went completely digital.