The Oracle Technology Network has a friendly article on PHP:
"Remember the heady days of HTML version 1.0 to version 2.0, when mastering a new Web language was as simple as looking at the code behind a Web site? Remember the ease of learning that came with basic HTML? Remember being able to hack out some code, quickly view the presentation as your wrote it, and if it didn't work, being able to easily change the HTML code? No IDEs, no Objects and Classes. Just a text editor, some tags, and your own cleverness. Talk about fast and cost-effective!
Those days may not be gone forever. That "keep-it-simple" spirit lives on in PHP, a Web scripting language that has surged in popularity over recent years."
And I'm quite proud of my OracleEditor currently being on top of the "Open Source Projects" list at the Oracle Open Source Developer Center :-)
Fri, 28 Nov 2003 14:06:39 +0000
Thu, 27 Nov 2003 09:05:51 +0000
Babeldoc seems to have a sound concept. Excerpts from their Whitepaper (PDF):
"Babeldoc is based around the concept of pipeline processing. Pipeline processing is where an input document is subjected to a linear succession of processing. The document is successively transformed into useful information. Examples of this might be to convert a purchase order document from a client in CSV (comma-separated value) format to a PDF document ready for printing. There are a number of standard processing pipeline stages available and it is a relatively simple programming exercise to add customized processing by developing new pipeline stages."
"The Babeldoc journal is centered around the concept of a ticket. This is analogous to the ticket you sometimes have to get when waiting in line for a service. All tickets are issued by the journal. This ticket then accompanies the document as it traverses the pipeline and its value remains constant. All operations on the document are logged against this ticket. In certain circumstances a document spawns one or more child documents (for example, a file of many purchase orders getting split into documents containing only one purchase order) at which point the ticket is said to fork. A forked ticket maintains a relationship to the parent ticket. This kind of relationship can be queried and is useful for complex pipelines."
Tue, 25 Nov 2003 12:00:55 +0000
SiteMesh sounds like a good idea (found this through PHP-Mesh):
"SiteMesh intercepts requests to any static or dynamically generated HTML page requested through the web-server, parses the page, obtains properties and data from the content and generates an appropriate final page with modifications to the original. This is based upon the well-known GangOfFour Decorator design pattern."
Mon, 24 Nov 2003 08:49:29 +0000
Andy Oram points to a fascinating Swedish court decision:
"Mrs Lindqvist also described the work done by her colleagues and their hobbies in mildly humorous terms. In several cases their family circumstances, their telephone number and other information were given. She also mentioned that one of her colleagues had injured her foot and was working part-time on medical grounds.
Mrs Lindqvist was fined SEK 4 000 (approximately EUR 450) for processing personal data by automatic means without notifying the Datainspektion (Swedish supervisory authority for the protection of electronically transmitted data) in writing, for transferring data to third countries without authorisation and for processing sensitive personal data (a foot injury and part time work on medical grounds)."
Thu, 20 Nov 2003 07:21:17 +0000
Thu, 20 Nov 2003 07:14:39 +0000
Thu, 13 Nov 2003 10:40:15 +0000
Jon Udell: "Point-to-point integration is out; event-driven communication across a common message bus is in. When you build a system this way, message queues are the first and best way to take the pulse of its real-time state."
Tue, 11 Nov 2003 10:31:01 +0000
Clay Shirky does a great job explaining why the Semantic Web is a myth:
"Descriptions of the Semantic Web exhibit an inversion of trivial and hard issues because the core goal does as well. The Semantic Web takes for granted that many important aspects of the world can be specified in an unambiguous and universally agreed-on fashion, then spends a great deal of time talking about the ideal XML formats for those descriptions. This puts the stress on the wrong part of the problem -- if the world were easy to describe, you could do it in Sanskrit."
Mon, 10 Nov 2003 23:42:15 +0000
What's the right way to design/structure a Web Service? These two articles show the limitations of SOAP:
Hao He explains why SOAP is not SOA.
And Paul Prescod promotes REST... "[REST] applies the principles of the Web to transaction-oriented services, rather than publishing-oriented sites. When we apply the strategy in the real world, we do so using web technologies such as URIs, HTTP, and XML. Unlike the current generation of web services technologies, however, we make those three technologies central rather than peripheral -- we rethink our web service interface in terms of URIs, HTTP, and XML. It is this rethinking that takes our web services beyond the capabilities of the first generation technologies based on Remote Procedure Call APIs like SOAP-RPC."
Thu, 06 Nov 2003 07:42:00 +0000
Mon, 03 Nov 2003 15:43:30 +0000
Adam Trachtenberg at ONLamp.com:
"Therefore, REST advocates claim, there's no need to layer the increasingly complicated SOAP specification on top of these fundamental tools. [...]
There may be some community support for this philosophy. While SOAP gets all the press, there are signs REST is the Web service that people actually use. Since Amazon.com has both SOAP and REST APIs, they're a great way to measure usage trends. Sure enough, at OSCon, Jeff Barr, Amazon.com's Web Services Evangelist, revealed that Amazon handles more REST than SOAP requests. I forgot the exact percentage, but Tim O'Reilly blogged this number as 85%! The number I do remember from Jeff's talk, however, is 6, as in "querying Amazon using REST is 6 times faster than with SOAP"."
Mon, 03 Nov 2003 07:54:01 +0000