I had reason to visit and download the latest version of the Eclipse WTP (Web tools Project). This has grown substantially during the last 12 months and there are some nice tools. One in particular is the Web Services Explorer, which provides the facility to view WSDL files and also invoke operations defined within the WSDL document. It automatically renders a form to accept user input and also presents the response in another pane. Very useful for testing deployed web services. Thanks Alex Boisvert for the tip.
I was able to use it to exercise the Work Manager service, which I am currently looking at again.
Now that I have a bit more time I am going to revisit the work manager application I wrote about 12 months ago. I did promise I was going to attempt to integrate it with some of the BPMS systems in particular the Intalio and ActiveBPEL offerings. I am particularly interested in Intalio’s recent acquisition of FiveSight and am curious to see how it all goes. In particular I am keen to test out their eclipse based BPMN designer, which generates BPEL code and runs on the PXE server.
A lot has happened in the 12 months since I last worked on this project so I will eventually need to port to hibernate3 and Maven but for the time being it will have to be hibernate2 and Ant running on a Jakarta Tomcat server v5.0.25.
I’m still missing a GUI to render work items and support human interaction with the work manager server. There are a heap of options these days from Tapestry to Echo, both support AJAX and both can be used to develop snazzy zero-admin style applications that run within a browser. I believe that Echo’s support for different browsers is superior to Tapestry’s. As you may imagine there is a lot of JavaScript behind Echo whereas Tapestry offers component based gui development, which can incorporate JavaScript and AJAX style interaction.
The work manager is a generic reusable service, one of the most fundamental when it comes to developing process oriented applications (POA).
We’ve worked with the National Maritime Museum in London for many years (who use our CMS, Amaxus). Over this time their web site has become incredibly successful, but now it’s time for a design refresh, which will start with a number of real user-testing sessions.
To complement this, we decided to record the exact position of any clicks on their homepage, to see if people’s click behaviour could tell us anything interesting about the current site. So one of our developers, Jon, used his lightning AJAX skills to quickly set-up the sending of a tiny XML message for every click on the page (that includes data such as: X, Y, user agent, text size setting, browser window size, etc.).
We then plotted this data using a variety of techniques (simple red crosses for clicks, grid-based heat maps, and Jon even made a lovely normal-distribution heat map). Many of the patterns we saw are not specific to the template, so I thought I’d share these with you.
First, a quick disclosure: all non IE-on-a-PC clicks have been removed (because other browsers render the page slightly differently), as have clicks from users that have non-default ‘text size’ (again, which causes the X/Y of clicks to be meaningless when combined together), and any users internal to the museum.
People click towards the middle (horizontally) of a link
As a consequence of Fitts’ law (perhaps?), there was a definite trend towards the centre of links.
A slight trend towards the bottom of links
As also demonstrated in the first image, there was a slight, if definite, trend for clicks to be slightly lower than the vertical centre of the link. Is this so that the user can still read the text of the link before clicking?
People click towards the left of text boxes…
OK, so I’ve extrapolated this result from a single text box, but it would seem to make sense. In English, we’re used to writing left-to-right, so do we perhaps try to position the cursor in the left of the available ’space’?
… and the bottom right of buttons?
This needs a much larger variety of tests, but from the single button on the page, the clicks were concentrated in the bottom right corner. It would also be interesting to test the difference between square buttons and rectangular buttons. Actually, Jon’s normal-distribution map shows this better:
Next steps…
We’re currently recording data from a few other sites, to get a better idea of generic patterns. If anyone out there can translate any of this into meaningful guidance for design, then let me know below! (For example, if people click towards the left of text boxes, should you not place links close to their left edge, in case of accidental clicks?)
Can we deduce anything useful from this? Let me know below…
It has become increasingly apparent as of late that several of the teams at Microsoft in which, by nature, tend to be criticized more often because they are exposed to a much broader/larger audience of folks, are beginning to change what we perceived, in the past, to simply be the Microsoft way. Because Internet Explorer represents a perfect example of this kind of extreme exposure, The IE team is an obvious candidate for just such criticism.
Of course the IE team at this stage of the game tends to lean more towards the IE7 team label. Closely knitted to the efforts of the IE7 team is the RSS team. While in previous years it hasn’t seemed like this was the case, things seem to be changing as of late, the result of which is showcased in particular by recent activity of the IE7/RSS teams in which have taken it upon themselves to proactively seek after such criticism, literally entering into areas such as the Atom and RSS syntax mailing lists, asking questions like (paraphrased) “What do we need to be doing to make things better for everyone involved?”
What could this mean?
Well, I’m guessing that out of a sampling of 100 people who read this post, a solid 10% will suggest that these efforts simply represent something that’s less obvious to the untrained eye, but evil none-the-less.
NOTE to these 10 folks:
“When did Slashdot let you out of your cage?”
Oh…. No reason. Just wondering. You’ve got some drool rollin’ — you know what, don’t worry about it… you look great! Really! I really do mean that.
[QUESTION-TO-THE-OTHER-90% : Is that drool, or is he just salivating while he thinks about wanting to eat me for lunch?]
Hmmm… Seems I’d best close this one out and — wait, “whats that… Oh… sorry, no, we don’t have any of those clever little icons we cut outta magazines and glued to the screen… You must feel lost, huh?
“Yeah…”
Poor things… they must feel like they’ve been lied to all this time, huh?!
Actually, I think they kind of have. That, or the MS recruiting folks are doing a bang-up job and bringing in folks who are less concerned with stock option value (or lack there-of as the case may be/is) and more concerned with being passionate about creating the next generation of Microsoft and the next generation of Microsoft Software.
I think its probably a bit of both.
But I’ll tell you what… Pop-on into the Atom-syntax archives (start here.) at some point and take a look at whats going on… Its really quite cool to see that Sean Lyndersay has taken it upon himself to proactively seek the questions, comments, and bug reports in regards to the Atom/RSS Data Feed support in the IE7 product. It’s this kind of proactive transparency that, when combined with the transparency that already has made itself known on the IE7 and RSS team blogs (and a whole bunch of other MS team blogs as well), is going to be the difference between a development community that believes that Microsoft could care less, and a development community who suddenly now realizes this is simply not (no longer?) the case, and reacts by providing valuable/usable feedback from folks who would otherwise not even bother.
The great thing about this is that the folks that I am referring to, the ones now providing feedback, that otherwise would not [UPDATE: Actually, that’s not true… these folks WOULD and DO help if and when they are asked… I just don’t think that MS has a history of asking. Suddenly, it seems this is no longer the case.], are folks like the Tim Bray’s, the Sam Ruby’s, the Uche Ogbuji’s, the James Snell’s, the … well, the list goes on with names just like this for several miles, if not more, something in which you can drop by and see for yourself. These are the folks who truly love building great software, and are passionate about every level of the process.
Seems like Sean, and the rest of the IE7/RSS folks are proving quite nicely that, in fact, they too love building great software.
What about the passion?
Seems to be there just the same.
These are all *GREAT* and *WONDEFUL* things that we are *ALL* are going to benefit from because of this.
Keep up the GREAT work IE7/RSS/Sean and all of the folks on Atom-syntax list who are proving that the thing that matters most is helping in the effort to ensure we don’t spend the next 10 years of our lives fixing all the mistakes we made in each of the years preceding the next because we simply refused to take into account all of the little, teenie, seemingly weenie things that, in fact, are just the opposite. Its rarely big things that cause problems in software, and instead LOT and LOTS of little things.
Details matter!
This stuff *REALLY, REALLY* matters.
And all of these folks who are putting for this effort are the ones that matter most.
Thanks everyone! Today, tomorrow, and for what seems to be be many, many years to come, these transparent efforts of MS, and the willingness of the Atom development community to simply help where the help is needed is going to result in a MUCH better world for all of us because of these efforts. These folks deserve a huge round of virtual applause from all of us for the efforts they are putting forth. And I mean that from both sides of the Atomic-structure-based fence (everything’s Atom-based, right? Yep, sure is. :)
Enjoy your AtomicRSS-enhanced Day! :)
[UPDATE: Regarding MS and asking for feedback. When it comes to their vast network of pro-MS developers, the history is quite a bit different. But the folks on the Atom list in particular tend to be more from the LAMP/Perl/Python/PHP/Ruby/Linux camps, and as such, this is more of the “history of not asking” I am referencing above.]
[ONE FINAL UPDATE: I don’t know how kosher this really is, but I also don’t think that highlighting the positive things that continue to take place in this space is a bad thing either. My apologies if this is the kind of thing that maybe should be left to be discovered by individuals on their own, but a recent post back from Sam Ruby to Sean Lyndersay’s latest post does such a great job of highlighting what I mean when I say these folks TRULY care about and are passionate at EVERY level of the software development process that starts with an idea, moves into various proof’s of concept, begins to develop a specification, a group of passionate folks come together and create a standards group for the development of this spec… etc… etc… etc… until they’ve reached the next level, which is taking the experiences of both the triumphs and the mistakes, and building better software using these experiences to then start at the beginning, and moving forward through the recursive/cyclical process all over again.
I can only think of about five folks who are in the same category/@ the same level as Sam Ruby when it comes to someone who simply deserves every ounce of credit and respect he is given, and in fact deserves more than that, but as is common among the elite at this level… its not about that. Its about the software and the process from start to finish of building that software to then support it, to then build better software, and so forth.
In and of itself, this is the reward, and what continues to drive the best and the brightest among all of us. (Like Sam)
Sean’s followed by Sam’s comments are below (archived post)
Sean Lyndersay wrote:
> Thanks James. I’ve filed bugs in our bug tracking database for each of
> the issues that came up in the feed validator (except for flagging
> /atom:*/ items, since these are a correct use of RSS 2.0 extension
> namespaces).
Re the flagging of atom: elements: this was indeed a bug in the Feed
Validator.
The Feed Validator was incorrectly flagging the use of atom:author
elements at the channel level and atom:link elements at the item level.
A test case has been expanded to include these elements, and these
problems have been corrected.
The fix should be deployed online in a matter of hours.
- Sam Ruby
The next few hours?
Ummmm…. WOW! Thats really cool :)
Transparency at its finest hour.
Ok Slashdot’rs… She’s all yours! Just give me like 10 seconds to get as far away from your nasty dragon breath, K… Gracia’s :D And will ya stop looking at the header!? They’re not going to magically appear!!!
There have been a number of interesting debates going on lately in quite a number of different areas that all have a certain thread running through them. A recent article asked whether PHP has taught too many bad habits and that it is slowly dying in its nest of bad code (and worse coders). The Java side seems to be facing the same existential angst - whether Java is in fact becoming an obsolete language, especially on the Web - and the arguments even range in areas as diverse as Perl, C#, Ruby and C++.
My suspicion here is that what is going on has less to do with the benefits of Java over Javascript (or vice versa) but has more to do with a deep level disquiet about the fact that maybe object oriented programming itself is changing in ways that challenge its initial tenets, that raises the possibility that maybe, just maybe OOP is not the ideal solution that it was deemed nearly thirty years ago. Admittedly, thirty years is a long time for any kind of technology to hold sway, so you could argue just as effectively that OOP has been extraordinarily effective over that time, which I agree with completely. However, these don’t make a duality. Rather, I think that both statements are true, and that we are only just now beginning to recognize this fact, much like finding oddly loose flooring raises the disturbing possibility that dry rot has set in underneath the support braces of your otherwise seemingly well-built house.
Object oriented programming began as the logical extension to the datatype that was pervasive in the procedural age. A datatype is a compound structure of either other datatypes or primitive types, or both. In certain languages, such as C, there is a fairly strong degree of correspondance between the most basic datatypes (integers, floating point numbers, characters, and so forth) and physical memory structures — an integer, for instance, would consist of between two and four bytes, and would have one representation for positive numbers and another for negative numbers (typically two’s complement notation) … this would correspond directly with the way that a machine represented the integer internally. Thus, while simple type was an abstraction, it didn’t abstract very far.
However, most data structures require more than one atomic type. A coordinate needs two, or perhaps three such types, along with some means of defining units. A string is a sequence of characters maintained in a linked sequence. An address or something more complex could in fact be made up of multiple levels of such simple types, bound together in a certain manner.
Data structures are purely declarative entities. You are declaring their existence, rather than assigning them intent. In a procedural world intent in turn is provided via functions defined within local libraries that accepted these data structures as inbound arguments, and returned other data structures as outbound arguments. A data type is the first level abstraction of a data structure, listing the associated component types but not specifically allocating values to those types.
The problem with this mode of operation is one of scaling. A linked library is a collection of individual “intents”, functions, that are grouped together by an overarching commonality - a graphics library, a file I/O library, a stack library, and so forth. This works reasonably well in certain domains … indeed, its what made such things as Windows 3.0 a reality, as that code was still procedural rather than objective, but that was probably about the largest (arguably larger than the largest) space that you could in fact use pure procedural code. Code management simply becomes too complex otherwise, and the possibility that two data structures or functions from different libraries would have the same name and signature but different functionality grew considerably, resulting in hideously long names and extremely complex parameter signatures.
The other problem with this approach (and the one perceived to be the problem to solve) was the fact that you needed to maintain a very comprehensive scope for data structures that persisted beyond an immediate functional need, and the likelihood of collisions of those variables reached a near certainty, especially if you had more than one team working in the application at any given time. The heart of polymorphism comes not in the fact that you can have multiple classes perform a similar operation in a common manner - it is that you can have multiple classes utilize the same name for potentially similar but not necessarily identical operations. This is a subtle but very important distinction, one that holds just as true within the namespaces of XML as it does in C++. Polymorphism allows for the reuse of names without having to resort on arbitrary (and often byzantine) naming conventions.
The next characteristic to arrive in the notion of an “object-centric” rather than “procedure-centric” approach is the concept of encapsulation. An “object” is a combination of an internal data model that has scope only within the object declaration and a collection of functions (now called methods) and properties that provide a means for the reading and manipulation of that internal state. Of course, that internal state may also have a direct connection to objects that provide “side-effects” to this state change, but from a programmatic standpoint these side-effects are in fact irrelevant - this object definition is an abstraction that hides the complexity of directly manipulating these side-effects.
One rule that I’ve observed over the years is a simple one - “Abstractions require energy, whether in the form of increased processing power, more memory (including hard drive storage), greater bandwidth or faster hardware capabilities. An abstraction will not be adopted until a minimum energy threshold is reached, at which point it will seem to coallesce ‘overnight’.”
This concept is an important one, and serves to highlight why computer technology seems to have definite periods of intensive innovation and activity followed by periods where there seems to be very little such innovation. The periods of intense innovation (one of which I believe we are in now) are brought about because the threshold has been reached to allow for a higher level of abstraction.
Notice that I’ve talked about polymorphism and encapsulation as being key components, but the one I haven’t addressed yet, and the one I think is most controversial, is that of inheritance. For many, many programmers, object oriented programming (OOP) is mainly about the principle of inheritance. I want to state here something that will likely get the dander of many people up - I think that inheritance is in fact a red herring.
Inheritance is one of those concepts that looks eminently good on paper - think about the code reuse you can get by creating a class from another class, adding one or two properties to those defined in the parent class and redefining the definition of one or two other methods or properties. This has been a selling point for OOP adoption to literally a generation of software developers, and in a small enough domain, it would seem to be a pretty good idea.
However, one immediate effect of inheritance is that it means that even the most mundane change to a class must result in the creation of another class, and the changes introduced into a given class close to the top of the inheritance tree intorduces the possibilities of changes to all descendent classes as well, creating a strong incentive to not change such core classes. This means that you must guess very early on about the interfaces that a given class closer to the root class must have in order to work more effectively with descendent classes. This is an extraordinarily difficult task, made even harder because programmers are not generally trained (or given the time) to create the best code, but rather to create code in the quickest fashion possible.
Because of these factors, such code frameworks periodically have to be written from the ground up, usually at tremendous costs in migration, in getting the updated libraries disseminated, and in time spent regaining currency in an API that a programmer had already invested considerable time and energy in learning. Occasionally the cruft accumulates so badly that it forces software developers to go off and write a new language altogether, one that has a different syntax so that its not quite so difficult to work with, but that in turn very quickly succumbs to the same faults that the previous language had.
However, its worth realizing that most languages may very significantly syntactically yet otherwise be similar enough that they can be mapped cleanly one to the other. Indeed, this is one of the principle tenets of Microsoft’s CLR, that it recognizes this basic fact and consequently makes it possible to create sanitized versions of languages that share the underlying structure. Admittedly, there are any number of languages that do not in fact correspond even remotely to the CLR model, but as these don’t tend to be well known to most developers (Ocaml, anyone?) the premise of a common runtime is seductive. Ultimately, however, I think it still misses the point - it attempts to impose a pure OOP bias upon all languages, even those that are “object-like” but that generally tend to utilize weak typing and minimize the role of inheritance.
The arbiters of programming fashion periodically deem that languages such as C++ represent the pinnacle of perfection and that languages such as the older style Visual Basic (before Microsoft got CLR religion with .NET), Python, Perl (gasp), or even Javascript (double gasp!) represent a debasement of true programming principles because they have OOP like characteristics but aren’t as rigourous in enforcing full encapsulation or even in supporting inheritance to the same degree. They are called “object-like” languages as a consequence.
Curiously enough, object-like languages tend to encourage the development of components rather than classes. This might seem like a recipe for anarchy, but curiously enough, such component based architecture seems, in many, many cases, to work better than the “pure” approach of building complex frameworks. Why? I think a part of the reason stems from the fact that such components are designed not to be inherited from. If you can transport the component libraries to your users, you don’t need a complete runtime for the entire class framework infrastructure. It separates out the need to have highly skilled OOP developers at all levels of the application, instead breaking the problem domain into highly skilled component developers and much lower skilled component integrators, and, so long as some consistency is provided in establishing presentation standards such components can be both more robust in the face of incoming datatype formats and more “skinnable” at the integration level.
Indeed, looked at in this light, component-centric languages exist at a higher level of abstraction than OOP languages do. Far from being throwbacks to a pre-OOP time, such component languages could only exist once computers reached a sufficient level of complexity to enable the jump from OOP to component systems.
The next obvious jump in abstraction is in the establishment of XML and the document object model. Indeed, I’ve often thought for some time that the document object model has been misnamed - it is more properly a document component model. People do not inherit a <P> paragraph object generally. Rather, that paragraph contains other content - text nodes, bold or italic containers, spans, etc. Inheritance in fact plays very little role here, while encapsulation is implied in HTML (and SGML) but made explicit within XHTML. and XML.
The XML abstraction has, curiously, seemed to shed much of the baggage of intent in its way to becoming the dominant mechanism for expressing data structures. The DOM mechanisms generally do not provide any intent within their semantics - they exist only to provide means of navigating and extracting elements from the data structure itself, without any preconceived notion about the meaning of that data structure. Certainly, XML schemas do have implicit semantics, and hence there do exist sets of operations that can be performed upon them that are semantic specific, but unlike with object-oriented code, the intent as expressed by such methods can be thought of more as an overlay upon the XML that can be switched with other overlays when the need for switching the intent changes.
The same thing holds true for the notion of type, which, as previously mentioned, is itself is an abstraction. The XML structure does not, in fact, have any explicit requirements upon it to represent type-valid content; this is radically different from most traditional OOP models where type emerges as an artifact of the need to maintain some correspondance with the physical hardware limitations of a given computer. In C++, a string is a class that contains a pointer to multiple characters of a specific character width connected via a linked list structure. In XML, a string is simply a label that will let the XML parsing mechanism determine what the best representation of that data needs to be. What’s more, the constraints and containership that a schema implies can be expressed in many different ways, from DTDs and XSD to RNG and Schematron, each of which can specify very different constraints. Thus, as with intent, type itself is an abstraction over an XML document that is imposed from without.
While XML is certainly the most self-evident of these “post-OOP” languages, it isn’t the only one. Dynamically typed languages, where the type is resolved based upon context, illustrates again this notion of the fluidity of type. They depend upon OOP typed systems, just as OOP depends in great part upon the notion of procedural code, but they represent an abstraction layer above that provided by such languages as C++ and Java. This in turn tends to push these latter languages further down the stack, away from the building of “workaday” applications and into the realm of constructing the more abstract languages. The higher abstraction languages are also, of course, more inefficient - any abstraction layer will decrease the immediate efficiency of execution, though usually this is more than counteracted by the flexibility that the abstraction layer provides in creating simpler, more manageable code. This is another restatement of the energy principle espoused above, by the way.
Thus the rush to “objectify” languages such as Perl and PHP has caused problems, because a move too far into the realm of pure-inheritance based OOP opens up the door to the full foundation class conundrums that languages such as C++ and Java now face. This is not to say that organizing content using encapsulation and method intent is a bad idea - there are times where it is preferable to maintain the intent with the data. However, taking this to the next step of requiring extensive inheritance models, especially in settings (such as web processing) where the need to maintain elaborate class structures is considerably lessened, usually ends up only adding to the overhead of development and places requirements that developers be considerably more skilled in their programming ability.
On the flipside, the distributed processing models that we are now heading towards means that state needs to be more fully managed upon the client. Here, again, though, such state management works more effectively in a component based environment, which can be seen as being a considerably simpler domain (and which, in general, tend toward being model/view/controller oriented). At the moment, in the AJAX space there is a rush to put out libraries of “helper functions” to perform specialized tasks, replicating in the main the procedural efforts from before OOP became established. I suspect that AJAX will probably not fully “stabilize” until you see a compelling set of components in this space, though good components that work well across the range of browsers currently out there are hard to come by.
The final piece of the puzzle comes in finding the balance that works best for developers. A significant number of web developers on both the client and server side (the domain where scripting and similar high abstraction languages express themselves most clearly) are surprisingly maladept at dealing with object-oriented code … they still employ the crudest form of code reuse - cutting and pasting content - generally have only marginal ideas about the value of the OOP paradigm, and utilize tools that keep the percieved space of development in a procedural model, even if the tools themselves may encapsulate this within a rudimentary OOP framework.
One expression of this is the current demand for good AJAX programmers. AJAX is not new - all of the pieces have been around for nearly half a decade, and while certainly specific aspects of AJAX programming can be a little more challenging (closures and asynchronous development, for instance) in an area where you might expect there to be a glut of Javascript programmers you have employers instead going begging. My suspicion is that this is true because most Javascript programmers use the language in a strictly procedural manner, and the component nature of DOM programming generally is at best only poorly understood by most of this “laity”, while more traditional Java and C++ programmers find the abstractions associated with working with the declarative environments so prevalent on the web confusing because they lack the framework that they’ve spent years mastering.
Recently there have been discussions about the increasing role of architects in the web sphere, but the more I look at it the more I’m convinced that the reason for such architects is not the need to be able to handle the construction process directly but because such architects naturally tend to gravitate to the realm of higher level abstraction necessary for dealing with heterogeneous, asynchronous, XML-based distributed applications. This points to another corrollary - each level of abstraction encompasses an order of magnitude more physical systems than the one before it. AJAX systems make relatively little sense within a bounded, single computer system, but make perfect sense in distributed systems involving dozens to thousands of operating systems, servers, and related nodes. Of course, this implies that the next level of abstraction involves the manipulation of entire networks, and consequently the evolution of virtual networks that exist for temporary purposes and then disappear - what I see as the “real Web 3.0″. There are signs that such are forming at rudimentary levels now, but as with the emergence of Web 2.0 tech, it is likely that we’ll go through a rocky period (purely as a guess, in about eight years) before that next level emerges with the requisite technologies to support it.
I hadn’t planned on this post being quite so long, but it points to some thinking that I’ve been noodling over for a while. I think that most of the discussions about language fitness ultimately are reflections over this same awareness that we’ve entered into a new domain, a new level of abstraction (indeed, perhaps this is a good working definition for what a “paradigm”, one of the most overused terms of the dot-com era, really is). I’m curious as to your thoughts on this.
Kurt Cagle is an author, software architect and systems theorist for Mercurial Communications. He lives in Victoria, British Columbia with his wife and two daughters.
There have been a number of interesting debates going on lately in quite a number of different areas that all have a certain thread running through them. A recent article asked whether PHP has taught too many bad habits and that it is slowly dying in its nest of bad code (and worse coders). The Java side seems to be facing the same existential angst - whether Java is in fact becoming an obsolete language, especially on the Web - and the arguments even range in areas as diverse as Perl, C#, Ruby and C++.
My suspicion here is that what is going on has less to do with the benefits of Java over Javascript (or vice versa) but has more to do with a deep level disquiet about the fact that maybe object oriented programming itself is changing in ways that challenge its initial tenets, that raises the possibility that maybe, just maybe OOP is not the ideal solution that it was deemed nearly thirty years ago. Admittedly, thirty years is a long time for any kind of technology to hold sway, so you could argue just as effectively that OOP has been extraordinarily effective over that time, which I agree with completely. However, these don’t make a duality. Rather, I think that both statements are true, and that we are only just now beginning to recognize this fact, much like finding oddly loose flooring raises the disturbing possibility that dry rot has set in underneath the support braces of your otherwise seemingly well-built house.
Object oriented programming began as the logical extension to the datatype that was pervasive in the procedural age. A datatype is a compound structure of either other datatypes or primitive types, or both. In certain languages, such as C, there is a fairly strong degree of correspondance between the most basic datatypes (integers, floating point numbers, characters, and so forth) and physical memory structures — an integer, for instance, would consist of between two and four bytes, and would have one representation for positive numbers and another for negative numbers (typically two’s complement notation) … this would correspond directly with the way that a machine represented the integer internally. Thus, while simple type was an abstraction, it didn’t abstract very far.
However, most data structures require more than one atomic type. A coordinate needs two, or perhaps three such types, along with some means of defining units. A string is a sequence of characters maintained in a linked sequence. An address or something more complex could in fact be made up of multiple levels of such simple types, bound together in a certain manner.
Data structures are purely declarative entities. You are declaring their existence, rather than assigning them intent. In a procedural world intent in turn is provided via functions defined within local libraries that accepted these data structures as inbound arguments, and returned other data structures as outbound arguments. A data type is the first level abstraction of a data structure, listing the associated component types but not specifically allocating values to those types.
The problem with this mode of operation is one of scaling. A linked library is a collection of individual “intents”, functions, that are grouped together by an overarching commonality - a graphics library, a file I/O library, a stack library, and so forth. This works reasonably well in certain domains … indeed, its what made such things as Windows 3.0 a reality, as that code was still procedural rather than objective, but that was probably about the largest (arguably larger than the largest) space that you could in fact use pure procedural code. Code management simply becomes too complex otherwise, and the possibility that two data structures or functions from different libraries would have the same name and signature but different functionality grew considerably, resulting in hideously long names and extremely complex parameter signatures.
The other problem with this approach (and the one perceived to be the problem to solve) was the fact that you needed to maintain a very comprehensive scope for data structures that persisted beyond an immediate functional need, and the likelihood of collisions of those variables reached a near certainty, especially if you had more than one team working in the application at any given time. The heart of polymorphism comes not in the fact that you can have multiple classes perform a similar operation in a common manner - it is that you can have multiple classes utilize the same name for potentially similar but not necessarily identical operations. This is a subtle but very important distinction, one that holds just as true within the namespaces of XML as it does in C++. Polymorphism allows for the reuse of names without having to resort on arbitrary (and often byzantine) naming conventions.
The next characteristic to arrive in the notion of an “object-centric” rather than “procedure-centric” approach is the concept of encapsulation. An “object” is a combination of an internal data model that has scope only within the object declaration and a collection of functions (now called methods) and properties that provide a means for the reading and manipulation of that internal state. Of course, that internal state may also have a direct connection to objects that provide “side-effects” to this state change, but from a programmatic standpoint these side-effects are in fact irrelevant - this object definition is an abstraction that hides the complexity of directly manipulating these side-effects.
One rule that I’ve observed over the years is a simple one - “Abstractions require energy, whether in the form of increased processing power, more memory (including hard drive storage), greater bandwidth or faster hardware capabilities. An abstraction will not be adopted until a minimum energy threshold is reached, at which point it will seem to coallesce ‘overnight’.”
This concept is an important one, and serves to highlight why computer technology seems to have definite periods of intensive innovation and activity followed by periods where there seems to be very little such innovation. The periods of intense innovation (one of which I believe we are in now) are brought about because the threshold has been reached to allow for a higher level of abstraction.
Notice that I’ve talked about polymorphism and encapsulation as being key components, but the one I haven’t addressed yet, and the one I think is most controversial, is that of inheritance. For many, many programmers, object oriented programming (OOP) is mainly about the principle of inheritance. I want to state here something that will likely get the dander of many people up - I think that inheritance is in fact a red herring.
Inheritance is one of those concepts that looks eminently good on paper - think about the code reuse you can get by creating a class from another class, adding one or two properties to those defined in the parent class and redefining the definition of one or two other methods or properties. This has been a selling point for OOP adoption to literally a generation of software developers, and in a small enough domain, it would seem to be a pretty good idea.
However, one immediate effect of inheritance is that it means that even the most mundane change to a class must result in the creation of another class, and the changes introduced into a given class close to the top of the inheritance tree intorduces the possibilities of changes to all descendent classes as well, creating a strong incentive to not change such core classes. This means that you must guess very early on about the interfaces that a given class closer to the root class must have in order to work more effectively with descendent classes. This is an extraordinarily difficult task, made even harder because programmers are not generally trained (or given the time) to create the best code, but rather to create code in the quickest fashion possible.
Because of these factors, such code frameworks periodically have to be written from the ground up, usually at tremendous costs in migration, in getting the updated libraries disseminated, and in time spent regaining currency in an API that a programmer had already invested considerable time and energy in learning. Occasionally the cruft accumulates so badly that it forces software developers to go off and write a new language altogether, one that has a different syntax so that its not quite so difficult to work with, but that in turn very quickly succumbs to the same faults that the previous language had.
However, its worth realizing that most languages may very significantly syntactically yet otherwise be similar enough that they can be mapped cleanly one to the other. Indeed, this is one of the principle tenets of Microsoft’s CLR, that it recognizes this basic fact and consequently makes it possible to create sanitized versions of languages that share the underlying structure. Admittedly, there are any number of languages that do not in fact correspond even remotely to the CLR model, but as these don’t tend to be well known to most developers (Ocaml, anyone?) the premise of a common runtime is seductive. Ultimately, however, I think it still misses the point - it attempts to impose a pure OOP bias upon all languages, even those that are “object-like” but that generally tend to utilize weak typing and minimize the role of inheritance.
The arbiters of programming fashion periodically deem that languages such as C++ represent the pinnacle of perfection and that languages such as the older style Visual Basic (before Microsoft got CLR religion with .NET), Python, Perl (gasp), or even Javascript (double gasp!) represent a debasement of true programming principles because they have OOP like characteristics but aren’t as rigourous in enforcing full encapsulation or even in supporting inheritance to the same degree. They are called “object-like” languages as a consequence.
Curiously enough, object-like languages tend to encourage the development of components rather than classes. This might seem like a recipe for anarchy, but curiously enough, such component based architecture seems, in many, many cases, to work better than the “pure” approach of building complex frameworks. Why? I think a part of the reason stems from the fact that such components are designed not to be inherited from. If you can transport the component libraries to your users, you don’t need a complete runtime for the entire class framework infrastructure. It separates out the need to have highly skilled OOP developers at all levels of the application, instead breaking the problem domain into highly skilled component developers and much lower skilled component integrators, and, so long as some consistency is provided in establishing presentation standards such components can be both more robust in the face of incoming datatype formats and more “skinnable” at the integration level.
Indeed, looked at in this light, component-centric languages exist at a higher level of abstraction than OOP languages do. Far from being throwbacks to a pre-OOP time, such component languages could only exist once computers reached a sufficient level of complexity to enable the jump from OOP to component systems.
The next obvious jump in abstraction is in the establishment of XML and the document object model. Indeed, I’ve often thought for some time that the document object model has been misnamed - it is more properly a document component model. People do not inherit a <P> paragraph object generally. Rather, that paragraph contains other content - text nodes, bold or italic containers, spans, etc. Inheritance in fact plays very little role here, while encapsulation is implied in HTML (and SGML) but made explicit within XHTML. and XML.
The XML abstraction has, curiously, seemed to shed much of the baggage of intent in its way to becoming the dominant mechanism for expressing data structures. The DOM mechanisms generally do not provide any intent within their semantics - they exist only to provide means of navigating and extracting elements from the data structure itself, without any preconceived notion about the meaning of that data structure. Certainly, XML schemas do have implicit semantics, and hence there do exist sets of operations that can be performed upon them that are semantic specific, but unlike with object-oriented code, the intent as expressed by such methods can be thought of more as an overlay upon the XML that can be switched with other overlays when the need for switching the intent changes.
The same thing holds true for the notion of type, which, as previously mentioned, is itself is an abstraction. The XML structure does not, in fact, have any explicit requirements upon it to represent type-valid content; this is radically different from most traditional OOP models where type emerges as an artifact of the need to maintain some correspondance with the physical hardware limitations of a given computer. In C++, a string is a class that contains a pointer to multiple characters of a specific character width connected via a linked list structure. In XML, a string is simply a label that will let the XML parsing mechanism determine what the best representation of that data needs to be. What’s more, the constraints and containership that a schema implies can be expressed in many different ways, from DTDs and XSD to RNG and Schematron, each of which can specify very different constraints. Thus, as with intent, type itself is an abstraction over an XML document that is imposed from without.
While XML is certainly the most self-evident of these “post-OOP” languages, it isn’t the only one. Dynamically typed languages, where the type is resolved based upon context, illustrates again this notion of the fluidity of type. They depend upon OOP typed systems, just as OOP depends in great part upon the notion of procedural code, but they represent an abstraction layer above that provided by such languages as C++ and Java. This in turn tends to push these latter languages further down the stack, away from the building of “workaday” applications and into the realm of constructing the more abstract languages. The higher abstraction languages are also, of course, more inefficient - any abstraction layer will decrease the immediate efficiency of execution, though usually this is more than counteracted by the flexibility that the abstraction layer provides in creating simpler, more manageable code. This is another restatement of the energy principle espoused above, by the way.
Thus the rush to “objectify” languages such as Perl and PHP has caused problems, because a move too far into the realm of pure-inheritance based OOP opens up the door to the full foundation class conundrums that languages such as C++ and Java now face. This is not to say that organizing content using encapsulation and method intent is a bad idea - there are times where it is preferable to maintain the intent with the data. However, taking this to the next step of requiring extensive inheritance models, especially in settings (such as web processing) where the need to maintain elaborate class structures is considerably lessened, usually ends up only adding to the overhead of development and places requirements that developers be considerably more skilled in their programming ability.
On the flipside, the distributed processing models that we are now heading towards means that state needs to be more fully managed upon the client. Here, again, though, such state management works more effectively in a component based environment, which can be seen as being a considerably simpler domain (and which, in general, tend toward being model/view/controller oriented). At the moment, in the AJAX space there is a rush to put out libraries of “helper functions” to perform specialized tasks, replicating in the main the procedural efforts from before OOP became established. I suspect that AJAX will probably not fully “stabilize” until you see a compelling set of components in this space, though good components that work well across the range of browsers currently out there are hard to come by.
The final piece of the puzzle comes in finding the balance that works best for developers. A significant number of web developers on both the client and server side (the domain where scripting and similar high abstraction languages express themselves most clearly) are surprisingly maladept at dealing with object-oriented code … they still employ the crudest form of code reuse - cutting and pasting content - generally have only marginal ideas about the value of the OOP paradigm, and utilize tools that keep the percieved space of development in a procedural model, even if the tools themselves may encapsulate this within a rudimentary OOP framework.
One expression of this is the current demand for good AJAX programmers. AJAX is not new - all of the pieces have been around for nearly half a decade, and while certainly specific aspects of AJAX programming can be a little more challenging (closures and asynchronous development, for instance) in an area where you might expect there to be a glut of Javascript programmers you have employers instead going begging. My suspicion is that this is true because most Javascript programmers use the language in a strictly procedural manner, and the component nature of DOM programming generally is at best only poorly understood by most of this “laity”, while more traditional Java and C++ programmers find the abstractions associated with working with the declarative environments so prevalent on the web confusing because they lack the framework that they’ve spent years mastering.
Recently there have been discussions about the increasing role of architects in the web sphere, but the more I look at it the more I’m convinced that the reason for such architects is not the need to be able to handle the construction process directly but because such architects naturally tend to gravitate to the realm of higher level abstraction necessary for dealing with heterogeneous, asynchronous, XML-based distributed applications. This points to another corrollary - each level of abstraction encompasses an order of magnitude more physical systems than the one before it. AJAX systems make relatively little sense within a bounded, single computer system, but make perfect sense in distributed systems involving dozens to thousands of operating systems, servers, and related nodes. Of course, this implies that the next level of abstraction involves the manipulation of entire networks, and consequently the evolution of virtual networks that exist for temporary purposes and then disappear - what I see as the “real Web 3.0″. There are signs that such are forming at rudimentary levels now, but as with the emergence of Web 2.0 tech, it is likely that we’ll go through a rocky period (purely as a guess, in about eight years) before that next level emerges with the requisite technologies to support it.
I hadn’t planned on this post being quite so long, but it points to some thinking that I’ve been noodling over for a while. I think that most of the discussions about language fitness ultimately are reflections over this same awareness that we’ve entered into a new domain, a new level of abstraction (indeed, perhaps this is a good working definition for what a “paradigm”, one of the most overused terms of the dot-com era, really is). I’m curious as to your thoughts on this.
Kurt Cagle is an author, software architect and systems theorist for Mercurial Communications. He lives in Victoria, British Columbia with his wife and two daughters.
What do you think about OOP and its place in web and application development?
Beware of marketing memes. Every so often, a company with either a very large ad budget or a very creative ad department will cobble together something that seems to catch fire as a way to sell their latest software product, shoe, or luxury sports utility vehicle. The technology field is, if anything, more susceptible than most in this regard, since the things being sold are often extraordinarily complex and difficult to describe except in terms of metaphor or marketing buzzwords.
The Web 2.0 Meme is a little different from the typical ad-agency inspired bit of doggerel. It started out more like a whisper, and a tentative one at that, by programmers dealing at the bleeding edge who began to realize that there has been a subtle but qualitative shift in the behavior of the web as critical standards, performance metrics and infrastructure changes have all fallen in place. Applications began to appear that seemed to take advantage of the dynamics of networked populations and that were defined as much by the intermixing of previously disparate concepts as upon any given business model.
As this notion has gained traction, there have been numerous definitions given as companies that have both caught this wave and the ones who are struggling to even articulate what the wave is in order to revive moribund product lines have each attempted toput their stamp onto it, to be seen as yet another Web 2.0 company and so attract venture capitalists who’ve been hoping to actually find an opportunity to make their money grow as well as it did in the heyday of the initial days of the web.
Most Web 2.0 companies that have emerged share a set of ten to twelve similar characteristics:
Mashups. Web 2 applications currently tend to be collisional in nature you throw two or more disparate technologies together and try to determine if there is in fact a market for the resulting product. This often utilizes existing web APIs from one or more disparate providers or applications (Google search information correlated with Google Maps in order to show clustering of behaviors, for information). (Another way of seeing this is that the application developers do not necessarily own all of the pieces of the application).
Extensive Use of Syndication. Syndication formats (RSS, Atom, etc.) act as a means for both synchronization and notification of services. As these syndication formats become more clearly defined, I expect that they will be used increasingly as the messaging substrate for disparate services, rather than just a syndication format for news readers, but such messaging systems generally are a string indicator of Web 2.0 membership..
Preferential Use of Open Standards and Open Source. Open and non-proprietary standards are preferred to closed, proprietary ones because they increase interoperability with other systems (not because of licensing issues). Web 2 applications do not have tobe on open source platforms, though this is where the dominant players are at the moment..
Diversity of Platforms. Web 2.0 applications use common frameworks or environments in order to work in a cross platform environment, and utilize intermediate modules that can be shifted between client and server transparently depending upon the richness of the application. Mobile device strategies are seen as a part of the overall application, rather than as a complete application in and of itself..
Asynchronous Messaging vs. Synchronous RPCS. Web 2 applications tend to utilize asynchronous messaging at multiple levels, rather than working with synchronous calls. This comes into play with AJAX (which stands for Asynchronous Javascript and XML) as well as distributed services on the server, and has the additional effect of moving the architecture from a client/server one to a distributed network..
Distributed Documentation/Data. One of the central characteristics of most web 2 applications is the distributed nature of the “user-owned” content data, images, documents, and preferences. This in turn places requirements upon two additional characteristics: Identity management and editability..
The Editable Web. Once Web 2.0 identity is determined, this opens up the potential for editability of distributed resources. In some cases, this involves the use of stand-alone applications that nonetheless have access to the Internet (at least sporadically). In other cases this is the incorporation of editing capabilities into browsers, a trend that seems to be accelerating.
Identity Management. Web 2.0 applications place an implicit requirement upon the need to maintain identity of participants across a network, in order to determine ownership, access rights, and editability characteristics. Because such applications are by their nature distributed, identity management moves beyond simple authentication and touches upon preferences management and personalization, as well as visibility of user assets to other users..
Social Networks. The distributed nature of Web 2.0 applications tend to make them ideal for “social” applications photo-sharing, blogging, podcasting, various and sundry link and reputation enabled systems, all of these are “social” in that they involvethe sharing and meta-tagging of resources among a group of people..
Metadata Rich. One of the more important aspects of the “media” content within web 2.0 apps is the fact that it usually has extensive metadata associated with it in a variety of forms, from RDF description files to embedded “tags” and micro-formats that provide a separate set of meanings or semantics on HTML code. .
Community. Community the collection of users, developers and evangelists of a given technology or product has long been a critical part of any software development effort. However, Web 2.0 companies (and projects) in particular are noted for their heavy reliance upon the community in order to both promote the products in question and to provide ancillary extensions, plug-ins or add-ons that enhance the capabilities of the core products. .
Rich Clients. While not all web 2.0 applications fit in this category, most tend to stretch the bounds of what web clients (browsers and related applications) can do, and are usually designed such that the client takes up a significant share of the state management, presentation generation and data processing. This in turn tends to relieve the server of having to maintain so much of this, simplifying server side code in the process.
My suspicion is that the particular term “Web 2.0″ will go out of vogue pretty quickly, but that a lot of the underlying concepts that inspired the term should be seen as hallmarks for this “new” web. However, like Groucho Marx’s comment about not wanting to be a member of any club that would have him as a member, definition of Web 2 applications all too often seem to be that they defy any categorization, so this list, like most out there, should be taken only as a guide.
Kurt Cagle is Director for Emerging Technologies and Training with Mercurial Communications in Victoria, British Columbia, and is the author of multiple books on Web technologies, XML, SVG and AJAX. He is also the Chairman of the SVG Open 2006 Conference.
So what do you think defines a Web 2.0 company, project, or technology?
Okay, I’ll have to admit, I’ve not been looking forward to writing this particular review - I find that after the fresh air of innovation that has been going on in the browser field over the last year that going back to Internet Explorer, even for just a brief look, is something that I’m loathe to do. However, my field right now is web development, and like it or not, IE will have a place in that field.
I was prepared to be as unbiased as I could, but even before starting it up, I’ve already found more than enough to get my juices flowing. I almost stopped when the IE install required that I confirm that I was running a legitimate copy of Windows XP, then, because I was running Firefox it ended up launching an HTA in order to load the requisite ActiveX control that checked my system. HTAs are web pages that run within the local security context, meaning that they can essentially go into your system and do anything. HTAs make me very nervous, precisely because they DO represent such a large potential security hole.
This feeling of invasiveness was only highlighted when IE required that I reboot my system in order to launch properly. Why does this bother me? Simple. You can run Firefox without needing to change the state of the underlying OS. You can run Opera without needing to change the state of the underlying OS. You run IE, and all of a sudden you’re back into the bad old days when a browser, an application, still ended up rewriting critical portions of Windows in order to run properly. Does this mean that I’m reintroducing instability into an environment that I’ve finally managed to stabilize enough to be manageable? You betcha. Am I happy about it? Not even remotely. Get a clue, guys, people don’t WANT super browsers that stick their tentacles deep into the operating system. Wasn’t this what .NET was supposed to give us?
Okay, once the system reboots (wait 10 minutes) I finally get a chance to click the new and improved icon and IE7 launches. The application shell launches fast - one of the downsides of Firefox is that it does rather take a while to launch, though there’s a fairly long pause while it loads and paints the browser window. Screen render time also seems to be faster than the Fox, though this isn’t that surprising.
A few thoughts about the interface - someone finally managed to get through to the designers that cluttered interfaces are bad. There’s no menu interface immediately visible (though a bit of searching finally revealed one hiding in the Tool section), and I think this is actually one of the better things about the browser. Overall the design is spare, and looks, not surprisingly, a lot like a just-out-of-the-box Firefox. A minor quibble on the forward and back buttons - they need to be a tad larger, as they present an uncomfortably small target for hitting.
That IE7 has added tabs is no longer a surprise - this was one of the key pieces of technology that has become so “standard” within Firefox and other browsers that had they not added tab support Microsoft would likely have had a revolt right then and there. While there’s a couple of nice pieces of functionality - the ability to do a preview of web pages for instance is particularly attractive, you don’t have the ability to change tab order, or (admittedly a wish list feature) move a tab from one window to another.
Microsoft has been paying attention to the notion of newsfeeds - among other IE7 has a button that becomes active when a web page contains one or more feed addresses - clicking on it will bring up a list of all of the available feeds, and will display these within an HTML page (and once displayed, let you add them into your favorites folder). Again, this is nice functionality to be adding, though its playing catch-up with at least a dozen such pieces within Firefox that are available as simple extensions. That they do include support for Atom 1.0 within their engine is particularly welcome, however, as it is a tacit endorsement that this spec is here for the long haul.
Search capability is the other piece added to IE, providing an integrated window for performing searches that mirrors almost exactly the search capability of Firefox. They do utilize the OpenSearch API, developed by Amazon partner A9, and it should be interesting to see whether this will prove to be a significant entry point for IE into the search venue (I’m encouraged by the fact that they are at least not trying to reinvent search protocols here).
What I find disappointing is what’s not here. You have support for Add-Ons, most of which appear to be ActiveX components (shudder). No doubt there is an extensive API for writing such add-ons, but so far the list of such add-ons is both rather sparse and singularly corporate in appearance (including all sorts of add-ons for sale, which admittedly may be a step in the right direction but is still rather discouraging to see). Will there be rich extension space that’s a feature now of Firefox (and personally one of its most valuable capabilities)? That’s hard to say. No doubt there will be an effort to offer such, but whether they will be the rich toolsets that seem to be populating the Fox space or Yet Another Search Toolbar remains to be seen.
Support for XML is likewise a rather disappointing mixed-bag. I was really hoping to have support for XHTML - it’s only been six years since the specification first saw the light of day, but at present all evidence seems to point to xhtml being treated as a foreign type to be handed off to someone else. SVG support? Hah! Yeah, right. We will all, of course, be writing XAML in the future, so why even worry about SVG. Except for the fact that the only people who are writing XAML code right now are writing Microsoft applications, not producing web pages. This means that VML will continue its long, painful twilight existence, being a standard solely through attrition, and we continue to play in the plugin space via Adobe or some other company. The XML rendering is a little prettier, there are a few minor tweaks to Javascript (XMLHttpRequest() no longer needs to be invoked as an ActixeX Object, for instance) but if that and pretty printing RSS feeds are the extent of Microsoft’s interest in XML, then I’m more than a little angry.
IE7 could have re-established itself as the dominant browser quite easily. Firefox is going through a rough patch right now, bumping up against some earlier architectural compromises, showing some embarassing security gaffes, watching as the early adopter wave is beginning to taper off. It’s vulnerable, albeit far less than IE6 is. IE7 could have been a contender. It’s not. It’s a nice little browser, continuing to promote the misguided Microsoft mantra that believes that once Avalon et alia REALLY get shown that people will abandon the web for Microsoft’s far prettier, more colorful version of the web. For Microsoft, IE7b2 is like being a batter in the bottom of the ninth inning, two guys out and one guy on. They needed a home run. Instead they got a bloop single. They could still score a home run, still take away the game by pushing beyond nice and into stellar (and secure and conformant) - but they’ve only got one more chance to get it right …
Kurt Cagle is Director for New Technologies and Training with Mercurial Communications in Victoria, British Columbia, and is the author of multiple books on Web technologies, XML, SVG and AJAX. He is also the Chairman of the SVG Open 2006 Conference.
What’s your take on IE7 - is it the browser for the future, or a desperate stop-gap?
I’ve been following the comments of Don Box and his discussion about Pragmatics, specifically:
Pragmatics
Someone recently asked me about how to handle an internal product debate around REST vs. SOAP.
In hopes I never have to address this debate again, here’s a record of what I told them.
The following design decisions are orthogonal, even though people often conflate two or more of them:
1. Whether one uses SOAP or POX (plain-old-XML).
2. Whether or not one publishes an XML schema for their formats.
3. Whether or not one generates static language bindings from an XML schema.
4. The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
5. Whether one adopts a message-centric design approach or a resource-centric design approach.
Some of the decisions (specifically 5) are architectural and sometimes philosophical.
Some of the decisions (specifically 1-2) are simple business decisions that are determined by who your target audience is.
I’m ambivalent about these, because I think there are implicit, unexamined assumptions here which color these either/or statements. A few comments:
···
SOAP vs. REST, not SOAP vs. POX. Let’s not overload the discussion with charged terms here.
···
REST folk (and not all REST folk are LAMP side) appreciate schemas as much as the SOAP crowd does. We just don’t confuse the issue by putting method semantics into them.
···
REST folk assume that type is implied by validation, rather than forcing XML into explicit code reification.
···
GET works fine if the assumption is that you are not changing server state by doing so. That’s been true since HTTP was standardized. Generally if you obey HTTP semantics, REST works just fine. If you don’t, caveat emptor. (On a similar note, if you ARE obeying HTTP semantics, you shouldn’t be sending XML via GET anyway).
The difference between a message-centric approach and a resource-centric approach is simply that in the first case you provide intent with the contents, while in the second you don’t (the intent is implied by the target). They both contain a formulation of state.
I think one of the things that I find a little frustrating in this debate is this fundamentally arrogant attitude that SOAP-oriented developers have that REST programmers are incompetents who utilize poor programming practices rather than using the “enlightened” approach of SOAP/WSDL, instead of being competent programmers who have looked carefully at both approaches and realized that while both have their place (and I will readily admit that they do) the REST approach actually offers significant larger-scale benefits over SOAP in the areas that are relevant to them.
Don continues:
1. If you want a great experience for .NET/Java devs, you’ll typically publish schemas (through wsdl) and support SOAP.
2. If you want a great experience for LAMP folks, you’ll support POX messages and will provide a non-XSD description of your formats.
3. If you want to reach both audiences, you’ll do both #1 and #2.
4. If you want to reach both audiences before your competition does, you’ll avoid indulging in religious debates and ship something.
I’d agree with #1.
I’d agree with #2, with the significant caveat that many REST people DO use XSD descriptions, not a few use Schematron or RelaxNG, and only a fool transmits XML that isn’t validatable, even if it isn’t validated. There is also a contingent of LAMP developers who are ardent SOAP/WSDL advocates, so be careful of generalizing.
I’d qualify #3 by saying, based upon discussions I’ve had with people at both Yahoo and Amazon, that SOAP tends to work best within a firewalled environment where you have stronger security contexts and can deal within internal servers as objective entities, while REST works far better outside of the firewall where you don’t have those security contexts in place. In essence, you will have different audiences for #1 and #2 and should recognize that in your design.
As to #4, know your customers before you ship, and recognize that they will do EVERYTHING in their power to game the system to their advantage, so make sure before you DO ship something that you’ve done your due dilligence to mitigate that abuse. Internal services do not need to be as robust, in general, because internal rogues can be countered more easily.
Finally, I think there’s a subtle point here (alluding to attitudes discussed earlier). While its easy to couch the arguments about approaches in religious terms (religious debates, evangelism, etc.), what is in question here is which approach is the best for the job at hand, not which approach is the more morally correct. This is an architectural decision, one based upon the needs and requirements of the customers, the competencies of the developers and the resources available to complete the job. If my requirements are to build an office building and the tools that you are offering are best suited to building cathedrals, I’d be hesitant to use those tools if ones that are more suited to office building construction are available.
SOAP and REST are not equivalent strategies, nor do they represent the “skilled” vs. the “unskilled” approach. Each has a specific domain where it has its strengths and should be used in that domain, just as each has its domain where it is weakest and should be carefully evaluated before being used in that other space. They are not even orthogonal - I think there are domains where you want to be able to offer both, where the two overlap, typically in those spaces where you are able to establish a “semi-trusted” perimeter. As application development moves into the realm of large-scale distributed applications where you likely do not own all of the nodes within the network, determining those boundaries and the appropriate tools will become one of the key differentiation points between the successful and the bankrupt.
Kurt Cagle is Director for New Technologies and Training with Mercurial Communications in Victoria, British Columbia, and is the author of multiple books on Web technologies, XML, SVG and AJAX. He is also the Chairman of the SVG Open 2006 Conference.
What about you? Would you buy Apple hardware that runs Windows? Would you feel at all betrayed if OS X development were just abandoned? Could any idea be more absurd?
At the moment there is a *VERY* slick product in Virtual PC for Macintosh in which enables you to run Windows on top of OS X via an x86 emulator. But this isn’t just Windows running in a separate memory space and instead Windows *VERY* well integrated into the Macintosh environment. (e.g. Drag & Drop, Copy/Paste, etc.. between environments, + quite a bit more).
There’s a problem however…
It’s SLLLLLLOOOOOOOOWWWWWWWWWW AAAAZz’…
Virtualization is one thing… Some pretty smart folks @ MS, VMWare, University of Cambridge (XEN), and elsewhere have found ways to virtualize several separate OS instances on the same machine with very little overhead and a very similar overall performance profile to that of only one OS instance on the same hardware.
But emulation?
That’s a *WHOLE* separate beast all2getha’.
But as already established, virtulization technologies that MS already owns can run several OS instances, no matter what they happen to be, on Intel architecture. I run virtual instances of Linux all the time on my WinXPPro DevBox, and while there is a little bit of slowdown, its nothing to get stressed over as its *barely* even noticeable.
So what’s keeping MS from revvin’ up the virtualization engine, and selling 10-20 million extra copies of Vista?
Well, at the moment, probably the fact that Vista hasn’t been released.
But, my guess anyway, is that this is pretty much about it.
A. This year, we made announcements in three areas. First, we continue focusing on improvements prioritized by our customers, specifically for Entourage 2004, which will include Sync Services integration, support for Spotlight search and enhanced Smart Card technology. These updates are the next step in our work with customers to provide deeper support of Mac platform technologies. Additionally, in March we’ll deliver an update to Messenger for Mac 5.0 that introduces encrypted file transfer and makes Messenger smarter about where to send a message if a user is logged in on more than one machine. We also outlined our plans at the show to build converters that will read the new Microsoft Office Open XML Format. Finally, we announced a new agreement with Apple. Our news overall emphasizes our dedication to building leading-edge products for the Mac platform.
“Ok. But is that it?”
Nope.
Q. Tell me more about the new agreement. What does this signify for your relationship with Apple?
A. We’re taking our already strong relationship to the next level by formalizing our commitment to develop Office for Mac for both PowerPC- and Intel-based Macs. We’ll keep working with Apple, just as we have for more than 20 years, to meet the needs of all Mac customers. The commitment agreement officially reinforces our existing plans.
“Hmmm… still need more.”
Okay.
Q. What else is on the horizon for the Mac BU?
A. As I’ve mentioned, we’re continuing to develop our core three products that Mac users depend on. We’ll keep supporting them and delivering new features and improvements.
Compatibility is a top customer concern, and the work that we are doing with the new XML file formats, layout engines and graphics handling will drive improved file compatibility. Customers know they’ll have more than the ability to open and share data, they know they can trust the data will appear the way it was intended.
Finally, we’ll keep working with Apple to identify new technologies that will benefit our customers. We’ll continue to collaborate closely with other Microsoft teams to develop new and creative ways to deliver answers to common productivity problems. The future is bright for the Mac BU, and we’re focused on bringing world-class productivity software to the Mac.
“Alright, this is all fine and dandy,” you say, “but this doesn’t provide anything other than speculation as to what it is MS and Apple might have going on behind the scenes. Where’s the meat?”
Q. I have an Intel-based Mac, and want to purchase Office 2004. Which version should I get?
A. Your best choices are the Standard version or the Student and Teacher version (if you meet the eligibility qualifications). Because the Professional version includes Virtual PC, and Virtual PC does not run on Intel-based Macs, you cannot take advantage of that extra value in the Professional version on an Intel-based Mac.
“So you mean folks that purchase a copy of Office 2004 Professional get a copy of Virtual PC for Mac to go with it already?”
Yep.
“Then that would mean that with the new Intel architecture coupled with existing MS-owned virtualization software, a new and improved version of Virtual PC for Mac could be re-bound and re-gagged to the new version of Office for Mac and, taking things even a bit further, could even become all but transparent to the Mac environment, in essence making the two operating systems…
“Oh my goodness…”
Yep.
“One.”
—
[UPDATE: Something similar to this scenario would certainly bring a little more sense to the recent announcement that MS would no longer provide a version of Windows Media Player for Macintosh. Why keep your resources in a project that is no longer necessary, and instead spend them on making a bright and shiny new version of Media Player for MacVista. [UPDATE.UPDATE: Don’t like the sound of MacVista? How ’bout OS:X.V (or OSXV or OS X.v or …)? Like it or not, at the current release rate of OS updates, somewhere between 2012 and 2014 they’re going to hit OS X version 9 (OS 10.9) and be forced to choose between OS XI or something alltogether new and sexy. Maybe its just me, but next to ‘X’, ‘V’ is about as sexy as you get in the Latin alphabet. I guess they could go with OS X.Next, which would be cool *AND* sexy and would kinda’ lend well to a bit of revenge on the part of Steve Jobs, but seeking revenge on the company you now once again dominate? Doesn’t really seem like his style, but then again I know about this >< much about Steve Jobs and Mac in general. So there ya’ have it. ;) ]]
Given that MS already distributes Virtual PC for Mac with Office Professional for Mac, it seems the only thing keeping current and future MacTel hardware owners who use Office Professional from also running Vista would be issues with licensing. So the question then is “will MS and Apple find a way to make the licensing issue a non-issue, distributing a Mac-enhanced version of Vista with the purchase of a license for the next version of Office Professional for Mac”? If they don’t “would you purchase a copy of Vista to gain, if nothing else, the extra benefits offered up by the 1000’s of extra peripheral hardware devices you can now run, that you couldn’t before?”
It’s been a little while since my last post, though not for lack of trying. I’ve been intending to write on the Northern Voice conference I attended last weekend, but after four attempts that have gone nowhere, I’ve rather given up. It was not that it wasn’t an interesting conference … it was, especially as it was one of the first conferences I’ve attended with my youngest daughter, Jennie (shown here podcasting away).
The sense I picked up at the conference though has left me somewhat depressed. In some respects I see in it the end of journalism as we know it, but then this has been something of a foregone conclusion for years. When you break down the barriers to entry by making it ridiculously easy to post content to the Internet, to format that content in as many different ways as you need and to present it in anything from a web page to a perfect bound hard-back book, big media’s days are numbered. New structures will, of course, take their place. Maybe one of these days I’ll articulate a little more clearly what exactly those new structures are. For now, I just want to get back to code.
SVG Conference
Before jumping into code full bore, however, I wanted to formally announce the SVG Open 2006 Conference in Victoria, British Columbia, to be held on August 22 through 25th, 2006. It’s purpose is simple - as with past years, the conference will promote Scalable Vector Graphics (and related “Open Graphics” standards), along with the community, product developers, map makers, theorists, and graphic artists that are now in this space. Because of the much greater visibility that SVG has had this year over last (especially within browsers, graphics chips, on the mobile market and so forth), I’m expecting this to be a major conference.
The website is still “drying” in places, and certan critical parts - call for papers, registration, sponsorship information and the like - will be posted over the next few days, but the site (at http://www.svgconference.com) is intended to be a clearinghouse not just for the conference but for people interested in SVG in general. Please check it out and sign up (the community, though not the conference, is free).
Scrolling Madness - Creating an SVG Component for Firefox
For some time, I’ve been thinking about being able to make use of SVG within Firefox to build user interfaces. It is one thing to talk about the fact that you can create compelling interfaces with XML-based vector graphics, but the reality is, unfortunately, a little more complex. SVG 1.1, as it exists right now, is a fairly low level API - it talks about shapes and paths and fills and similar things like that, and while it is possible to tie the various disparate pieces into something approaching utility, in point of fact, you need to have at least one, and potentially two levels of abstraction between this low level description and interactive web content.
One of the more maddening challenges in trying to demonstrate SVG is that most of the simple use cases that people deal with for interfaces - tables, lists, even tabs - can actually be accomplished with some basic Javascript code, XHTML and CSS … especially when dealing with components that flow consistently with the dominant flow of the web page that contain them (i.e., for most Western dialects, text that moves from left to write on the page). If you want your text to flow at an angle of forty five degrees, yeah, SVG’s your tool of choice, but frankly the number of compelling use cases for such a technology are at best very limited (maps being the most obvious exception). If you’re willing to play with moving transparent bitmap graphics in something like a scrollbar, then you can even fake such a scroll bar with XHTML+CSS, but the problem gets more complex when you want that scrollbar to resize or scale (and is impossible in cases where the scrollbar and correlative content are rotated) … for that, you need SVG … and a little bit of ingenuity.
What I ultimately set out to do was to create a tag, called <scroller> which would let you insert an SVG scrollbar into a web page. This element would let you specify such things as the minimum and maximum values, the current value, and whether the values within the component were discrete (integers) or continuous (floating point). It would also provide an onchange handler that could be applied to the scrollbar in order to read the current slider values. A simple sample web page (Firefox 1.5+ only) that displays this usage is shown in Listing 1, with the inactive and active states described by this shown in Figures 2 and 3 respectively. (You can also try this application by opening up the scroller.xhtml file - though it will only work with Firefox 1.5, Mozilla 1.8, or Seamonkey currently.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title/>
<style type="text/css"><![CDATA[
html {background-color:black;}
scroller {-moz-binding:url(svgComponents.xml#scroller);}
]]></style>
</head>
<body>
<scroller minimum="0" maximum="100" type="discrete"
value="100" id="scr1" onchange="
var bar = document.getElementById('posn');
var dataDisplay = document.getElementById('dataDisplay');
bar.textContent=this.value;
bar.style.width = this.value * 10 +'px';
dataDisplay.value = this.value;
"/>
<div id="posn" style="background-color:blue;border:outset 3px blue;color:white;"> </div>
<div>
<input type="text" id="dataDisplay"/>
<button onclick="
var scroller = document.getElementById('scr1');
var dataDisplay = document.getElementById('dataDisplay');
scroller.value =dataDisplay.value;
"
>Set Value</button>
</div>
</body>
</html>
The <scroller> element is fairly robust, and while I’ve included it in the XHTML namespace (for now), it should more properly be in its own namespace. Here, it utilizes
five attributes - minimum, maximum, value, type (discrete or continuous), and the onchange event handler, in order to set the initial conditions
for the scrollbar.
<scroller minimum="0" maximum="100" type="discrete"
value="100" id="scr1" onchange="
var bar = document.getElementById('posn');
var dataDisplay = document.getElementById('dataDisplay');
bar.textContent=this.value;
bar.style.width = this.value * 10 +'px';
dataDisplay.value = this.value;
"/>
Listing 4. The <scroller> element in detail.
The way that this is set up, the <scroller> element is assigned its functionality inside the <style> block:
<style type="text/css"><![CDATA[
html {background-color:black;}
scroller {-moz-binding:url(svgComponents.xml#scroller);}
]]></style>
employing the Mozilla -moz-binding property within CSS to associate it with a specific XBL file, in this case svgComponents.xml.While the binding mechanism is usually associated with XUL, it works perfectly well in the context of XHTML within the browser itself.
The binding is tied not just into the svgComponents.xml file, but also to a specific entry within this document, the <xbl:binding> element with an id of scroller. The svgComponents.xml file could potentially have a number of such components defined in this manner (and indeed if you have a number of related components it makes sense to place them all within a single binding as this file would then only need to be downloaded once). The formal listing for svgComponents.xml is shown in Listing 5.
<xbl:bindings
xmlns:xbl="http://www.mozilla.org/xbl"
xmlns:h="http://www.w3.org/1999/xhtml"
xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:s="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<xbl:binding id="scroller">
<xbl:content>
</xbl:content>
<xbl:implementation>
<xbl:constructor action=""><![CDATA[
// This is Javascript code invoked when the
// binding is first attached to the element.
paint();
]]></xbl:constructor>
<xbl:method name="paint">
<xbl:body><![CDATA[
var boundElement = this;
var scrNode = new XML((new XMLSerializer()).serializeToString(boundElement));
function iif(a,b,f){
if (a != null){
if (f != null){
var result = eval(f+"('"+a+"')");
}
else {
var result = a;
}
}
else {
var result = b;
}
return result;
};
var data = {minimum:iif(scrNode.@minimum,0,'parseFloat'),
maximum:iif(scrNode.@maximum,100,'parseFloat'),
type:iif(scrNode.@type,'discrete'),
onchange:iif(scrNode.@onchange,''),
updateInterval:iif(scrNode.@updateInterval,10,'parseInt'),
value:iif(scrNode.@value,0,'parseFloat')};
var http=new XMLHttpRequest();
http.open("GET","scroller.xml",true);
http.onload = function(){
var result = http.responseXML;
boundElement.appendChild(result.documentElement.cloneNode(true));
boundElement.scroller = new Scroller(boundElement,data);
}
http.send(null);
]]></xbl:body>
</xbl:method>
<xbl:property name="value">
<xbl:setter><![CDATA[
// This defines a setter for the property
// and assumes the rvalue parameter is contained
// in the default parameter "val"
var boundElement = this;
boundElement.setAttribute("value",val);
boundElement.scroller.setTo(val,true);
]]></xbl:setter>
<xbl:getter><![CDATA[
// This defines a getter for the property
var boundElement = this;
return boundElement.getAttribute("value");
]]></xbl:getter>
</xbl:property> -->
</xbl:implementation>
</xbl:binding>
</xbl:bindings>
Listing 4. The <scroller> element in detail.
The binding here is simple, and reflects a basic level of functionality only. It defines one method - paint() - which gets invoked from the constructor, as well as a property - value - which is used to manually set or retrieve the value of the scroll bar based upon its current position. There are a couple of interesting points to keep in mind with this. First of all is the (quiet) use of E4X in order to get an instance of the scroller node as an XML() object contained in the variable scrNode. The expression, scrNode.@minimum, is then a shortcut for scrNode.getAttribute(”minimum”). I’ve also defined a small helper function called iif() which simplifies the assignment of default values. The data hash loads the current values into a single data structure, before an AJAX call to the SVG file scroller.xml retrieves this file, inserts it into the bound <scroller> object, and finally creates a new Scroller() Javascript object that associates the this bound element and the data structure with this object.
One thing to note in this listing … I’ve deliberately gone out of my way to NOT specify any hard information about the underlying SVG object, beyond the fact that it requires the parametric values in data to set the value of the object. Put another way - the binding serves as a layer of abstraction between the XHTML and the SVG, such that, so long as certain key design (and programmatic interface) considerations were satisfied, you could effectively replace one SVG with another.
You might have noted the reference to the Scroller() class. This is an object that is in fact defined within the SVG file directly, and acts as the actual controller for the scroller component. The full listings for this file, scroller.xml, are given in Listing 5.
<s:svg width="400px" height="40px" viewBox="0 0 400 40" xmlns:s="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<s:defs>
<s:linearGradient id="bedGradient">
<s:stop stop-color="navy" offset="0"/>
<s:stop stop-color="black" offset="0.5"/>
<s:stop stop-color="blue" offset="1"/>
</s:linearGradient>
<s:radialGradient id="thumbGradientOff" gradientTransform="translate(0.05,-0.05)">
<s:stop stop-color="red" offset="0"/>
<s:stop stop-color="maroon" offset="1"/>
</s:radialGradient>
<s:radialGradient id="thumbGradientOn" gradientTransform="translate(0.05,-0.05)">
<s:stop stop-color="yellow" offset="0"/>
<s:stop stop-color="red" offset="0.75"/>
<s:stop stop-color="maroon" offset="1.2"/>
</s:radialGradient>
<s:g id="thumbGraphicOff">
<s:circle cx="23" cy="23" r="12" fill="black" opacity="0.3"/>
<s:circle cx="20" cy="20" r="12" stroke="black" fill="url(#thumbGradientOff)"/>
</s:g>
<s:g id="thumbGraphicOn">
<s:circle cx="23" cy="23" r="18" fill="black" opacity="0.3"/>
<s:circle cx="20" cy="20" r="18" stroke="black" fill="url(#thumbGradientOn)"/>
</s:g>
<s:g id="bedGraphic">
<s:rect x="0" y="0" width="400" height="40" fill="url(#bedGradient)"/>
<s:polyline points="0,40 0,0 400,0" fill="none" stroke="navy" stroke-width="3"/>
<s:polyline points="0,39 399,39 399,0" fill="none" stroke="lightBlue" stroke-width="3"/>
</s:g>
</s:defs>
<s:use xlink:href="#bedGraphic" x="0" y="0" id="bed" width="400"/>
<s:use xlink:href="#thumbGraphicOff" x="0" y="0" id="thumb" width="40"/>
<s:script type="text/javascript"><![CDATA[
function Scroller(bindingElement,scrollData){
var thumb = document.getElementById("thumb");
var bed = document.getElementById("bed");
var scroller = this;
this.thumb = thumb;
this.bed = bed;
this.isActive = false;
this.maxXVal = bed.width.baseVal.value - thumb.width.baseVal.value;
this.minXVal = 0;
thumb.addEventListener("mousedown",function(evt){scroller.start(evt)},true);
thumb.addEventListener("mousemove",function(evt){scroller.move(evt)},true);
bed.addEventListener("mousedown",function(evt){
scroller.start(evt);
scroller.moveTo(evt);
scroller.stop(evt);
},true);
thumb.addEventListener("mouseup",function(evt){scroller.stop(evt)},true);
this.start = function(evt){
scroller.isActive = true;
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOn");
position = {x:thumb.x.baseVal.value,y:thumb.y.baseVal.value};
scroller.delta = {x:evt.clientX - position.x , y:evt.clientY - position.y};
};
this.move = function(evt){
if (this.isActive){
mousePos = {x:evt.clientX,y:evt.clientY,toString:scroller.coordToString};
newPosition = {x:scroller.constrainX(mousePos.x - scroller.delta.x),
y:mousePos.y - scroller.delta.y,
toString:scroller.coordToString};
thumb.setAttribute("x",newPosition.x);
thumb.setAttribute("y",0);
scrollData.value = scrollData.minimum + (scrollData.maximum - scrollData.minimum) *
(newPosition.x - this.minXVal)/(this.maxXVal - this.minXVal); // Continued from previous line
if (scrollData.type == "discrete"){
bindingElement.setAttribute("value",Math.round(scrollData.value));
}
else {
bindingElement.setAttribute("value",scrollData.value);
}
bindingElement.onchange();
}
};
this.moveTo = function(evt){
if (this.isActive){
mousePos = {x:evt.clientX,y:evt.clientY,toString:scroller.coordToString};
newPosition = {x:scroller.constrainX(mousePos.x - (thumb.width.baseVal.value/2)),y:0, toString:scroller.coordToString};
var currentPosX = thumb.x.baseVal.value;
var posXArr = new Array();
for (var i=0;i<=10;i++){
var factor = i/10;
posXArr.push(parseInt(currentPosX + (newPosition.x - currentPosX)*(1-factor*factor)));
}
var key = window.setInterval(function(){
if (thumb.getAttributeNS("http://www.w3.org/1999/xlink","href")!= "#thumbGraphicOn"){
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOn");
}
var pos = posXArr.pop();
thumb.setAttribute("x",pos);
thumb.setAttribute("y",0);
scrollData.value = scrollData.minimum + (scrollData.maximum - scrollData.minimum) *
(pos - scroller.minXVal)/(scroller.maxXVal - scroller.minXVal); // Continued from previus line
if (scrollData.type == "discrete"){
bindingElement.setAttribute("value",Math.round(scrollData.value));
}
else {
bindingElement.setAttribute("value",scrollData.value);
}
bindingElement.onchange();
if (posXArr.length == 0){
window.clearInterval(key);
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOff");
}
},50);
}
};
this.setTo = function(val,noAnimFlag){
var transformedValue = scroller.minXVal + (thumb.width.baseVal.value)/2 + (val - scrollData.minimum)*
(scroller.maxXVal - scroller.minXVal)/(scrollData.maximum - scrollData.minimum); // Continued from previus line
var mousePos = {x:transformedValue,y:0,toString:scroller.coordToString};
newPosition = {x:scroller.constrainX(mousePos.x - (thumb.width.baseVal.value/2)),y:0, toString:scroller.coordToString};
var currentPosX = thumb.x.baseVal.value;
if (noAnimFlag){
thumb.setAttribute("x",newPosition.x);
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOff");
scroller.isActive =false;
bindingElement.onchange();
}
else {
var posXArr = new Array();
for (var i=0;i<=10;i++){
var factor = i/10;
posXArr.push(parseInt(currentPosX + (newPosition.x - currentPosX)*(1-factor*factor)));
}
var key = window.setInterval(function(){
if (thumb.getAttributeNS("http://www.w3.org/1999/xlink","href")!= "#thumbGraphicOn"){
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOn");
}
var pos = posXArr.pop();
thumb.setAttribute("x",pos);
thumb.setAttribute("y",0);
scrollData.value = scrollData.minimum + (scrollData.maximum - scrollData.minimum) *
(pos - scroller.minXVal)/(scroller.maxXVal - scroller.minXVal); // Continued from previous line
if (scrollData.type == "discrete"){
bindingElement.value = Math.round(scrollData.value);
}
else {
bindingElement.value = scrollData.value;
}
bindingElement.onchange();
if (posXArr.length == 0){
window.clearInterval(key);
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOff");
}
},50);
}
};
this.coordToString = function(){return "("+this.x+","+this.y+")";};
this.constrainX = function(x){
if (x<0){
var newX = 0;
}
else {
if (x>scroller.maxXVal){
var newX = scroller.maxXVal;
}
else {
var newX = x;
}
}
return newX;
}
this.stop = function(evt){
thumb.setAttributeNS("http://www.w3.org/1999/xlink","href","#thumbGraphicOff");
this.isActive = false;
}
// initialize;
this.setTo(scrollData.value);
}
]]></s:script>
</s:svg>
Listing 5. The scroller.xml SVG file contains the actual graphics generation.
The key to understanding Listing 5 is to recognize where the abstractions have been introduced. Like most programmatic SVG documents, the key items have been abstracted via <svg:use> elements, in this case,
The bed and thumb items in turn point back to #bedGraphic and #thumbGraphicOff. This is significant … so long as these items fit within the prescribed widths (400 and 40 user units respectively), These graphics can be ANYTHING that you want them to be. The component also defines a #thumbGraphicOn which is used when the thumb is moving or being moved. What this means in practice is that you could create multiple different SVG files, each of which use a similar controller and the same interface descriptions, and changing the user interface becomes as simple as switching the link being referred to.
This particular component has two major drawbacks. Currently, it is incumbent upon the user to specify the dimensions directly into the graphic itself, then propagate these back up the chain so that these dimensions are reflected in the XHTML file. There are ways around this (for instance, embedding the relevant templates as an XSLT file and passing this information parametrically), but the final version of this component (which I will also post once done with it) will incorporate these mechanisms. The second drawback is somewhat more problematic - currently because you have the referential structure in place and id elements in this component are visible within the broader XHTML scope (due to a known bug in the Mozilla code), you have the potential for multiple elements with the same id if you have more than one <scroller> element in place. There are ways around this as well, and the final version of this code will incorporate these in order to make the scroller component usable for multiple instances.
The Scroller() object itself also makes use of some advanced Javascript concepts, including the notion of closure in order to perform previously declared animations. For instance, in the setTo() method, the thumb actually transits between its previous and new location parametrically, with this information encoded in a dynamic array where the content is pushed on as it’s calculated, then popped asynchronously. Once this stack is empty, then the setInterval process is cleared. This little trick could, with a little bit of work, be used to provide the animation support that didn’t make it into Firefox 1.5.
This sample is a work in progress … I’ll be incorporating more extensive support for resizing and rebalancing of the limits when I repost this, quite possible as part of a more comprehensive Source Forge project. You are welcome to work with this (consider it to be under the GPL license), and I welcome comments and suggestions on both improvements to this component and ideas about other SVG based components that could be made available. As a recap, the relevant files are available as follows:
Kurt Cagle is Director for New Technologies and Training with Mercurial Communications in Victoria, British Columbia, and is the author of multiple books on Web technologies, XML, SVG and AJAX. He is also the Chairman of the SVG Open 2006 Conference.
What other components would you like to see discussed or developed within this venue?
My work life is organised with military precision; shared calendars, synchronised personal calendars, Gantt charts, and so on. But at home, I don’t even use a paper calendar. Which is why I’ve forgotten to go to gigs that I have tickets for, to put the garbage out, or to take the cats to the vet.
I shall stand for this no more! So it’s time to invest in some toys, just because it’s a good excuse. What I’m looking for is some kind of display that I can mount on a wall in my hallway, which is connected to a computer of sorts (Linux, Windows, OSX, I don’t care). This will be used to organise everything in my personal life; mainly calendar functions (entering repeat or one-off events), to-do lists, and more.
There are some ‘nice to haves’ too; ideally it should have internet connectivity (using the existing wireless network), and maybe the potential to hook it up to some kind of web-cam like device or telephony device, for VOIP or video messaging, etc.
It has to be ‘flat’ enough to not get easily knocked off the wall, robust enough to be able to continuously run day and night (maybe the display could re-awaken with movement in the webcam?), and have a simple input interface (ideally, a keyboard).
So, has anyone installed something similar? Any ideas for components? I’ve looked at touch-screen ‘all in one’ devices, wall-mountable TFTs, Mac minis, wireless keyboards. And all I’ve managed to do is confuse myself. Any suggestions for what to use (or not to use) gratefully accepted!
In what was meant as an innocent ’shout out’ to Sylvain (turns out both of us are *BIG* ‘Queens of the Stone Age’ fans) it seems that I may have invoked a spell upon Kurt, and now theres *ALL HELL* to pay!
I didn’t mean to do it. But the Devil, err, I mean Kurt, made me!
Confused?
What? ‘We’re Not Eveel!’ what are you talking about?!!!
“M.!”
Yes Satan, err, I mean Kurt, err, I mean… ah hell, What?!
“Get to the point!”
Oh. Okay then… Apparently the ‘Eveel One’ is growing a bit impatient… So here’s the deal:
* Join me, qotsa, and a combination of some ‘old school for the new fool’ and ’some new school for the old fool’ White Stripes as we exclaim “Get Behind Me Satan!” while we attempt to “Free Kurt Cagle!” from the grips of the ‘Eveel UnderLord’!
* That, or join Kurt and I as we attempt to tackle the topic ‘Can Google Really Beat Microsoft?’
(Same task, different approach? ;))
Are you in?
[Sign, err, I mean, uh, click here please > Episode #4 : MP3 Format : WMA Format]
In a recent response to a post made to XSL-List regarding the Sarissa project, an OSS cross-browser scripting utility many of us have come to rely on for a multitude of browsed-based XML processing and rendering tasks, as well as bringing a common wrapper-based API to the various implementations of Microsoft’s XMLHTTP data request object, Emmanouil Batsis (Manos), the Sarissa project developer writes:
Currently i’ve fixed a number of Safari and Opera bugs and investigating XSLT support for Opera 9.
BTW i’m also trying to gather interest and a bounty for DOM L3 XPath support in Safari here [see below]. Any help appreciated :-)
Thanks Manos! I think its safe to state we are *ALL* Looking forward to your next release :)
If you would like to have Manos contact you directly, please leave a quick comment with your prefered method of contact. I will notify Manos to keep an eye out on this post for any and all parties interested. Thanks!
I am not one of those high priced media consultants that seems to have their finger on the pulse of “The New Media” … I have to admit that while it’d be nice (when I look at my current bank account, it’d be REAL nice about now) but I also think that I’d have some problems with living with myself the next morning if I did take such a position, primarily because I suspect that a significant deal of my time would be spent lying to people about “how great the upcoming New Wave of MEDIA is really going to be!!!!” That’s a four exclamation statement … something they teach you in media school, I suspect. It usually means not only that you’re lying through your teeth, your clients know you’re lying through your teeth, and both of you nonetheless are clinging desperately to the lie because the truth is so much more terrifying.
I do not know what the future is going to bring. All I can do is to extrapolate based upon the experiences the I and others have had, taking into account the fact that periodically the world changes in unanticipatible ways. It is the fundamental flaw of Azimov’s psycho-history - there’s always a damn butterfly floating around when you’re least expecting it, spreading chaos into the mix just about the time that you think you’ve got everything nailed down. Thus it is with blogging and the future of (the) Media.
Most people, when they talk about Media with a capital M have this preconception drilled in by a hundred years or so of experience, first of newspapers, then of radio and television. Moreover, this hypothetical Media is far more concerned with the dissemination of news, to the extent that news media would be an oxymoron if it weren’t for the fact that so much of what passes as news is entertainment instead. However, it is worth stepping back and looking at the initial meaning of the word: media is, of course, short for media of communication. The media are the modalities of expression for communication - the aether by which one person can talk to another. Of course, by this definition, the telephone is media, as are more contemporary forms such as chat systems, VOIP, and email, not to mention web pages. What differentiates these latter forms is generally a matter of scope. For instance,
email is “typically” a person-to-person communication system, unless of course that email is informing you of being awarded the European Lottery, but you need to provide your bank account for the funds transfer…;
web pages, while clearly broadcast, are perceived as being primarily static, though a portal is often more dynamic than all but a handful of daily newspaper
telephony of course isn’t media- its a voice system that implies immediacy of communication, unless … hmmm… one side happens to be a machine running an automated voiceML system coupled with voice recognition, (of course, if both sides are running such a system, then you begin to get such philosophical questions as “if two voice mail systems are talking to one another, is a conversation actually happening?)
chat systems and IRC hardly fit into the notion of Media at all, until you realize that if you spend any time at all on Yahoo or MSN or AOL chat, you’re far more likely to end up talking to a girl named Candy who might not be real bright but does happen to have a website showing her doing her favorite things with kumquats for only $4.95 per month.
In other words, the traditional notion of these “small m” media as being simply peer-to-peer communication really doesn’t stand up to heavy scrutiny.
So lets try something different - perhaps the distinction between these traditional Media and the new ones on the block have to do with the devices involved for presenting that media. Newspapers and magazines of course have a monopoly on paper, but with electronic paper coming to a store-front near you within the next couple of years (eInk and Sony are doing some very interesting things in this space right now - more momentarily), its likely that this distinction is close to being washed out.
This is not in fact a trivial distinction, by the way. A press is a large and costly piece of equipment, running from several tens of thousands to a couple of million dollars per press, utilizing tens of millions of tons of paper a year, with its product sent via trucks, planes and ships, typically nourishing the mail systems of countries along the way. On the other hand, with electronic paper, I can create a PDF (or better, a formatted XHTML page with SVG graphics), establish a link to it, send a small bit of XML to notify you that I’ve just “published” it, and within seconds you can be looking at exactly the same formatted content on a fairly inexpensive “plastic” page at practically no cost to me, beyond the cost that I and the vendor choose to agree upon as important for the value of that content.
This in turn points to a more disturbing realization - the Media, as it exists today, consists of companies that have managed to create a vast infrastructure with a high barrier to entry that utilizes hideous amounts of minimally replaceable resources in order to move physical representations of information to your table every morning. Television and radio are perhaps less inefficient, but they still require the powering of massive transmitters and use the scarcity of resource (electromagnetic bandwidth) in order to control access to the channels of distribution.
The creation of Media content is, surprisingly, not that expensive a part of the overall process in nearly any media. A typical starting reporter makes a salary that’s usually not going to make even the most penny-pinching of employers lose a lot of sleep. Certain personalities can command a fairly significant sum of money for a column or newscast, but typically this cost pales in comparison to that personality’s draw in attracting readership and advertising. In general, even production facilities for fairly elaborate shows will end up representing a minimal percentage of the total cost of distributing that content, to the extent that while there is significant competition on the part of studios to get the “air time”, that most precious of resources for airing their works. Ultimately, it comes down to distribution.
So in 1991, along comes this young British programmer working at a research facility in Switzerland who was just trying to figure out how to get physics abstracts out to research scientists too lazy to go to the center’s library, and WHAMMO! all of a sudden this whole balance of power thing that these Media giants have spent the last century building becomes irrelevant. In fifteen years, the web has changed the equation so dramatically that most media players are forced to resort to their big guns … the LAWYERS … in order to manage to even slow the process down enough that maybe, just maybe, they can figure out where to go next.
There’s a fundamental law in economics: You Make Money on the Differential.
In a nutshell, this means that any time there is some form of impedence - a high barrier to entry, a high material costs, limited resources, expensive distribution costs, etc. - you can make money because you’re investing money in scaling that impedence where others may find the costs are too high. Once past that initial impedence, most media costs are manageable (the transmitter is expensive, but once in place the cost of production and transmission is cheap, the press is expensive but once in place the other costs are manageable, and a good press-owning publisher essentially sees time on the press as their limited resource).
What the Internet has done is to knock out all of those impedences. The cost of owning a server is far smaller than owning a press, but your portal or blog can still be viewed by as many (and in a number of cases far more) people than would be the case if you’re creating newspapers. Your distribution costs are so low as to be measured in microcents. Your advertising costs are also low … if you’re good, then others will link to you, and in those links lies your ability to attract new subscribers. All of a sudden, without really intending to do it, you’re competing (and more amazingly, are competing easily) with the established journalists … and they’re scared silly.
Now, here’s where things get interesting. You put a Google banner ad on your blogsite (oh, and there will be others there, if you don’t like Google’s politics - it’s far too profitable a place to be, making a little money off of millions upon millions of people rather than a lot of money off of a few fickle custoners), maybe tie in a link or three to an affiliate marketer such as Amazon, and without a huge amount of effort you’re making money off of your writing, off of your website, even, perhaps, off of your chat session. The money might not be much, though again if you’re both good and dilligent you can make a surprising amount of money doing it, but what you’re also doing is undermining the Media which have survived precisely because they offered eyeballs to advertisers.
The web has, consequently, and without a huge amount of specifically directed effort, performed upon traditional Media a form of Ju Jitsu, in which the Media’s strengths - its high barrier costs to entry and distribution - become instead its greatest weaknesses. Right now, these Media are surviving because of two primary factors … there is still a percentage of the population that has not yet migrated in any significant manner to the web for their source of news and entertainment, and there is still a percentage of the population that have equated the near monoply control that these media have held on the market with stability and quality - they are brand names, to a population segment (largely baby boomers) that were raised upon the near religious worship of such brand names. However, that hold is rapidly slipping away in that most crucial of demographics … the young.
I am near the tail end of a generation that remembers Walter Cronkite’s stentorian tones describing the drama as a man first walked upon the moon. Here was a man who epitomized for me and for millions of others the voice and face of Authority. Recently, with the death of Peter Jennings and the retirements of Ted Koppel and Dan Rather, the three major stellar lights of a more contemporary generation within the journalistic sky have dimmed. In their place are … um … damn, I can’t think of anyone. I can think of political pundits on the left and right, a few very (darkly) funny comedians, but … um, authoritative journalists? You’d think with the sheer talent that’s out there, with twice the number of people in this country from what it was when Cronkite was in his prime, that there would be someone with that level of sheer raw authority out there … but there aren’t.
The young (which in my book is beginning to encompass an awful lot of you, sad to say) have not been inculcated to the same degree in the cult of personality that the boomers were, nor were they taught to revere the brand, to salivate on demand upon hearing the Pavlovian tinkling of Madison Avenue’s bells. Go to the very young, that evanescent group of market desireables called the Tweeners, and you see that their identities are wrapped far less upon the notion of seeking after what’s cool, and is instead tied far more in being random. My own twelve year old daughter identified random as being “unpredictable”, hard to categorize, difficult to pin on some marketing mogul’s map of demographics. Once the brand fails, once these same younglings begin to realize that the great Oz is not only this shrunken man behind a curtain but that the guy’s a rather scary little pedophile, then the Authority of the Media begins to fail in earnest.
So what does this mean for bloggers and blogging? Once upon a time, long before Media was raised to the level of being a university level schools of discipline, newspapers typically did not have the resources to have a huge staff interviewing everyone at all times. Instead, they relied upon the reports of eye witnesses to these events who happened to keep journals, paying them a certain amount to relay their impressions to a waiting audience. These journalists had their own agendas and viewpoints, of course, and even then a journalist would be hard pressed to sell his or her story to a publisher with opposing political views, but in order to appeal to the largest possible audience, the publisher himself also had to occasionally relax his biases enough so that he wasn’t losing out from the potential income of a subscriber.
This give and take between journalist, publisher and reader served for quite some time to create a relatively balanced viewpoint, though this was also balanced out by multiple papers of different viewpoints also being available within the same town or city. Most people under the age of forty are unlikely to realize that at one time, most cities over a certain size might have actually had not just two competing papers but a whole constellation of them. However, the move to a winner-take-all advertising model, the rising costs associated with the technology and materials involved in publishing and the attrition that occurred as people moved from the introspective model of reading papers to the visceral model of watching TV has largely spelled the end of the multiple newspapers per city era, at least in the United States (Canada seems to be more robust in this regard, which I’ve always found to be a major selling point of the Canadian ethos).
Blogging is forcing a radical sea-change in the print media realm, and will likely do the same within the TV and radio realm as podcasting becomes more established. There are several million blogs right now, though the vast majority of them are fairly ephemeral - people testing the media and discovering that perhaps the stories that they have to tell are not as pressing as they had thought. I’ve written or cowritten nearly twenty books in the last fifteen years … I know full well that writing is hard work that requires persistence, and being a blogger is very much like being a columnist with an absolutely insane deadline and absolutely no control of who your audience is. It’s thus not surprising that blogging has such a high churn right now, but that’ll change.
What is happening, however, is that out of this chaos a new night sky is beginning to emerge, one sanctioned not by the official imprimateur of an advertisting based Media but one that is driven by word of mouth referrals, links in which authority is imputed by the authority of the referrer, the network-effect based phase-shift brought about by search engines as someone zips past their tipping point. To a certain degree there’s a Ponzi scheme like characteristic to this … the first into a given niche will have a considerable advantage over those later into the niche, but in the hyper-evolving world of the web, this strength can turn into a weakness overnight when the niches themselves shift and dance like crazed squirrels in a cashew factory. Still, the good bloggers, the skilled ones, are those who have managed to find their own strange little attractors that provide a modicum of stability in this chaotic landscape.
You have to be a good writer to succeed as a blogger. You have to entertain as well as enlighten, turn even outrage into a fascinating look at the human psyche. Oddly, objectivity is not as relevant a factor, largely because most bloggers are generally not trained in the artifice of journalistic objectivity. Nonetheless, failing to get your facts straight in the blogging environment can prove brutalizing to you, ironically far more than stretching the truth (or even fabricating it out of whole cloth) in the more traditional Media, because your readers are also only a link away, and have in most cases access to many of the same pieces of information that you may have yourself. Thus objectivity, whatever that particular shiboleth is, tends to be a self-reinforcing property within the blogsphere that all too often is missing in the Media proper.
In the end, this objectivity may prove to be the critical point upon which traditional Media falls. In the “random” world of the early twenty first century, the old Media conglomerates are competing against legions of low-overhead counterparts that are capable of producing as much content by aggregating related bloggers and news articles into “editorial” packages as the traditional media can, often at considerably lower cost. I blog for O’Reilly and Apress in addition to my own personal site, UnderstandingXML.com; it is an arrangement of convenience, because O’Reilly raises my visibility considerably; they, on the other hand get a blogger of increasing note and reputation reinforcing their reputation as “new authorities” in the field. I make some money from banner ads, but I also make money and gain connections for my own work that I wouldn’t have had otherwise. In other words, the relationship between author and publisher is changing, profoundly, and I think that in the end for the better.
The traditional Media are on the other hand forced to do what comes unnaturally to many of these publishers - pushing the reputations of their writers (and other content producers) rather than themselves as the arbiters and retellers of “Truth”, “Humor”, “Insight” or “Beauty”. Those Media representatives that recognize their own diminished roles are ironically the ones that will survive, while those that continue to raise the masthead colors will in time disappear into the sea of information, abandoned by their readership who seem them as offering only one potential slice of that truth, and abandoned by the advertisers who are far more interested in the odd, targeted blogs that represent to them very finely focused advertising micro-markets.
These advertisers like the Google model, because it makes it far easier for them to ride the crests of author popularity, most of whom tend to have self-selecting readerships within a given marketing niche, without the risk of being too dependent upon a horse that fails mid-stream. There are some risks with this approach as well … being affilliated with someone who may be violently opposed to the advertiser’s message being only the most obvious, but again this is something of a self-corrrecting problem in that such a person may not want the association any more than the advertiser does.
Beyond the gradual fading of the traditional Media in the face of the search aggregators such as Google, the future of blogging is somewhat murkier. One aspect that is already obvious in this space is the pollution back channel that seems to arise with every media. Corporate pseudo-blogging is on the rise, in which a company creates a “virtual blogger” who acts as a shill for the company’s products or services and is a fictional creation of a marketing department. I don’t see these having much traction … blog-space readers are becoming more and more nuanced in their ability to determine “bogosity” (blogosity?) in both commentary posts and blogs, and once so unmasked, the revelations can prove to be damaging to a company’s credibility in that space. This differs from the legitimate company blogger, who is generally expected to take the viewpoint of the company but nonetheless provides useful value to readers … this represents more of an insider’s perspective than anything, and is treated as such.
Blam (blog-spam) is also a problem - most blog engines offer web services that make it possible to post comments and give trackback pings to related sites, and anywhere that an automated interface exists so does the potential for spam. This can be partially counteracted by user registration and graphical authorization passwords (the distorted number and letter combinations that many services use to fool screen scraper and OCR programs), but this tends to reduce readership as well, as many people are understandably loathe to sign up for something and possibly expose themselves to identity theft.
This points to another area where blogging is likely to change - at the moment, there are roughly a dozen different types of blogging servers, each of which offer their own set of user interfaces and web APIs. It’s likely that, over time, there will be a fairly high degree of consolidation in this space — indeed, I’d go so far as to say that by mid-2007 there will be some consortium of blogging server providers that will set an open standard for communicating with blog servers (as a guess based upon the Atom 1.0 Publishing Protocols). This development is not a nice to have - its crucial for the future success of blogging. A common publishing API makes it possible for browser vendors and application developers to incorporate editors within their products that do not need to expose to the average user the intricacies of connecting the the blog server. This means that publishing to the web literally becomes akin to writing an email message, where all you need to know is the mail address of the recipients, and that you can build web interfaces that express connectivity with the blog server as being little different than looking into a folder for a particular file.
Such a transparent “blogging” solution actually results in the development of a seamless “writeable” web, one where content can be added to the web without needing to know any of the particulars of publishing, can be done in a consistent manner regardless of the server and browser, and can be edited not just at the text level but at the metadata level as well. This also has the effect of doing for content management systems (CMS) what has become an increasingly viable goal within the database realm - creating a layer of abstraction around a given CMS so that its internal characteristics (or at least an acceptable minimal subset) are irrelevant. When this happens in the database realm, it radically simplifies the development of data-oriented applications … watching this change take place within the CMS space should prove interesting as it breaks down the final vestiges of the static web that seems the hallmark of Web 1.0.
Finally, returning to the societal implications side of things, we’re moving into a world in which the ability of governments and corporations to control the flow of “inflammatory” blogs will become increasingly difficult. Blogs, unlike websites, can exist in syndicated form independently of a specific web-link; such “unaffiliated” blogs can often be syndicated and distributed far faster than a government or corporation can react, especially in the pressence of content aggregators, and they can be notoriously difficult to shut down or stamp out, because there’s typically no one “central” server that can be seized by police. However, this also means that bloggers who are caught are likely to be dealt with harshly, especially in more totalitarian regimes, and (not coincidentally) in more restrictive corporations.
Bloggers today are regarded as curiosity by the mainstream Media, though not a few journalists are establishing their credentials in the blogosphere even as other journalists (and the publications and networks they work for) are recognizing the threat that blogging has to their profession. This means that bloggers will likely end up testing the boundaries of what constitutes free speech throughout the world in a way that makes them extraordinarily vulnerable to persecution precisely because they do not have the formal imprimateur of existing publishing organizations behind them. This does not make what bloggers are doing any less important … or any less legitimate. The blogger represents one of the purest exponent of personal or citizen journalism at a time when most journalism has been heavily tainted by corporate intimidation and government threats of violence or censure. Given that it is difficult for a government to remain corrupt in the face of an active, engaged and well-informed populace, it is likely that the success or failure of this extraordinary experiment will presage the shape of society for decades to come.
Kurt Cagle is an author and the technology evangelist for Mercurial Communications in Victoria, BC. He writes regular on web technologies, XML, and their societal implications for UnderstandingXML.com. This (admittedly long) blog is intended to accompany a talk to be given at the Northern Voice Canadian Blogging Conference in Vancouver, BC, February 9 at 1pm, where Kurt will be blogging the conference.
So what do you feel is the direction that blogs will take in the future?
I’ll admit it … I’m one of those poor saps who inevitably, when given the chance, roots for the underdog. I can’t help it. For several years, I rooted for the Seattle Mariners, that perennial underdog that has, in its thirty odd years of existence, never made it to the World Series. Its perhaps for this reason (though there many others) that I’ve been a long time fan of Open Office. The open source office suite has come from rather dismal beginnings (the early Star Office incarnations were truly dreadful) into being a solid, capable, and performant alternative to Microsoft Office not only in the Linux space but even on MS Office’s home turf of Windows.
Open Office Developer Writing Content
In the wake of Open Office 2.0, there have been a number of interesting developments that are aimed at improving not only the product itself but also the developer and user communities. One in which I have a direct hand most recently is the establishment by the Open Office development team of a contest for the best technical article about some facet of Open Office. To specifically quote Louis Suarez-Potts of the Open Office Team:
OpenOffice.org, with the support of Team OpenOffice.org e.V. and
extra sponsorship from Sun Microsystems, announces its first
Developer Contest starting February 1, 2006. The goal of the
developer contest is to generate more developer documentation. We are
also interested in promoting OpenOffice.org to developers at the same
time.
As part of the contest, developers are asked to write articles about
developer topics, such as porting, add-on and filter development
(e.g. new wizards, Calc functions, chart types, etc.), bug fixing,
etc. Every month a committee will pick the best article from the pool
of submitted articles. Articles that did not initially win will stay
in the pool, so that they can still win later.
The developer contest team wishes all participating developers and
writers good luck! We look forward to receiving the first articles.
I am a member of the judging board, and I’m specifically going to be looking for decent articles with an XML bent to recommend, so please, feel free to submit as often as possible.
Open Office Labels
Russell Ossendryver, the US director of Worldlabel.com, also recently wrote to me to announce one of those odd little niches in business which can, when identified, make their identifier a very wealthy man. In this case, Russell writes
We just released label templates for Openoffice.org: http://www.worldlabel.com/Pages/openoffice-template.htm. Although it might not seem significant for XML, it is when you consider that the only available label templates for the masses have been in Microsoft Word for text type supplied by Avery Dennison corp., the giant monopoly. Actually 10s of thousands of Word label templates are used daily for printing labels These templates fill a void especially for Office Suites on Linux, FreeBSD and Solaris.
I personally think this is a fairly major thing - most labels are generated for use from within office programs and batch processing mode processing. The templates, in addition to working well within the Open Office environment, can also be opened and examined by unzipping the template document, which means that with a little bit of additional processing you could actually utilize these with XSL-FO to generate labels from other XML sources.
Mitt Romney is Fast Becoming My Hero
When Massachusetts state CIO Peter Quinn resigned recently due to intense lobbying pressure (and some reported intimidation tactics) may have seemed like a major blow to the adoption of the Open Document Format, but it seems that Massachusetts Governor Mitt Romney may in fact have the last laugh. On the 30th of January, he appointed a new CIO, Louis Gutierezz, and during the appointment also released a press release indicating that he was still very much in favor of the ODF format and planned on seeing it made official by year’s end, as is indicated in the second sentence of the press release:
Gutierrez will be responsible for overseeing the final stages of implementation of the state’s new Open Document format proposal, to go into effect in January 2007.
This is frankly incredible, and showcases the fact that Romney, who’s rumored to be considering a run for President, is both very much aware of the technical debate and at the same time has absolutely no intention of being bullied by Microsoft on this front. It’s a gutsy stance for any politician to take, and bodes well for the future of open standards in the state … and by extension, may prove to be the catalyst for other states to consider moving their infrastructure to open standards.
Open Office for Intel Mac OSX and Portable Open Office
Open Office recently announced that the first build of Open Office 2.01 for the Intel version of Mac OSX, adding to the applications capable of running on that intriguing hybrid. In similar news, OpenOffice.org teamed with PortableApps.com to create a portable version of OpenOffice, one capable of running off of a USB thumbdrive, a portable hard drive, an iPOD or MP3 player, and so forth. This raises a number of issues, not least of which being that we are rapidly reaching the second fork of ubiquitious computing (the first being files in the Internet data cloud), where one’s data can remain with you even without a computer. If bluetooth or ultra high bandwidth wireless USB ever becomes a reality, this gives rise to the notion that you could walk up to a computer anywhere and start working with the files located on your belt buckle or earrings, without having to worry about having the right tools.
SVG Import Filter
At the end of last month OpenOffice.org released what I’ve felt has long been a sorely needed feature - an SVG Import Filter. While Open Office doesn’t use SVG internally (although it does maintain critical information in an SVG namespace within drawings) the lack of SVG import support has meant that its not possible to load in SVG files as graphics for word documents - something that’s been very frustrating to me and many others. Utilizing the Apache Batik SVG engine, the import filter has undergone a number of improvements since its last update in August, including considerably better handling of gradients (something that’s always been a problem in OpenOffice), better handling of elliptical curves and transformable use and image elements. It does require that you have the Java JRE 1.5 on your system.
Batch Conversion of Legacy Docs
Bob DuCharme, in a superb article for XML.com writes about “Moving to OpenOffice: Batch Converting Legacy Documents.“. In it he covers the Open Office macro language and illustrates how you can create a simple batch routine for taking all of those pesky proprietary MS Word documents and converting them into Open Office format, including invoking this from a command line call. I’ve used Open Office before in this role as a batch document converter not just to ODF (or to the older SXW format) but to DocBook and other related formats. This trick should be a critical part of any document management system that needs to convert legacy Word documents into XML formats, without the licensing costs of going to the MS Office 2003 and utilizing the Office Open (hah!) XML format.
So, to wrap this up, once again I ask all of you budding technical writers to try your chops in writing for the OpenOffice contestOpenOffice contest. It comes with a decent prize ($750 for the winning entry per month), and helps to build the information base for the best open source office suite on the planet.
Kurt Cagle is an author and web architect specializing in XML, Web 2 and AJAX technology, and is currently available for consulting (please check out his resume for more information).
Do you have any news or case studies about OpenOffice that you’d like to let people know about?
Wednesday February 1, 2006 12:04PM
by Jim Alateras
The role of open source software has changed over the past 10 years. Initially it was the domain of the alpha geeks and hackers motivated by the need to ’scratch an itch’. Today most successful open source initiatives are backed by large ISVs and industry consortiums. The other significant change is that open source, which primarily focused on developing commodity style software (long tail) is now targeting the vertical market.
Six years ago I worked on OpenJMS, and open source messaging product for the OEM market. Today, I am currently working on a open source CMS application sponsored by a consortium of veterinaries. Why? The reason is that the stakeholders believe that the core features of the CMS will not offer their business a competitive advantage so they view it as a point of collaboration. A CMS that is flexible, customizable, extensible is paramount to their business. From the veterinary’s perspectives the ISVs in this space have failed to deliver software with these attributes along with an affordable pricing model. The software moves from the hands of the small to the hands of the many, which is all good for the customer. The customer still requires support and enhancements but they are not tied in to the resource limitations or resource schedule of a single company. They now have many more options.
The open source model is not always the right approach and many open source software initiatives have failed for one reason or another…just look at 80% of the projects at sourceforge. The role that open source software plays has changed and will continue to change as the industry changes. Are we cutting our own throats by promoting open source software? I don’t believe so. Instead it is opening up a whole lot of new opportunities for those innovative and brave enough to exploit them.
It’s been a little while since my last post, though not for lack of trying. I’ve been intending to write on the 
