I dislike HTML in e-mail. A lot. However, I must now play devil's advocate, because I realize that like spam, it is an annoying fact of modern e-mail that ain't going away...
Active content doesn't enhance the e-mail experience for most users, nor does it increase their productivity to any measurable extent. For most people, what is important is the actual *content*, the presentation is in most real-world cases a secondary, trivial issue.
I say at least 50% of non-technical users regularly use HTML e-mail features all the time, either on purpose (graphic images as part of their signature, special fonts), or without knowing it (most emails I get from non-technical people that are not sent via Hotmail or Yahoo!-type accounts come as MIME multipart, i.e. HTML with a second text-only version).
HTML-based e-mail is larger, slower, potentially a hassle across a heterogeneous array of e-mail clients
It's not noticeably slower. It is larger, but nobody in corporate america notices. I think most standard mail clients for Windows and the Mac can handle HTML emails equally well. As for Unix/Linux, who cares? (Not my opinion, Linux has been my primary desktop for years.)
On the other hand, your assertion that "(business types) are not concerned about privacy issues" is simply naive at best. It's a cutthroat world and business users have things like trade secrets and confidential information to worry about. And I would suspect that most people, in a business environment or otherwise, would like to believe that their e-mail correspondance is private. I'd even go so far as to bet that the majority of users actually *believe* their e-mail is private, and would be upset to find out otherwise.
Actually, businesses pretend they care about privacy, but only as far as protecting privacy doesn't hinder convenience. Note that employees already know their email isn't private; companies read employee email all the time. But even in keeping it secure, companies will sacrifice security for the sake of convenience and simplicity. It happens all the time.
----------
Political candidates have a right to publicly state their case, but they don't have a right to enter your home and start putting campaign posters on your wall... ----------
The two contrasted issues here are freedom of speech for business, and privacy rights for consumers.
First of all, I don't know that there is a commercial free speech to receive business solicitations in my home. It's a little different in outdoor ads, but when it comes to my home, I can hardly believe there is a "free speech" right for businesses to enter my home and put ads everywhere. And yes, receiving spam is the equivalent. This happens already with snail mail, but that doesn't mean it is so because it is constitutionally guaranteed.
Even if there were a business right to spam, there is the issue of consumer's right to privacy, which I believe is also consitutionally guaranteed. Does that matter? Apparently it doesn't, but it should.
Really, the issue is about what is more important: consumer rights or business rights. I argue that consumer's right to not be bombarded with ads at home outweighs the rights of business to spam me. If you are about to say that it is important for businesses to thrive, which in the end benefits consumers anyway, then great, because it leads to my next point...
Spam is completely anti-business. It is in the nature of spam that any idiot can bulk email millions for almost no cost. If it is not regulated, it will spiral beyond control, because even more idiots will use it. For many people this is the case already. Without government control, it will get worse, and email runs the risk of becoming useless due to extremely low signal/noise ratio.
Unfortunately, none of this really matters, because the people that really cause a problem with spam are the aforementioned idiots that don't care what laws are passed. Without secure mail and authentication, I'm afraid spam is here to stay. ----------
Sure, Linux could survive without the "industry". But without it, it wouldn't be anywhere even remotely where it is today in terms of capability and future.
Would Linux be anywhere near as popular without commercial distributions like Red Hat and SuSE?
Journaling file systems, tons of hardware device drivers either contributed outright or aided by the manufacturer, XFree86 DRI, etc... none possible without the Linux "industry".
Red Hat, VA Linux, IBM and many, many others are paying for Linux development. Would these developers be able to contribute as much on a purely volunteer basis vs. full-time? Would they be able to contribute at all?
The fact is that Linux will obviously grow much, much faster---both in market share and ability---with commercial support. And some things would simply not ever be accomplished without commercial support.
I can understand some of the waryness, but to think Linux doesn't need "the industry" is fallacy. The only serious progress Linux can make is with industry support. If you don't want great improvements on the desktop, towards enterprise class server solutions and "Big Iron" mainframes, or towards embedded/portable devices, then fine, Linux can continue without the industry. But for Linux to truly succeed on a large scale, it needs "the industry" to take it there. ----------
I used the Red Hat 7 RPMs, and I have all the latest Ximian stuff installed, also the latest stable Evolution.
To get the RPMs to install, I had to use --oldpackage with RPM to install both libghttp (as noted on their RH 7 install instructions) and also bonobo.
After installing, it started with some "first time" configuration stuff, then promptly crashed. Trying to restart it resulted in an error about having to reboot or re-installing. Rebooting worked.
Unfortunately, it insists on setting the desktop background color. Yay, just what we need, an Nth way to do this. Somehow, after launching Nautilus, trying to set the background with GNOME, Enlightenmnet, or even xsetroot fails. You have to go into one of the menus with pixmaps on it, select the "solid color" button to the left, and drag and drop it to your background.
While it definitely looks better than PR2, it is unfortunately so far a lot more unstable for me. (Red Hat 7, PIII 400Mhz, latest Ximian everything). It crashed on first time after install; now it is refusing to startup.
Your mileage will vary, but while I am excited with a new release, and it does look a lot better---maybe even faster than PR2---I am surprised at the stability problems I've seen so far. (3:1 ratio of crashes to successful runs? Rebooting to fix problems? I feel like I'm in Windows...) I didn't use PR2 super extensively, but it definitely didn't have these problems. Especially when I've heard GNOME 1.4 is due in February, and Nautilus is supposed to be the included file manager. I would hate to see GNOME's excellent stability (yes, in 2000, GNOME became very stable) tainted...
And yes, I do plan to contribute by filing lots of bug reports... ----------
About the background: you can set it with Nautilus. Off the menu that has a bunch of pixmaps that you can drag and drop to change the look and feel, you can click on one of the left hand side buttons for solid colors, then drag and drop that into your background, and voila! it's changed.
I'd tell you which menu, but right now it is completely refusing to startup. ----------
Was the StarOffice 5.2 source released without mods as the StarOffice 5.2 source, or was it only released after Sun mucked with it and labeled it "OpenOffice"? If StarOffice source was not officially released, I'm not sure how SuSE got it or licensed it. ----------
No, nobody can force you to use anything. But if 90% of Linux users use major subsystem foo, and all of a sudden foo becomes completely proprietary, and the company doing that does it in a Microsoft fashion to exclude other possibilities, it becomes a pretty big problem.
Suppose in two years StarOffice becomes THE standard office suite for Linux. Suppose some company adds some key proprietary pieces, which everyone comes to depend on, which initially are usable by everyone. Then one day, oops, it only works on distribution X, and you have to pay for it, and oh yeah, it's on a subscription service...
All of a sudden 90% of Linux users get screwed. Even if you don't use it, you could end up screwed, because it could affect Linux's momentum in a major way.
Again, the more core a component is, the more important the GPL is. An office suite is not an "essential" component like the kernel, or something "optional" but pretty much essential like X/GNOME/KDE, but it's not exactly trivial either. ----------
I'm about to make some ignorant remarks, so someone more enlightened please, well, enlighten me.:)
Sounds to me like this is why the GPL is so important. I'm assuming (1) that this about OpenOffice, not just StarOffice, and (2) that the reason they can do this is because they are using the Sun Industry Standards Source License (SISSL) instead of the GPL. (OpenOffice is licensed under both GPL and SISSL, take your pick.)
If SISSL allows you to release such proprietary extensions, then it's a poor choice to allow OpenOffice to be licensed under it. While SuSE sounds like they will do The Right Thing and GPL their mods, what's to prevent someone else from not doing that in an attempt to privatize the whole thing? If OpenOffice is to become such a major project, it is very important for it to remain GPL.
This is similar to the old, ThankGodNoLongerRelevant GNOME/KDE license wars. The license under which core components for Linux are shipped is extremely important; it must be GPL, or else the whole system can breakdown if later on someone sneaks a major subsystem into proprietary land. While OpenOffice isn't as critical (license-wise) as the kernel, X, or GNOME/KDE, it has a shot at being the most popular office suite under Linux, and if the goal is try to keep it open source, it should have a truly open source license. ----------
I have heard (especially
on past slashdot rummagings on contracting) similar complaints. I find
them interesting because I have done contract work for 5 years, and have
only ended up along side other excellent contractors.
Of course, everyone's mileage will vary, but my experience is that you are
just as likely to find good/bad contractors as good/bad employees. The
good people are always hard to find, and I don't know that the odds are
better for one or the other... I've had to hire full-time programmers and I got thrown so many loser resumes it wasn't even
funny...
It sounds like your company needs better screening. Shouldn't screening a contractor be just as thorough as
hiring a full-time employee? I.e. look at personality fit, sense of
honesty, references, etc. I don't mean to knock your recruiters, but it
seems odd that you'd have so many bad experiences.
----------
Well, there's two different issues: the technology used to render to a specific platform (e.g. JSP for HTML, WAP for wireless), and the differing needs of the various platforms.
HTML, in theory, can still be the "universal" markup language, for all platforms, driven by PHP/JSP/ASP/Perl/whatever.
Even then, however, the fact remains that what you aim to present a user looking at an HTML page on their 17" monitor from home is different from what you want to present to a user on a cell phone with a 128x48 pixel screen. Clearly you need to display different things. In fact, what you need to display is so vastly different that it makes sense to code two completely different "pages" for each user, rather than a single one that will work under both, even with slight variations.
While in theory the actual technology to display one or the other doesn't have to change, e.g. HTML for both, in reality it also makes sense for it to change also, for similar reasons. HTML has evolved around needs surrounding display on your typical CRT, and those needs are going to be very different from those for smaller devices. ----------
Completely agree, the latest Mozilla 0.7 build is a huge improvement over M18, and in terms of performance, over 0.6 also. I don't know what they did, but it's a hell of a lot faster.
And, I highly recommend galeon; it's a GNOME browser, built using Gtk, but using the Mozilla rendering engine of whatever Mozilla build you have installed. Much faster than running the full Mozilla, but with all the Mozilla standards support goodies. ----------
AOL is the only thing that will save the web from becoming IE-only. This is because AOL will eventually switch to Mozilla, which will force everyone to accomodate it. Hopefully this will mean a better world where web standards are followed more closely, given that by the time this happens, IE and Mozilla should have excellent standards support.
Yes, I'm sure there currently are, and always will be, standards compliance issues, but by the time AOL switches to Mozilla these will be for the most esoteric and cutting edge features, so for most sites, they will hopefully not be too bad. Even at this point, the latest Mozilla and IE support is supposed to be excellent.
Note that it's only AOL's use of Mozilla that will make Mozilla mean anything. Without AOL adopting Mozilla as its default browser, Mozilla will be relegated to the likes of Netscape, Opera and Lynx... no, I'm not bashing Lynx and Opera. It's just the truth that they will simply not be on any large commercial site's radar screens. They will not do anything to stop the tide of sites converting to IE only.
Some say that web access for other devices will help this situation, but I doubt it. The display needs and platforms for PDAs, cell phones, and whatever are so different that companies will code entirely different interfaces for those devices, instead of hoping that their HTML will work across all possible devices. This actually makes sense. Architecturally the "right thing" is to do the usual content/presentation separation, e.g. XML as the data stream and JSP/ASP/PHP for standard web display, WAP for wireless, etc. ----------
Wine is also a pain to install and run. I've
never been able to get anything beyond Notepad.
I tried it again recently with no success (when
the claims of running Word 2000 came out).
Nontheless, I highly recommend Win4Lin if you are
running Windows 95/98. (Yes, I know the poster
is using Windows 2000.) It is extremely fast and runs almost all non-game programs flawlessly (Outlook is probably the most notable exception, but Office, IE, and most stuff should be fine). ----------
I'm having trouble seeing them because Netscape to this day has problems with PNG. Every time I click on one of the image links, I get some funky reference to my browser's cache followed by "unknown or unsupported image type".
Duh, I guess I should have thought of that. I was concentrating on the meaning of a unicorn when it comes to replicants.
One thing that kept me skeptical about the whole thing was that I heard that the unicorn dream scene was taken from another movie (Legend, I think, which Scott also directed). This to me says that it really wasn't part of the original thinking of the movie (similar to adding the "happy ending", which is taken from, of all movies, The Shining), and that the whole thing was added to try to make the movie more interesting as a director's cut. In other words, it was a gimmick.
I guess you can argue you are then left with why Gaff left the unicorn, but I took that in and of itself to mean that Rachel had no termination date (unicorns being mythical creatures having to do with longevity). ----------
I love this movie, but I don't understand why the unicorn is a hint that he's a replicant. What does this really mean?
I guess I generally fail to see any real clue that he's a replicant. I don't see the unicorn as a clue, and fail to see others. Help? (Yes, I read the article, it still doesn't make sense.) ----------
All it does is start the text processor, or spreadsheet, or whatever, automatically within StarOffice, but it's no different from starting StarOffice and then opening a text document. I.e. if you then do the same thing for the spreadsheet, it opens up within the large MDI-type StarOffice window, not in a separate X window. ----------
I think you missed my point... I wasn't saying that JSP/PHP by themselves were good enough to substitute for XMLC. I'm saying that other XML to HTML solutions, combined with JSP, are better.
There is a difference between static and dynamic content, vs. how static content is generated. For example, a basic web page that doesn't vary for anyone could be generated on the fly with XMLC/Cocoon, but it's still essentially static content. If the page shows the current time on each access, then it's dynamic, even if it's a simple PHP HTML template.
So, for basic content generation, I think XML to HTML is a great idea. XMLC is one solution. XSL is another. The problem with XMLC is that it only works at run time, which is a non-trivial performance hit. (Especially when you consider static content, that can no longer be served as a plain HTML file, and has to go through a servlet engine.) With XSL, and perhaps other technologies, the XML to HTML processing can be done at build time, resulting in HTML files that can be served faster.
The reason I mention JSP or PHP is because then you have to insert dynamic content into the resulting HTML, and at that point, you need JSP/PHP/whatever. But keep in mind that if you apply the content/logic separation with JSP/PHP clean, then making sure that your XML to HTML translation adds the right JSP tags is easy. So, you still maintain your content/logic separation throughout the whole process. And you get an additional performance boost over XMLC because you are simply outputting new strings, as opposed to manipulating a DOM tree, which is harder and slower.
Bottom line: XMLC combines static content generation with dynamic content generation. Both are slow, because (a) it happens at run time, and (b) DOM manipulation is slow. My suggestion is to move static content generation to build time, and use a simpler technology, like JSP, that gives you the same content/logic separation, to do the dynamic stuff. This still involves using XML to keep the distinction between logic and presentation nice and clean. ----------
How do you generate the DOM tree beforehand? XMLC generates the Java class for the DOM tree at compile time, but it's still instantiated at run time, and it's a pretty heavy weight object. Also, the DOM manipulations at run time are much more expensive than simply outputting different text for the dynamic HTML.
I think something like XML/XSL at compile time, followed by JSP/PHP/whatever at runtime, works better, because you have the same content/design separation as XMLC, but not the performance implications.
BTW, even though you're speaking of WML in particular, I'm speaking of content serving in general. ----------
Ah, good idea. You're right about WAP devices, though, I also have no idea if they support client side scripting. I doubt they support JavaScript. In that case, it may be better to go with a server side solution, like the one mentioned above in reply to my question. ----------
While XMLC is a great idea, it is a performance hog, because you are generating a whole DOM tree, manipulating it, then displaying it, at run time. I don't know if Enhydra has introduced caching mechanisms, like the ones Apache's Cocoon is using, to alleviate this; right before I went off to another project, I was about to build this in.
A better approach is to statically do the base XML to HTML conversion, with JSP (or PHP, mod_perl, whatever) to introduce the final dynamic content. (I.e. convert the XML to a JSP with scriptlet tags for the true run time dynamic content.) Caching algorithms would alleviate this, but I don't see the advantage of doing it runtime, when it works just as well doing it statically. Even with caching, your performance will clearly be better. ----------
Another important point regarding XSL is that XSL doesn't preclude you from using CSS. Most of the XSL I've done results in HTML with CSS in it. The above referenced article also forgets that, right now, CSS and DOM implementations are horrible, so for the next few *years*, it will not be possible to rely strictly on CSS and DOM on the client. Clients need to see more pure HTML, with very few advanced CSS/DOM features, because they simply don't work uniformly. So, it is better to put more formatting into the initial XML transformation layer. For now.
In either case, as the poster above said, the real point of XSL is that you don't have to be a full fledged programmer to use it. While XSL can definitely be painful, I think it is better than writing a computer program in {Perl,Java,Python,*} to do the same thing. Unfortunately, it's not easy enough for just anyone to pick up, so it doesn't completely allow for designers or HTML coders to assume all control of layout without an engineer showing them the ropes, unless of course they are particularly bright and can pick it up. ----------
Slashdot Mirror
----------
Political candidates have a right to publicly state their case, but they don't have a right to enter your home and start putting campaign posters on your wall...
----------
First of all, I don't know that there is a commercial free speech to receive business solicitations in my home. It's a little different in outdoor ads, but when it comes to my home, I can hardly believe there is a "free speech" right for businesses to enter my home and put ads everywhere. And yes, receiving spam is the equivalent. This happens already with snail mail, but that doesn't mean it is so because it is constitutionally guaranteed.
Even if there were a business right to spam, there is the issue of consumer's right to privacy, which I believe is also consitutionally guaranteed. Does that matter? Apparently it doesn't, but it should.
Really, the issue is about what is more important: consumer rights or business rights. I argue that consumer's right to not be bombarded with ads at home outweighs the rights of business to spam me. If you are about to say that it is important for businesses to thrive, which in the end benefits consumers anyway, then great, because it leads to my next point...
Spam is completely anti-business. It is in the nature of spam that any idiot can bulk email millions for almost no cost. If it is not regulated, it will spiral beyond control, because even more idiots will use it. For many people this is the case already. Without government control, it will get worse, and email runs the risk of becoming useless due to extremely low signal/noise ratio.
Unfortunately, none of this really matters, because the people that really cause a problem with spam are the aforementioned idiots that don't care what laws are passed. Without secure mail and authentication, I'm afraid spam is here to stay.
----------
-
Would Linux be anywhere near as popular without commercial distributions like Red Hat and SuSE?
-
Journaling file systems, tons of hardware device drivers either contributed outright or aided by the manufacturer, XFree86 DRI, etc... none possible without the Linux "industry".
-
Red Hat, VA Linux, IBM and many, many others are paying for Linux development. Would these developers be able to contribute as much on a purely volunteer basis vs. full-time? Would they be able to contribute at all?
The fact is that Linux will obviously grow much, much faster---both in market share and ability---with commercial support. And some things would simply not ever be accomplished without commercial support.I can understand some of the waryness, but to think Linux doesn't need "the industry" is fallacy. The only serious progress Linux can make is with industry support. If you don't want great improvements on the desktop, towards enterprise class server solutions and "Big Iron" mainframes, or towards embedded/portable devices, then fine, Linux can continue without the industry. But for Linux to truly succeed on a large scale, it needs "the industry" to take it there.
----------
Wow, that's pretty bad, if there really is a correlation. I'll give it a shot... I don't really use Evolution [yet].
----------
-
To get the RPMs to install, I had to use --oldpackage with RPM to install both libghttp (as noted on their RH 7 install instructions) and also bonobo.
-
After installing, it started with some "first time" configuration stuff, then promptly crashed. Trying to restart it resulted in an error about having to reboot or re-installing. Rebooting worked.
-
Unfortunately, it insists on setting the desktop background color. Yay, just what we need, an Nth way to do this. Somehow, after launching Nautilus, trying to set the background with GNOME, Enlightenmnet, or even xsetroot fails. You have to go into one of the menus with pixmaps on it, select the "solid color" button to the left, and drag and drop it to your background.
-
While it definitely looks better than PR2, it is unfortunately so far a lot more unstable for me. (Red Hat 7, PIII 400Mhz, latest Ximian everything). It crashed on first time after install; now it is refusing to startup.
Your mileage will vary, but while I am excited with a new release, and it does look a lot better---maybe even faster than PR2---I am surprised at the stability problems I've seen so far. (3:1 ratio of crashes to successful runs? Rebooting to fix problems? I feel like I'm in Windows...) I didn't use PR2 super extensively, but it definitely didn't have these problems. Especially when I've heard GNOME 1.4 is due in February, and Nautilus is supposed to be the included file manager. I would hate to see GNOME's excellent stability (yes, in 2000, GNOME became very stable) tainted...And yes, I do plan to contribute by filing lots of bug reports...
----------
I'd tell you which menu, but right now it is completely refusing to startup.
----------
Was the StarOffice 5.2 source released without mods as the StarOffice 5.2 source, or was it only released after Sun mucked with it and labeled it "OpenOffice"? If StarOffice source was not officially released, I'm not sure how SuSE got it or licensed it.
----------
Suppose in two years StarOffice becomes THE standard office suite for Linux. Suppose some company adds some key proprietary pieces, which everyone comes to depend on, which initially are usable by everyone. Then one day, oops, it only works on distribution X, and you have to pay for it, and oh yeah, it's on a subscription service... All of a sudden 90% of Linux users get screwed. Even if you don't use it, you could end up screwed, because it could affect Linux's momentum in a major way.
Again, the more core a component is, the more important the GPL is. An office suite is not an "essential" component like the kernel, or something "optional" but pretty much essential like X/GNOME/KDE, but it's not exactly trivial either.
----------
Sounds to me like this is why the GPL is so important. I'm assuming (1) that this about OpenOffice, not just StarOffice, and (2) that the reason they can do this is because they are using the Sun Industry Standards Source License (SISSL) instead of the GPL. (OpenOffice is licensed under both GPL and SISSL, take your pick.)
If SISSL allows you to release such proprietary extensions, then it's a poor choice to allow OpenOffice to be licensed under it. While SuSE sounds like they will do The Right Thing and GPL their mods, what's to prevent someone else from not doing that in an attempt to privatize the whole thing? If OpenOffice is to become such a major project, it is very important for it to remain GPL.
This is similar to the old, ThankGodNoLongerRelevant GNOME/KDE license wars. The license under which core components for Linux are shipped is extremely important; it must be GPL, or else the whole system can breakdown if later on someone sneaks a major subsystem into proprietary land. While OpenOffice isn't as critical (license-wise) as the kernel, X, or GNOME/KDE, it has a shot at being the most popular office suite under Linux, and if the goal is try to keep it open source, it should have a truly open source license.
----------
After all, they invented web cookies.
----------
Of course, everyone's mileage will vary, but my experience is that you are just as likely to find good/bad contractors as good/bad employees. The good people are always hard to find, and I don't know that the odds are better for one or the other... I've had to hire full-time programmers and I got thrown so many loser resumes it wasn't even funny...
It sounds like your company needs better screening. Shouldn't screening a contractor be just as thorough as hiring a full-time employee? I.e. look at personality fit, sense of honesty, references, etc. I don't mean to knock your recruiters, but it seems odd that you'd have so many bad experiences.
----------
HTML, in theory, can still be the "universal" markup language, for all platforms, driven by PHP/JSP/ASP/Perl/whatever.
Even then, however, the fact remains that what you aim to present a user looking at an HTML page on their 17" monitor from home is different from what you want to present to a user on a cell phone with a 128x48 pixel screen. Clearly you need to display different things. In fact, what you need to display is so vastly different that it makes sense to code two completely different "pages" for each user, rather than a single one that will work under both, even with slight variations.
While in theory the actual technology to display one or the other doesn't have to change, e.g. HTML for both, in reality it also makes sense for it to change also, for similar reasons. HTML has evolved around needs surrounding display on your typical CRT, and those needs are going to be very different from those for smaller devices.
----------
And, I highly recommend galeon; it's a GNOME browser, built using Gtk, but using the Mozilla rendering engine of whatever Mozilla build you have installed. Much faster than running the full Mozilla, but with all the Mozilla standards support goodies.
----------
Yes, I'm sure there currently are, and always will be, standards compliance issues, but by the time AOL switches to Mozilla these will be for the most esoteric and cutting edge features, so for most sites, they will hopefully not be too bad. Even at this point, the latest Mozilla and IE support is supposed to be excellent.
Note that it's only AOL's use of Mozilla that will make Mozilla mean anything. Without AOL adopting Mozilla as its default browser, Mozilla will be relegated to the likes of Netscape, Opera and Lynx... no, I'm not bashing Lynx and Opera. It's just the truth that they will simply not be on any large commercial site's radar screens. They will not do anything to stop the tide of sites converting to IE only.
Some say that web access for other devices will help this situation, but I doubt it. The display needs and platforms for PDAs, cell phones, and whatever are so different that companies will code entirely different interfaces for those devices, instead of hoping that their HTML will work across all possible devices. This actually makes sense. Architecturally the "right thing" is to do the usual content/presentation separation, e.g. XML as the data stream and JSP/ASP/PHP for standard web display, WAP for wireless, etc.
----------
Nontheless, I highly recommend Win4Lin if you are running Windows 95/98. (Yes, I know the poster is using Windows 2000.) It is extremely fast and runs almost all non-game programs flawlessly (Outlook is probably the most notable exception, but Office, IE, and most stuff should be fine).
----------
Help?
----------
One thing that kept me skeptical about the whole thing was that I heard that the unicorn dream scene was taken from another movie (Legend, I think, which Scott also directed). This to me says that it really wasn't part of the original thinking of the movie (similar to adding the "happy ending", which is taken from, of all movies, The Shining), and that the whole thing was added to try to make the movie more interesting as a director's cut. In other words, it was a gimmick.
I guess you can argue you are then left with why Gaff left the unicorn, but I took that in and of itself to mean that Rachel had no termination date (unicorns being mythical creatures having to do with longevity).
----------
I guess I generally fail to see any real clue that he's a replicant. I don't see the unicorn as a clue, and fail to see others. Help? (Yes, I read the article, it still doesn't make sense.)
----------
All it does is start the text processor, or spreadsheet, or whatever, automatically within StarOffice, but it's no different from starting StarOffice and then opening a text document. I.e. if you then do the same thing for the spreadsheet, it opens up within the large MDI-type StarOffice window, not in a separate X window.
----------
There is a difference between static and dynamic content, vs. how static content is generated. For example, a basic web page that doesn't vary for anyone could be generated on the fly with XMLC/Cocoon, but it's still essentially static content. If the page shows the current time on each access, then it's dynamic, even if it's a simple PHP HTML template.
So, for basic content generation, I think XML to HTML is a great idea. XMLC is one solution. XSL is another. The problem with XMLC is that it only works at run time, which is a non-trivial performance hit. (Especially when you consider static content, that can no longer be served as a plain HTML file, and has to go through a servlet engine.) With XSL, and perhaps other technologies, the XML to HTML processing can be done at build time, resulting in HTML files that can be served faster.
The reason I mention JSP or PHP is because then you have to insert dynamic content into the resulting HTML, and at that point, you need JSP/PHP/whatever. But keep in mind that if you apply the content/logic separation with JSP/PHP clean, then making sure that your XML to HTML translation adds the right JSP tags is easy. So, you still maintain your content/logic separation throughout the whole process. And you get an additional performance boost over XMLC because you are simply outputting new strings, as opposed to manipulating a DOM tree, which is harder and slower.
Bottom line: XMLC combines static content generation with dynamic content generation. Both are slow, because (a) it happens at run time, and (b) DOM manipulation is slow. My suggestion is to move static content generation to build time, and use a simpler technology, like JSP, that gives you the same content/logic separation, to do the dynamic stuff. This still involves using XML to keep the distinction between logic and presentation nice and clean.
----------
I think something like XML/XSL at compile time, followed by JSP/PHP/whatever at runtime, works better, because you have the same content/design separation as XMLC, but not the performance implications.
BTW, even though you're speaking of WML in particular, I'm speaking of content serving in general.
----------
Ah, good idea. You're right about WAP devices, though, I also have no idea if they support client side scripting. I doubt they support JavaScript. In that case, it may be better to go with a server side solution, like the one mentioned above in reply to my question.
----------
A better approach is to statically do the base XML to HTML conversion, with JSP (or PHP, mod_perl, whatever) to introduce the final dynamic content. (I.e. convert the XML to a JSP with scriptlet tags for the true run time dynamic content.) Caching algorithms would alleviate this, but I don't see the advantage of doing it runtime, when it works just as well doing it statically. Even with caching, your performance will clearly be better.
----------
In either case, as the poster above said, the real point of XSL is that you don't have to be a full fledged programmer to use it. While XSL can definitely be painful, I think it is better than writing a computer program in {Perl,Java,Python,*} to do the same thing. Unfortunately, it's not easy enough for just anyone to pick up, so it doesn't completely allow for designers or HTML coders to assume all control of layout without an engineer showing them the ropes, unless of course they are particularly bright and can pick it up.
----------