Recently in Microcontent Apps Category

Reporting from InfoWorld CTO Forum, Jon Udell summarizes Adam Bosworth's keynote address where he paints the big picture on Internet application architecture.

As I have mentioned previously, I thoroughly enjoy hearing what Adam has to say. (I still maintain that the world would be a much better place if he had a weblog.) Again he does not disappoint, making several insightful observations with his uncanny clarity that are spot on. Topics covered included coarse-grained messaging, XML repositories, XQuery, message-driven model, asynchrony, and public contracts.

It was his reported comments on scripting rings most true for me presently. Insights from Bosworth, Udell and Ward Cunningham have reinforced and contributed to my thinking in how Sun should (but probably won't) simplify Java development and why Flash/SWF is on track to achieve a great deal of success in developing Internet applications.

Bosworth was instrumental in driving the effort to add native XML scripting to ECMAScript that was just officially announced this Friday. Being BEA's Vice President of Engineering, it is no surprise that BEA is the first to implement it in a product.

Certainly the combination of some of the browser interface technologies (specifically XUL and in the future XForms ) could develop into a strong candidate platform for Internet applications, but quite has to develop soon if it is to happen at all.

UPDATE: Chief Software Architect, Kevin Lynch notes Adam's keynote and comments on scripting by comparing it to Macromedia grand plan. He final concludes with a familar reconmendation – Adam, you need a weblog! Makes me actually feel like Kevin might be out there reading my weblog.

If Adam wants a weblog, I'll personally volunteer to setup MovableType for him. He probably doesn't want me to do any design for him though. ;)

Macromedia announced Flash's independence from the browser and an associated marketplace for Flash applications called Central. This is a very positive setup towards Flash's adoption as a microcontent client development platform and application-centric mate for the browser. The issue of a Flash application development tool for programmers is still left unresolved. I wish for a Flash application compiler. More on my O'Reilly weblog.

UPDATE: Seems my wish could be coming true sooner then I thought. Macromedia's Mike Chambers writes on the tantilizing Royale project that was shown a the FlashForward conference today.

I just got around to reading Dave Winer's "First Essay of the Year." If you know Dave and can parse out his self-serving comments, he has some very good thoughts. For instance The Web uniquely wants to be used by everyone, not just for the purposes of big companies and their profits and paranoia. This is a foundation that I think we agree on.

Agreed. I wouldn't just differentiate on big companies though.

I thought Jeremy Allaire's commentary on the essay more relavent and better stated. Allaire writes The question it really provoked for me, and one that has been lurking in my mind for the past few months, is whether weblogging as we know it will truly become a mainstream form of personal communications and sharing, rather than it's current perceived niche as form of personal or independent Internet journalism.

Jeremy lists his personal perspective as to why weblogging is revolutionary -- publishing to the web is simple and your content is well structured and shareable. In order to gain mainstream acceptance he asserts weblogging, as it is known today, will need to Break out of the calendar journal or narrative metaphor and Embrace richer forms of expression through graphics, audio and video.

It would appear that 2003 is shaping will be the year of the two-way web and, as I like to think about it, the universal canvas.

The ever-insightful Jeremy Allaire offers his views on "holistic Web services."

...I've continued to be annoyed by the narrow-minded thinking that has dominated discussions of web services to date. Like many IT technologies, the central thrust of the web services worldview has emerged from the classic middleware infrastructure providers, which has in turn colored our thinking on web services significantly. The essential problem is that web services as defined by a core collection of XML protocols (SOAP, WSDL, UDDI) focuses almost entirely on API-level application integration, rather than a broader view of how software will be created, distributed and consumed in the future.

Jeremy goes on to discuss the relationship between Web services and Application Service Providers (ASPs) in addition to "the missing pieces" in ASPs vision.

He concludes, "let's turn the debate around and focus again on the broader vision of software as service rather then keep ourselves down in the plumbing....."

Amen. This is the exact notion I had in mind when I wrote "Flash MX and the Bigger Picture: Lightweight Internet Applications".

[UPDATE: Just catching up on my reading I found that Jeremy also has posted an equally as insightful piece on "The Problem of Scale" that is also worth a read.]

Jon Udell notes Macromedia CTO Jeremy Allaire has created a weblog and starts off with a post on "rich-text" editors developed in Flash MX. Like Jon, this is a topic that has been of great interest to myself in the past. Jeremy links to a review by Flash VooDoo of three of these editors. They show a lot of potential though none of them are exactly what I want.

My first article for the O'Reilly Network, "Flash MX and the Bigger Picture: Lightweight Internet Applications" was published today. Its the expansion and refinement of my past thinking here and elsewhere.

Rajesh Jain comments on the ZDNet Linux desktop special report:

Still no mention of Linux on Thin Clients. Linux TCs are disruptive. Everyone today thinks of thick, new desktops. That is because the context is either US, Western Europe or Japan. Change the context to India, China, Brazil and see how the picture changes! It opens up a new world of opportunities and ideas, which is exactly what the tech world needs today.

