Tim Bray is switching his development environment from OSX/Linux to Solaris. His diary of the switch is here (Note, as he does, that Mr. Bray is a Sun employee)
The most important difference for me is that Velocity is not tied to server side servlet processing. JSP templates cannot be used outside of a servlet container (they are in fact compiled into servlets at runtime) however Velocity templates can be used in any context. I personally have used Velocity to do source code generation and offline report generation.
Interesting that you put it that way. Berners-Lee's vision for "Intuitive Hypertext Editing" is very similar to wiki technology. However where wikis work by shoehorning editing into [rapidly aging] browser technology, TBL envisions a user agent that doesn't differentiate between browsing and editing. In other words, every page you view is editable by the user and changes are sent back to the server via PUT or POST.
There's a mozilla extension that moves in this direction but I can't quite pull it out of my brain at the moment...
Chunked encoding is usefull to me everyday. I use a protocol one level up from HTTP1.1 (AS2) where messages and their digests are transferred in the same request - in chunks.
As for supporting ranges, this is why agents are encouraged to delegate difficult MIME handling to helper apps like a Flash plugin. Plenty of servers implement this, it's actually not even that hard. There is a separate issue related to what a range response actually represents (in the theoretical sense), but I won't touch that for now. Read www-tag @W3C for more info.
Content negotiation works nicely. We serve French pages to agents that prefer French. We also serve unstyled xml to agents which we're sure are not browsers. It's not hard to do, we look at a header and then decide which representation to serve. Caches use the Vary header to choose which responses to serve from cache. It's not rocket science.
My favorite part: "HTTP needs to die quickly and be replaced by something sane"
I'm with you on the too many cooks point but spare XML. XML 1.0 is a nice, small refactoring of SGML done by a small group of intelligent people. It was designed with respect for the 80/20 rule.
On the other hand, many xml-related technologies (XML Schema, XQuery, XLink, XPointer . . with XSLT and XPath as notable exceptions IMO) are bloated junk designed by huge committees trying to be everything to everyone.
Queuing approaches have proven to be much more scalable in other areas - no reason to think it wouldn't work for web servers. Check out SEDA: An Architecture for Highly Concurrent Server Applications for a working implementation in Java that outperformed Apache [insert benchmark caveat here].
More on event-driven servers that minimize data copies and context-switching here.
exactly my point - it's not an impossible leap to get a useful amount of meta-data.
On the other hand, if i had to open a find file dialog, choose 3 meta-identifiers (date, document type, receiver), 3 relationships ( >, ==, ==), and 3 values ("7 days ago", "letter", "grandma@examle.com") just to open one file, well, that's just poor.
I think there is a certain amount of meta-data that can be derived automatically. For example, last-touched information can be very useful. Also, it may be reasonable to guess the type of document based on its format (this would be especially easy if a template were used). Then from the document type you could derive other, type-specific information. . . It would never be 100% accurate but even 80% might make it useful.
Just with what I described above you could get to "Show me the Letters I wrote to Grandma last week."
A separate issue is, how do you build a good UI for such a query. $ "SELECT FILE_NAME FROM USER_FILES WHERE LAST_UPDATE > SYSDATE - 7 AND TYPE = 'Letter' AND RECEIVER = 'grandma@example.com'" isn't really going do drive widespread adoption;-)
Fixed Font Size Style sheets unfortunately give websites the power to disable a Web browser's "change font size" button and specify a fixed font size. About 95% of the time, this fixed size is tiny, reducing readability significantly for most people over the age of 40. Respect the user's preferences and let them resize text as needed. Also, specify font sizes in relative terms -- not as an absolute number of pixels.
OK, this is not the fault of stylesheets. Internet Explorer does not allow the "zooming" of fonts set with pixel sizes. This is a shortcoming of Internet Explorer, not CSS. If this is so important to Nielsen (and I can see why it would be - my vision isn't so great either), perhaps he should look into using alternative browsers (Opera and Moz-based browsers all allow font zooming regardless of how the font size was set).
It is unimportant that any average Word doc can be exported to xml because the average Word doc does not carry semantic meta-information. It carries stuff like "make this line bold and indent it 4 pixels" That kind of info is pretty much useless unless you're Google and you spend your days writing algorithms that parse semantics out of display information. The best case scenario for legacy Word documents would be the ability to save as FO.
The key feature is "It seems Word can also edit arbitrary XML languages under the control of an XML Schema" This, coupled with IE5+'s "Web Folders" (really WebDAV) Means that I can point my users to a schema/stylesheet combination, let create a compliant XML document in WYSIWYG mode in Word and then save it directly to my webserver over HTTP. On the server-side, I do ACLs, Versioning, etc.
XML content creation has long been the missing link in CMS software. XMLSpy has been doing this for a while now but they're f'ed now because they never quite got it right and now the 500 lb. gorilla is about to sit on them.
I don't understand the "like those routinely released by the Apache Software Foundation" comment. Much of what is created by the Jakarta project is implementations of the very same "overly-complex" specifications that the author laments. httpd is an implementation of the more-complex-than-you-think HTTP 1.1 spec, and the Apache XML project has implementations of the DOM, SOAP, and SVG (very complex, pretty complex, and kinda complex, respectively)
Don't get me wrong, I love and appreciate what ASF has been doing, I just question how one can derride the specification while praising the implementation?!
I too usually surf with Javascript turned off (tip: add the Preferences toolbar to mozilla to be able to toggle js/java/cookies/etc. on and off quickly) but Javascript is gaining ground as a more general purpose language. See a recent article in Javaworld on using Netscape's free Rhino library to add javascriptability to your applications. Also, Javascript is how many XUL mini-apps are implemented.
Ask anyone with solid.NET experience and they'll tell you that Beta 2 of.NET was more mature then Java was when it was released. It is much more mature then you think.
I agree with you that many companies have become early.NET adopters but in the case of my company it was because of the old Microsoft BOGU (bend over, grease up). Microsoft is throwing millions of dollars at top companies in every industry (in our case, financial services), to use.NET. Free servers, load testing, MS developers on loan (not consultants mind you, but the same developers who wrote parts of the.NET framework), architects, free software, ANYTHING.
They want case studies and success stories and they're willing to drop millions to shorten the time to respectability for.NET
JAXP and Xerces do different things. JAXP is essentially a standard interface that can be used to decouple your parsing code from a particular parser implementation. Xerces is one such implementation (for DOM, SAX, etc.) which can be used underneath JAXP and therefore unseen by a developer. As such it can be used by JAXP but is never in competition with JAXP.
As far as I can remember, JAXP has little or no implementation code.
"Oh, you want XYZ feature? Let me run that through our scheduling metrics and I'll tell you tomorrow what the [additional cost|deadline shift|feature tradoff] will be."
Giving estimates on the spot as you hear of a new feature can be DEADLY.
Roy Fielding is chairman of the Apache group and a key contributor to the ideas that have become "the web" (e.g. HTTP, URI). His dissertation outlines the architecture of the web and why certain decisions (such as statelessness) were made. Note that it was written in 2000 so I'm sure it's a bit revisionist. At the same time, every theory has since been implemented so it's a high-level theory paper without any of the pie-in-the-sky crap.
HTTP 1.1 (possibly 1.0 - i don't remember) has a header fieled called "Vary". the contents of that header can tell caches that the content of the response will vary by certain request parameters, language encodings, etc.
wow, that is a lot of code. depending on your end-user needs, you may want to look at compressing the content on the server-side before sending it over the wire. Most modern browsers can handle compress and/or gzip content (check the HTTP Accept header).
It's more processing on the server side but you'll save bandwidth and the user-perceived performance will be better.
Slashdot Mirror
Tim Bray is switching his development environment from OSX/Linux to Solaris. His diary of the switch is here (Note, as he does, that Mr. Bray is a Sun employee)
The most important difference for me is that Velocity is not tied to server side servlet processing. JSP templates cannot be used outside of a servlet container (they are in fact compiled into servlets at runtime) however Velocity templates can be used in any context. I personally have used Velocity to do source code generation and offline report generation.
Interesting that you put it that way. Berners-Lee's vision for "Intuitive Hypertext Editing" is very similar to wiki technology. However where wikis work by shoehorning editing into [rapidly aging] browser technology, TBL envisions a user agent that doesn't differentiate between browsing and editing. In other words, every page you view is editable by the user and changes are sent back to the server via PUT or POST.
There's a mozilla extension that moves in this direction but I can't quite pull it out of my brain at the moment...
If you're interested in Open Source project management you might find some of these Mozilla lessons learned interesting.
What's next is waka. Really.
Troll city. I'll bite.
Chunked encoding is usefull to me everyday. I use a protocol one level up from HTTP1.1 (AS2) where messages and their digests are transferred in the same request - in chunks.
As for supporting ranges, this is why agents are encouraged to delegate difficult MIME handling to helper apps like a Flash plugin. Plenty of servers implement this, it's actually not even that hard. There is a separate issue related to what a range response actually represents (in the theoretical sense), but I won't touch that for now. Read www-tag @W3C for more info.
Content negotiation works nicely. We serve French pages to agents that prefer French. We also serve unstyled xml to agents which we're sure are not browsers. It's not hard to do, we look at a header and then decide which representation to serve. Caches use the Vary header to choose which responses to serve from cache. It's not rocket science.
My favorite part: "HTTP needs to die quickly and be replaced by something sane"
Yeah, it'll never catch on.
We couldn't get all these Open Source developers do do everything we wanted for free so we're going to take our ball and go home and play Techmo Bowl.
In any gecko browser (including chimera/camino), set the network.http.connect.timeout property to an integer (number of seconds). Default is 30.
You can access this property through the about:config url or add the line
user_pref("network.http.connect.timeout",999)
to your user.js file
I'm with you on the too many cooks point but spare XML. XML 1.0 is a nice, small refactoring of SGML done by a small group of intelligent people. It was designed with respect for the 80/20 rule.
On the other hand, many xml-related technologies (XML Schema, XQuery, XLink, XPointer . . with XSLT and XPath as notable exceptions IMO) are bloated junk designed by huge committees trying to be everything to everyone.
Queuing approaches have proven to be much more scalable in other areas - no reason to think it wouldn't work for web servers. Check out SEDA: An Architecture for Highly Concurrent Server Applications for a working implementation in Java that outperformed Apache [insert benchmark caveat here].
More on event-driven servers that minimize data copies and context-switching here.
exactly my point - it's not an impossible leap to get a useful amount of meta-data.
On the other hand, if i had to open a find file dialog, choose 3 meta-identifiers (date, document type, receiver), 3 relationships ( >, ==, ==), and 3 values ("7 days ago", "letter", "grandma@examle.com") just to open one file, well, that's just poor.
I think there is a certain amount of meta-data that can be derived automatically. For example, last-touched information can be very useful. Also, it may be reasonable to guess the type of document based on its format (this would be especially easy if a template were used). Then from the document type you could derive other, type-specific information. . . It would never be 100% accurate but even 80% might make it useful.
;-)
Just with what I described above you could get to "Show me the Letters I wrote to Grandma last week."
A separate issue is, how do you build a good UI for such a query. $ "SELECT FILE_NAME FROM USER_FILES WHERE LAST_UPDATE > SYSDATE - 7 AND TYPE = 'Letter' AND RECEIVER = 'grandma@example.com'" isn't really going do drive widespread adoption
OK, this is not the fault of stylesheets. Internet Explorer does not allow the "zooming" of fonts set with pixel sizes. This is a shortcoming of Internet Explorer, not CSS. If this is so important to Nielsen (and I can see why it would be - my vision isn't so great either), perhaps he should look into using alternative browsers (Opera and Moz-based browsers all allow font zooming regardless of how the font size was set).
I should learn to preview. That's http://www.webdav.org
The scenario gets even better as Subversion moves forward.
It is unimportant that any average Word doc can be exported to xml because the average Word doc does not carry semantic meta-information. It carries stuff like "make this line bold and indent it 4 pixels" That kind of info is pretty much useless unless you're Google and you spend your days writing algorithms that parse semantics out of display information. The best case scenario for legacy Word documents would be the ability to save as FO.
The key feature is "It seems Word can also edit arbitrary XML languages under the control of an XML Schema" This, coupled with IE5+'s "Web Folders" (really WebDAV) Means that I can point my users to a schema/stylesheet combination, let create a compliant XML document in WYSIWYG mode in Word and then save it directly to my webserver over HTTP. On the server-side, I do ACLs, Versioning, etc.
XML content creation has long been the missing link in CMS software. XMLSpy has been doing this for a while now but they're f'ed now because they never quite got it right and now the 500 lb. gorilla is about to sit on them.
I don't understand the "like those routinely released by the Apache Software Foundation" comment. Much of what is created by the Jakarta project is implementations of the very same "overly-complex" specifications that the author laments. httpd is an implementation of the more-complex-than-you-think HTTP 1.1 spec, and the Apache XML project has implementations of the DOM, SOAP, and SVG (very complex, pretty complex, and kinda complex, respectively)
Don't get me wrong, I love and appreciate what ASF has been doing, I just question how one can derride the specification while praising the implementation?!
I too usually surf with Javascript turned off (tip: add the Preferences toolbar to mozilla to be able to toggle js/java/cookies/etc. on and off quickly) but Javascript is gaining ground as a more general purpose language. See a recent article in Javaworld on using Netscape's free Rhino library to add javascriptability to your applications. Also, Javascript is how many XUL mini-apps are implemented.
They want case studies and success stories and they're willing to drop millions to shorten the time to respectability for
Also, don't rip off witticisms from such obvious places without giving credit.
JAXP and Xerces do different things. JAXP is essentially a standard interface that can be used to decouple your parsing code from a particular parser implementation. Xerces is one such implementation (for DOM, SAX, etc.) which can be used underneath JAXP and therefore unseen by a developer. As such it can be used by JAXP but is never in competition with JAXP.
As far as I can remember, JAXP has little or no implementation code.
Well said - I'd make one small change...
"Oh, you want XYZ feature? Let me run that through our scheduling metrics and I'll tell you tomorrow what the [additional cost|deadline shift|feature tradoff] will be."
Giving estimates on the spot as you hear of a new feature can be DEADLY.
Roy Fielding is chairman of the Apache group and a key contributor to the ideas that have become "the web" (e.g. HTTP, URI). His dissertation outlines the architecture of the web and why certain decisions (such as statelessness) were made. Note that it was written in 2000 so I'm sure it's a bit revisionist. At the same time, every theory has since been implemented so it's a high-level theory paper without any of the pie-in-the-sky crap.
p .h tm d ing_dissertation.pdf
html:
http://www.apache.org/~fielding/dissertation/to
pdf (1.3mb): http://www.apache.org/~fielding/dissertation/fiel
HTTP 1.1 (possibly 1.0 - i don't remember) has a header fieled called "Vary". the contents of that header can tell caches that the content of the response will vary by certain request parameters, language encodings, etc.
wow, that is a lot of code. depending on your end-user needs, you may want to look at compressing the content on the server-side before sending it over the wire. Most modern browsers can handle compress and/or gzip content (check the HTTP Accept header).
It's more processing on the server side but you'll save bandwidth and the user-perceived performance will be better.