If you want the plans for something it's not necessarily because you want to recreate it. Have you not seen Star Wars?
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
There should be a simple fix for the specific IE version issue. It's possible to run multiple IE browser engines on the same OS as there's an app that does this already (IETester).
It should be possible to create a piece of software - if one doesn't already exist - a web browser that is designed for enterprise use and allows the IT department to specify different browser engines for different sites.
That outdated internal application could be configured to use the IE6 engine - other newer applications and external websites could use newer IE engines or another engine entirely such as WebKit.
It could be rolled out by replacing 'iexplore.exe' and assuming the interface was very close to Internet Explorer it could even be transparent to users and thus very easy to roll out.
I think I agree with that. Google are probably worried that initial sales would be hampered by the preconceived notion that it would be used for major eyespam.
In my view these are both examples of the bad practice I mentioned in my post.
Your first example requires a continually maintained list of phone browser user agents. The second example, a list of search engine user agents. There are a vast number of devices and browsers and you're unlikely to stay on top of this list.
Creating a unique table row for every visitor to your site isn't the best application design for the reason you point out - a browser without cookies is going to add a new row with each access. My approach would be to generate a session key but store that in a cookie only, with session related data stored only as necessary (e.g. basket rows). Search engines are unlikely to POST so you won't get any basket rows from them (if you're adding to a basket via GET then you will have other issues).
I've been developing web applications full time since 1996 and I've never once had to resort to browser detection via user agent strings. It's just bad practice.
The fact that some people have been doing this has led to the very convoluted user agent strings we see today, rather than a simple description of the browser / rendering engine and version.
It's perfectly possible to write code that works cross-browser without having to detect browsers via user agent strings. The closest I've come to any sort of browser specific code is occasionally including IE specific CSS to work around IE bugs, but this included in an IE specific way and is ignored by other browsers.
A browser vendor should be able to put whatever they like in the user agent string, and if that breaks a web site or application, then so be it. It's the fault of the developer for making assumptions.
Link to Original Source
I think it was a joke.
This is free for home and business use also. The non-commercial restriction applies to the operators of the software, not the users of it.
Google docs on the other hand is completely closed source.
Do you really need 3D support for 3D product visualisation? Object rotation videos (like QTVR's Object VRs) have been around for ages. I company I used to work for was creating these back in 1998. It's a series of photos of the actual product, so you can rotate and see the product from different angles. A non-plugin JS version would be trivial to build.
Safari for iOS and Chrome for Android don't support browser plug-ins.
...which is a problem with the native code route. Java applets weren't a bad solution to this problem, but of some reason they fell out of favour. There were a lot of terrible applets, but there was nothing wrong with the technology in my view. 3D acceleration support via OpenGL / Direct3D is there.
I don't see why we would need pages of information to incorporate 3D elements. The only two uses I can think of are games and gimmicky UI / animations. The former would be better served via native code with a browser plugin (e.g. Unity3D) or a virtual machine (e.g. Java applets). The latter - gimmicky animations - we could probably do without.
A better use of 3D might be to use XML/HTML/HTTP type technologies to model virtual worlds that can be linked together in the same way we link pages together with anchors. We already had this with VRML and it didn't take off. It might have been ahead of its time, as bandwidth was much lower back then and hardware 3D acceleration was less common. I'm not convinced, though.
And for completion:
BSD/MIT: all derived works can be relicensed as proprietary
GPL: the whole of a derived work, even new components, must remain under the GPL
MPL: only the code files licensed under the MPL must remain under the MPL
That sounds promising. Unfortunately, at the moment we must still support Windows XP and IE8, but it is good to know that the situation will improve.