Phil Wainewright summarizes his thoughts on two recently published articles on Web services. On "Web services: Is it CORBA redux?" by Sonic Software's Gordon Van Huizen he writes "The article is a useful primer on why RPC should be avoided -- something I've always felt was the case, without being able to succinctly explain why (until now)." The second is an interview with XML pioneer Dave Hollander entitled "Thinking about the future of data." He writes "It's a helpful introduction to concepts like XML Schema and Namespaces, and why they're important."

Phil also points to a recently published IBM developerWorks article on the topic of BPEL4WS for the curious.

I've been involved in a discussion of Flash's capabilities to develop a better HTML editor component for authoring hypertext content through a browser interface. This is a topic I've been openly giving some initial thought to and was consequentially asked to share my views on how this editor might be designed. While far from complete, this post is a summation of those thoughts thus far to begin what I hope is a productive dialog on this topic.

Recently I said that a simple and extensible markup editor is too integral to web applications that it has to be ubiquitous and without constraints. How this editor component is designed can be defined with three primary goals: flexibility, simplicity, and lightweight. Of course these design goals can be interrupted in varying ways and requires elaboration. The also require a certain amount of balance and compromise to achieve a broad set of requirements. Here are some specific thoughts I have had in mind.

FLEXIBILITY

The editor widget should be configurable through a separate XML file (locally or remotely) rather then modifying source code. I really enjoyed using Homesite 2.5 in its day. While it was a code (rather then WYSIWYG) editor, it was streamlined and yet powerful with its easy extensibility. (Has anyone used TopStyle by the same author?) One of favorite features was the ability to create custom editor "tags" by defining attributes such as start and end segments. One click would wrap the highlight text in those start and end tags. This was immensely helpful in pre-CSS days because I could define a tag that was composed of multiple HTML tags. For instance I could create a <scream> tag that would wrap the selected text in <b>, <i> and <font color="red"> HTML tag sets. Besides saving time it made my HTML coding more consistent. Once acquired by Allaire, HomeSite extended this capability by introducing VTML with TagTips and dialogs. Unlike HomeSite these configuration options probably shouldn't be editable directly from the widget rather the site manager or application developer. If one really wanted to allow users to customize the editor they could elsewhere and dynamically generate the configuration file.

This is just one example of why configurability is an important feature. What markup tags are available and how they are implemented (XHTML or HTML?) could also be controlled without code modification. To this point...

SIMPLICITY

The editor should "shield" the user from understanding actual markup and not be limited to producing just HTML. This editor would initially be used for HTML editing interfaces like those found in weblog tools. In considering the bigger picture, I believe it's important to allow for the configuration of task-centric editors. For instance, which is more user friendly: having a bookTitle option or selecting span and choosing class "bookTitle?"

Does not attempt to come close to the sophistication of standalone editors like Dreamweaver and Composer. The value of this editor will diminish if it tries to do too much.

Supports only simple interfaces. The editor should make minimal use of dialog boxes. The widget should only support a single editor window.

LIGHTWEIGHT

Implements "fat" features as web services. Simple helps in creating a lightweight application, but not completely. Functions such as a spell checker or markup validator should offload its processing and data to an external service

Userland's Jake Savin has been considering an HTML editor in Flash (here and here) and writes:

Why doesn't Macromedia get their heads out of their asses and come up with a really kick ass cross-platform browser-based WYSIWYG editor plugin? It needs to be really fast, do spell checking, send data via HTTP POST, and ideally be extensible using locally running native code.

There's a gigantic opportunity here, and Macromedia has the experience, the marketing power and the developers to make it happen. If their users are already this close, then the engineers inside Macromedia are certainly capable of fulfilling this wish.

This is a topic I went into some depth on back in June. I posted this comment to Jake weblog:

I had written about the illogicz (rich) text editor in my weblog that got the first discussion going sometime ago. Sadly little progress has been made in furthering this idea. Here is what I can offer this thread...

At a meeting with Macromedia I made the same suggestion as Jake -- develop a markup editor widget for the communities use. I was told that Macromedia would leave such an effort to its partners or the flash developer community at large. After several messages to the folks at illogicz I received a broadcast message thanking me for my interest and stating their intent to package the editor into a product that they would offer for sale shortly. I believe some of Macromedia's partners also have plans along these lines.

I don't think this really is going to help if there is a price tag involved. I'm not a flaming Richard Stallman FSF type. I just think that a simple and extensible markup editor is too integral to web applications that it has to be ubiquitous and without constraints.

From what I can tell the Flash developer community doesn't think like we do as coders and backend systems folks. (A real hurdle for Macromedia if they want Flash to be taken seriously as an application platform.) I've been meaning to take a crack at this myself --even going so far as to acquire a copy of Flash MX and draw out a wishlist/spec. However, I've been rather preoccupied and am not much of a Flash developer.

Last, the illogicz editor is indeed read-only. In asking around, I've been told that there is a means for a Flash object to communicate with the embedded pages DOM, but I was given the impression it can be a dicey issue.