This comment will only be relevant if I guessed your intent from your problem definition.
When you say you are using Ajax to lighten your DB load, it implies might be using Ajax to request content from other servers than the source server your content comes from (cross-site scripting).
If that is the case, you can certainly expect your clients' antivirus systems to (rightfully) give you a headache.
You simply should not be doing that, and until something like http://json.org/JSONRequestJSONRequest (proposed for inclusion into ECMASCript core)is implemented in Ajax in an acceptable, core way, then you should stay far away from cross-site functionality. Go through a proxying solution to handle off-site content vian agents on your server.
Unless the American is actually hosting content itself, and is not instead the owner of a local legal person (company), then the American hoster probably falls out of the loop...
And as far as providing data to Americans goes, this is like buying cuban cigar...
If I were American, I do not think it would be illegal for me to smoke Cuban cigar while visiting Switzerland, where they are not illegal to smoke.
Even if I mail-ordered a cigar from an American-owned, Swiss-domiciled company which sent it to me, it would be me who carried responsibility and not the Swiss company which acted legally within the laws of its domicile.
The web page may be server *to* the US, but if it is being served FROM australia, then I propose that it is a Very Long Stretch to tell even an Americal Firm to stop publishing material in Australia and within the Australian DNS space, which may or may not be illegal in the US.
Even in current over-reaching times in the US, the re are many things not allowed in the US that are allowed elsewhere that are procured by Americans who intend to consume them in the US. Even if the provider were owned or operated by a US firm, the fact that they are delivering content in another country really only concerns Australia.
Even if a judgement were made agains a US owner of such a provider, so what?
I wonder if this has not already been hashed out with ISPs. I would expect the webhosting porn industry has worked this issue out long ago, whereby content there is deemed 'inappropriate' for certain countries (or states within those countries) yet is hosted none the less.
Usually, in law, the laws at the point of transaction are the ones that apply, and on the internet the transaction occurs on the server, not on the client...
Oh yeah, thanks for the grammar. Us ESL people get ahead of ourselves.
An american is threatening an Australian about an Australian server in Australia about what an Australian person who placed this Australian server?
Hmmm.
Someone reeeealy needs to explain to these people that the only way you can get your way in the world is by diplomacy or by force. And when you use force, well... we can all plainly see where *that* leads.
Some people in some more inwards-looking countries seem to forget that their cultures and their laws stop functioning at their border. Beyond these borders, one only get to choose between asking permission and acting 'all bully-like'.
And international bullying always seems to lead to expensive karma debts with unexpectedly high interest. One might even be tempted remind them that the road to happiness is through diplomacy.
The best reaction to this attack on the Gutenberg project seems to me to laugh hearrtily at the arrogance of some foreigner to Australia who doesn't seem to know enough geography to find the USA's borders.
I'm sorry. I seem to have offended you somehow enough to try to geek-bait me by questioning my technical credentials.:-) (ironic smugness)
As a software professional who's been coding since 1980 at the age of 12, and who's been programming professionally since 1993, I don't appreciate your flame attempt inter-mingled within your apparent attempt to have an intellingent conversation. if you want to check out someone's credentials, look them up on google and at perlmonks. I was probably programming when you were in diapers.:-)) (humour)
You mention cookie debugging as a clear benefit of Moz over older/other browsers. This is exactly the type of bloat I mean. In order to simplify a couple of developers' lives, we toss this code into the code base and force the entire client base to lug it around in memory evey time it's loaded? This is fundamentally flawed and a poster child for bloatware.
A web browser is for browsing http 1.0 and 1.1 protocol text strings and their content. It needs to support plugins in order to handle mimetypes it doesn't understand. There are a couple of cool standards that it helps it it supports like xml, xlink, and css. dtd's are a good idea to know about too. A few image processors will help. Say gif, jpeg, and png.
The browser that does this best, with the smallest code base and with the smalles ram footprint, is the best browser. Maybe speed is also an issue here but I'll ignore it for the sake of the discussion.
The rest of the functionality of the app has no place in the main code trunk and should be bundlable on demand or on compile time, but should not be forced down peoples' throats like MS bundles IE into Win.
If Moz followed this basic concept, then it might get a larger user base than under-25 males who happen to have a 2GHz box.
Pray tell, what is old hardware? 1 year old? 2? 5? Older than yours? I work on a 64-cpu x 400MHz Sun E10000 with 64G of ram. That's the biggest, fastest sun box there is. But that's a server, and it doesn't count. The desktop is a 600MHz thinkpad. And it's not 'old hardware'. But I resent having to dedicate 40M of ram to a web page rendering app that shows essentially the same content as in '95 at 20x the footprint cost. You'd think it was written in Java.
Of course you're right: "Mozilla does a hell of a lot more than NS4.7".
But how much of that hell of a lot is *useful*? And does it really take 40Mb to render a 1024 x 1280 screen at 16 bit colour depth? I'd really love to see a codebase usage plot based on my user behaviour just to see how much of Moz I actually ever invoke.
What Moz needs to be is a web browser with CSS, SLL, and scripting support. The IRC, mail, etc. functionality is chaff for a great many people. If you want to play with the bells and whistles, why not select that for loading on demand or something like that?
" if you think it's only cookies and popups you're either not a developer,..."
wrong. I think I know what I'm talking about.
".... or you've never actually used Mozilla"
wrong again. And I still know what I'm talking about.
You should check people out before you run your mouth like that.
". If you want this extra functionality, you have to have the hardware to run it"
I'm not sure what extra functionality you're talking about that Moz is offering. plugin support? yes it's important but not critical. I don't use anything in Moz that wasn't imperfectly (read buggy) implemented in NS4 or IE4. All that Moz has really done for me since NS4 is add standards compliance, css, and a tighter javascript support. The rest was already there that I can see.
The fact of the matter is that there is no choice but to upgrade versions of moz. Clearly, being the Esteemed Perl Developer that you are, you don't need to be reminded of the importance of keeping your browser up to date in order to minimize clientside exploits.
So no, I don't want to 'stay with my old NS4.7'. And yes, I think that the majority of the bells and whistles on Moz are useless. Moz is an html (and xml) rendering tool. It doesn't need to also make coffee. But even the Moz team have noticed that their code base is overly bloated and that they need to trim off the neat-but-barely-used chunks. That's what they're doing with firebird, isn't it?
That said, don't take my comments as slagging the Moz team in any way. The quality of the Moz 1 release is top, and I am very much looking forward to their (bloatware) implementation of native SVG. But I also think that it's time that they start listening to the low-horsepower people and stop growing the footprint.
What else do you upgrade at the same yearly cost as you upgrade your PC? Does your employer or client ask you to use the latest generation? Do you have a 19" flat screen at work? Do you re-paint your entire house every year? Change the furniture? Get a new degree?
Do you REALLY think that you should be REQUIRED to have a (say,) 2+GHz machine to effectively use a KDE desktop, as you seem to be implying?
Have you considered how many people are using 500MHz or less machines? All my machines are under 800MHz. I contract for big clients with lots of hardware, and I have never worked with a 1G+ box on the desktop.
Of course fast boxes are available everywhere. It's inevitable that the next laptop I buy will be in the 2-3GHz speed due to product offering. But very few professionals I see at my courses are using anything fast or interesting, and I only know 1 developer using a 1GHz+ laptop.
You should not need to replace your hardware annually.
To illustrate my point, here's another way to look at it:
Have you considered that the concept that a $2K machine needs to be updated yearly is essentially a tax? How loudly would you whine if your tax authority raised taxes by $200 per year (the probable pre-income-tax cost of your box per year) in exchange with providing you a new computer every year? Hey, they could even force software vendors to be universally compatible. Maybe I'm onto something here. Think of it as a basic service like schools... Would you find it acceptable, then, to require that machines be a bit slower, and only have to pay the tax premium every 2 years?
Right. Of course you would.
Ten years ago, SGI CAD/Animation boxes were the leading edge and gave superbe video graphics and quality on less than 200MHz or so CPU and 100Mb ram even though they had a much weaker graphics card than I have in my laptop now. So what happened? How is it that today, my 500MHz/300Mb Thinkpad is borderline able to render a Moz page that 10 years ago rendered superbly (and instantly) on that SGI box? When I ask myself what additional functionality the new tools have that the old tools didn't, I am blocked thinking of the MS Office paperclip, transparent icons and screens, and fun 3-d effects on my GUIs. Wow. What an improvement on my life.
Now, back to Moz... I totally agree that Moz suffers badly from bloat. In some ways it's understandable that it's so fat. It competes with IE, not Amaya or Konqueror.
Luckily, Firebird will (hopefully) take care of some of that. And until then, there's always KDE (although I admit I use Moz1.5b with SVG).
But until then, take it easy on the small-pc users. My favorite laptop is a TP240 ultra portable. At 266MHz, it suffers on advanced graphics tasks. That's really a shame because it has no 'value' but is invaluable to me, and I can't find anything 'better' (read more suited to my travel/usability needs).
The current mozilla build expects text/xml mime type for SVG rather than image/svg+xml . Because of this, you can only render SVG when it has the xml mime type.
Mozilla say it has put out a branch to deal with this by including a mime type synonym from image/svg+xml to text/xml: Mozilla SVG Samples:
News The mime-type issue (bug #160882) and a whole load of other things are now fixed in SVG_20020806_BRANCH builds.
foreignObject support is fixed for gtk2 builds on SVG_20020806_BRANCH
but I can't find it... My version of Mozilla (Mozilla 1.5b Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030720) does not appear to have bug #160882 (mime-type) taken care. I guess this is because it's not a branch build.
This problem comes from a long-standing argument between the w3c and mozilla. The plugin vendors (Corel and Adobe) have gone all practical on us and decided to use the generally accepted image/xvg+xml mime type as recommended by the W3C, but since nobody has bothered registering this mime type, this is actually an *INVALID* mimt type. This means that now developers (I am developing SVG apps on roasp.com ) have to support both mime types. This is a problem.
It seems that the mime type issue originates in the need of the browser plugins to have their own mime type in order to recognize plugin-handled content.
A serverside solution is to server SVG content dynamically and allow a mime=xml|[svg] parameter in my query strings, or some other similar kludgy workaround. Alternatively, if you know how, you can test for supported mimetypes. or for plugins.
Two important differences between Flash and SVG related to internet-based vector-generated applications
SVG-based systems can be delivered using server with programs written in any language. Currently, you can deliver SVG web applications from Linux, Solaris, and Windows using SVG.pm module, C#, php, python, ASP, and Java through the Apache Batik. There is more info on these on the SVG wiki. With Flash MX, you are currently limited to Windows servers. This means that you are forced to buy your entire server supply chain from monopolies. This is a Very Bad Thing.
SVG-based systems can be rendered by any internet-capable application. There are over a dozen independant rendering applications available free of charge, covering most operating systems.The Flash 6 viewer can only be downloaded for Windows, and is limited to desktop computers. It is fairly well known that the PC market is down and the bulk of growth on the web will be in portable applications (handhelds, phones, etc). In this market, there is *no* Flash player that I know of. This means that if you build a flash-based app for your windows visitors, you will need to spend that much money again building something for non-PC users.
There are more objective comparisons between SVG and Flash at carto.net.
Slashdot Mirror
This comment will only be relevant if I guessed your intent from your problem definition.
When you say you are using Ajax to lighten your DB load, it implies might be using Ajax to request content from other servers than the source server your content comes from (cross-site scripting).
If that is the case, you can certainly expect your clients' antivirus systems to (rightfully) give you a headache.
You simply should not be doing that, and until something like http://json.org/JSONRequestJSONRequest (proposed for inclusion into ECMASCript core)is implemented in Ajax in an acceptable, core way, then you should stay far away from cross-site functionality. Go through a proxying solution to handle off-site content vian agents on your server.
Good points.
Unless the American is actually hosting content itself, and is not instead the owner of a local legal person (company), then the American hoster probably falls out of the loop...
And as far as providing data to Americans goes, this is like buying cuban cigar...
If I were American, I do not think it would be illegal for me to smoke Cuban cigar while visiting Switzerland, where they are not illegal to smoke.
Even if I mail-ordered a cigar from an American-owned, Swiss-domiciled company which sent it to me, it would be me who carried responsibility and not the Swiss company which acted legally within the laws of its domicile.
The web page may be server *to* the US, but if it is being served FROM australia, then I propose that it is a Very Long Stretch to tell even an Americal Firm to stop publishing material in Australia and within the Australian DNS space, which may or may not be illegal in the US.
Even in current over-reaching times in the US, the re are many things not allowed in the US that are allowed elsewhere that are procured by Americans who intend to consume them in the US. Even if the provider were owned or operated by a US firm, the fact that they are delivering content in another country really only concerns Australia.
Even if a judgement were made agains a US owner of such a provider, so what?
I wonder if this has not already been hashed out with ISPs. I would expect the webhosting porn industry has worked this issue out long ago, whereby content there is deemed 'inappropriate' for certain countries (or states within those countries) yet is hosted none the less.
Usually, in law, the laws at the point of transaction are the ones that apply, and on the internet the transaction occurs on the server, not on the client...
Oh yeah, thanks for the grammar. Us ESL people get ahead of ourselves.
So, let me get it straight.
An american is threatening an Australian about an Australian server in Australia about what an Australian person who placed this Australian server?
Hmmm.
Someone reeeealy needs to explain to these people that the only way you can get your way in the world is by diplomacy or by force. And when you use force, well... we can all plainly see where *that* leads.
Some people in some more inwards-looking countries seem to forget that their cultures and their laws stop functioning at their border. Beyond these borders, one only get to choose between asking permission and acting 'all bully-like'.
And international bullying always seems to lead to expensive karma debts with unexpectedly high interest. One might even be tempted remind them that the road to happiness is through diplomacy.
The best reaction to this attack on the Gutenberg project seems to me to laugh hearrtily at the arrogance of some foreigner to Australia who doesn't seem to know enough geography to find the USA's borders.
Hackmare
I'm sorry. I seem to have offended you somehow enough to try to geek-bait me by questioning my technical credentials. :-) (ironic smugness)
:-)) (humour)
As a software professional who's been coding since 1980 at the age of 12, and who's been programming professionally since 1993, I don't appreciate your flame attempt inter-mingled within your apparent attempt to have an intellingent conversation. if you want to check out someone's credentials, look them up on google and at perlmonks. I was probably programming when you were in diapers.
You mention cookie debugging as a clear benefit of Moz over older/other browsers. This is exactly the type of bloat I mean. In order to simplify a couple of developers' lives, we toss this code into the code base and force the entire client base to lug it around in memory evey time it's loaded? This is fundamentally flawed and a poster child for bloatware.
A web browser is for browsing http 1.0 and 1.1 protocol text strings and their content. It needs to support plugins in order to handle mimetypes it doesn't understand. There are a couple of cool standards that it helps it it supports like xml, xlink, and css. dtd's are a good idea to know about too. A few image processors will help. Say gif, jpeg, and png.
The browser that does this best, with the smallest code base and with the smalles ram footprint, is the best browser. Maybe speed is also an issue here but I'll ignore it for the sake of the discussion.
The rest of the functionality of the app has no place in the main code trunk and should be bundlable on demand or on compile time, but should not be forced down peoples' throats like MS bundles IE into Win.
If Moz followed this basic concept, then it might get a larger user base than under-25 males who happen to have a 2GHz box.
Here we go again with the old hardware thing.
Pray tell, what is old hardware? 1 year old? 2? 5? Older than yours? I work on a 64-cpu x 400MHz Sun E10000 with 64G of ram. That's the biggest, fastest sun box there is. But that's a server, and it doesn't count. The desktop is a 600MHz thinkpad. And it's not 'old hardware'. But I resent having to dedicate 40M of ram to a web page rendering app that shows essentially the same content as in '95 at 20x the footprint cost. You'd think it was written in Java.
Of course you're right: "Mozilla does a hell of a lot more than NS4.7".
But how much of that hell of a lot is *useful*? And does it really take 40Mb to render a 1024 x 1280 screen at 16 bit colour depth? I'd really love to see a codebase usage plot based on my user behaviour just to see how much of Moz I actually ever invoke.
What Moz needs to be is a web browser with CSS, SLL, and scripting support. The IRC, mail, etc. functionality is chaff for a great many people. If you want to play with the bells and whistles, why not select that for loading on demand or something like that?
" if you think it's only cookies and popups you're either not a developer,..."
wrong. I think I know what I'm talking about.
".... or you've never actually used Mozilla"
wrong again. And I still know what I'm talking about.
You should check people out before you run your mouth like that.
". If you want this extra functionality, you have to have the hardware to run it"
I'm not sure what extra functionality you're talking about that Moz is offering. plugin support? yes it's important but not critical. I don't use anything in Moz that wasn't imperfectly (read buggy) implemented in NS4 or IE4. All that Moz has really done for me since NS4 is add standards compliance, css, and a tighter javascript support. The rest was already there that I can see.
The fact of the matter is that there is no choice but to upgrade versions of moz. Clearly, being the Esteemed Perl Developer that you are, you don't need to be reminded of the importance of keeping your browser up to date in order to minimize clientside exploits.
So no, I don't want to 'stay with my old NS4.7'. And yes, I think that the majority of the bells and whistles on Moz are useless. Moz is an html (and xml) rendering tool. It doesn't need to also make coffee. But even the Moz team have noticed that their code base is overly bloated and that they need to trim off the neat-but-barely-used chunks. That's what they're doing with firebird, isn't it?
That said, don't take my comments as slagging the Moz team in any way. The quality of the Moz 1 release is top, and I am very much looking forward to their (bloatware) implementation of native SVG. But I also think that it's time that they start listening to the low-horsepower people and stop growing the footprint.
Ronan.
And no, my vic 20's not that old either...
What else do you upgrade at the same yearly cost as you upgrade your PC? Does your employer or client ask you to use the latest generation? Do you have a 19" flat screen at work? Do you re-paint your entire house every year? Change the furniture? Get a new degree?
/300Mb Thinkpad is borderline able to render a Moz page that 10 years ago rendered superbly (and instantly) on that SGI box? When I ask myself what additional functionality the new tools have that the old tools didn't, I am blocked thinking of the MS Office paperclip, transparent icons and screens, and fun 3-d effects on my GUIs. Wow. What an improvement on my life.
Do you REALLY think that you should be REQUIRED to have a (say,) 2+GHz machine to effectively use a KDE desktop, as you seem to be implying?
Have you considered how many people are using 500MHz or less machines? All my machines are under 800MHz. I contract for big clients with lots of hardware, and I have never worked with a 1G+ box on the desktop.
Of course fast boxes are available everywhere. It's inevitable that the next laptop I buy will be in the 2-3GHz speed due to product offering. But very few professionals I see at my courses are using anything fast or interesting, and I only know 1 developer using a 1GHz+ laptop.
You should not need to replace your hardware annually.
To illustrate my point, here's another way to look at it:
Have you considered that the concept that a $2K machine needs to be updated yearly is essentially a tax? How loudly would you whine if your tax authority raised taxes by $200 per year (the probable pre-income-tax cost of your box per year) in exchange with providing you a new computer every year? Hey, they could even force software vendors to be universally compatible. Maybe I'm onto something here.
Think of it as a basic service like schools... Would you find it acceptable, then, to require that machines be a bit slower, and only have to pay the tax premium every 2 years?
Right. Of course you would.
Ten years ago, SGI CAD/Animation boxes were the leading edge and gave superbe video graphics and quality on less than 200MHz or so CPU and 100Mb ram even though they had a much weaker graphics card than I have in my laptop now. So what happened? How is it that today, my 500MHz
Now, back to Moz... I totally agree that Moz suffers badly from bloat. In some ways it's understandable that it's so fat. It competes with IE, not Amaya or Konqueror.
Luckily, Firebird will (hopefully) take care of some of that. And until then, there's always KDE (although I admit I use Moz1.5b with SVG).
But until then, take it easy on the small-pc users. My favorite laptop is a TP240 ultra portable. At 266MHz, it suffers on advanced graphics tasks. That's really a shame because it has no 'value' but is invaluable to me, and I can't find anything 'better' (read more suited to my travel/usability needs).
The current mozilla build expects text/xml mime type for SVG rather than image/svg+xml . Because of this, you can only render SVG when it has the xml mime type.
Mozilla say it has put out a branch to deal with this by including a mime type synonym from image/svg+xml to text/xml:
Mozilla SVG Samples:
News
The mime-type issue (bug #160882) and a whole load of other things are now fixed in SVG_20020806_BRANCH builds.
foreignObject support is fixed for gtk2 builds on SVG_20020806_BRANCH
but I can't find it... My version of Mozilla (Mozilla 1.5b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030720) does not appear to have bug #160882 (mime-type) taken care. I guess this is because it's not a branch build.
This problem comes from a long-standing argument between the w3c and mozilla. The plugin vendors (Corel and Adobe) have gone all practical on us and decided to use the generally accepted image/xvg+xml mime type as recommended by the W3C, but since nobody has bothered registering this mime type, this is actually an *INVALID* mimt type. This means that now developers (I am developing SVG apps on roasp.com ) have to support both mime types. This is a problem.
It seems that the mime type issue originates in the need of the browser plugins to have their own mime type in order to recognize plugin-handled content.
A serverside solution is to server SVG content dynamically and allow a mime=xml|[svg] parameter in my query strings, or some other similar kludgy workaround. Alternatively, if you know how, you can test for supported mimetypes. or for plugins.
None of these options is really palatable.
Ronan
Use SVG;
Serverside SVG Portal
Two important differences between Flash and SVG related to internet-based vector-generated applications
SVG-based systems can be delivered using server with programs written in any language. Currently, you can deliver SVG web applications from Linux, Solaris, and Windows using SVG.pm module, C#, php, python, ASP, and Java through the Apache Batik. There is more info on these on the SVG wiki.
With Flash MX, you are currently limited to Windows servers. This means that you are forced to buy your entire server supply chain from monopolies. This is a Very Bad Thing.
SVG-based systems can be rendered by any internet-capable application. There are over a dozen independant rendering applications available free of charge, covering most operating systems.The Flash 6 viewer can only be downloaded for Windows, and is limited to desktop computers. It is fairly well known that the PC market is down and the bulk of growth on the web will be in portable applications (handhelds, phones, etc). In this market, there is *no* Flash player that I know of. This means that if you build a flash-based app for your windows visitors, you will need to spend that much money again building something for non-PC users.
There are more objective comparisons between SVG and Flash at carto.net.
--Hackmare
Perl SVG.pm evangelist
http://www.roasp.com/