Pioneering

Ward Cunningham on open source, wikis, etc. as he joins AboutUs...

I'm fortunate to have been closely involved with a number of important shifts in our industry. I try to keep track of developments in patterns and agile but have chosen to focus my day-job attention on open source. This is not out of casual interest. The rationale for open source goes well beyond cost sharing to the very means by which we create knowledge, a theme that runs through all my work.

I bring this up now because there is one more shift with my finger prints on it that has been developing nicely and now demands more of my attention. Wiki is the tail that wags me. It is the little thing created in service of programming that grew bigger than programming itself.

In a week I will join AboutUs, a wiki company founded in 2005, as Chief Technology Officer. I’m honored to join their team. This company understands the power of the wiki concept and how to put it to productive use.

A Two-Run Home Run

Interesting that the MSFT soap/indigo folks are coming to jesus at the altar of restful web services just at the same time they are coming to jesus at the altar of dynamic languages.

"Contracts" are good. Over-specified, up-front specification checking is not.

PDF Creator -- PDF Print Driver for Winders

I just came across, and started using, PDF Creator. Now when someone sends me a MSFT office document, I can easily save it as PDF for all to use, anywhere, more efficiently. This still happens a lot at large, enterprisey places.

I've bought PDF print drivers for low cost in years past, but this is open source and seems to work fine. It uses ghostscript, and there is an installer with and without ghostscript, depending on if you need that too.

Pick up gsview while you are at it.

Apollo

It's here where I'm probably getting caught up. Do you envision such an Apollo client to be a sexier, slightly more functional version of the app that renders in my browser? Or does the Apollo app contain sufficient functionality that it is the only meaningful client?

I see apollo as a platform for more capable clients that are easier to develop, but that consume the same restful web services that other clients consume. Those services may dish up html, etc. perhaps with microformats, or they may dish up "pure informational" resources in xml, json, etc. and the clients would provide some other, non-html-based display/interaction engine.

If the latter, then that is what I, at least, have a problem with. If it's the former, then that tracks with your argument, but it seems there's a very fine line between a somewhat better client and the only client--a line too easily (even accidentally) crossed.

"Only client" would be bad, generally. Of course people *will* do this, they do it today. Many people were doing something even worse when they were on the WS-Deathstar. Fortunately the whole world seems to be disavowing they were ever even remotely in that camp. (Let the record show I never was.)

So the world seems safe now for new clients that can actually play on the web with truly restful web services. That's the whole point, what allows evolution of clients and servers to take place.

It would also help if you can describe how you're using Apollo today, and how you're keeping from making Apollo-only apps.

We're just starting to use Flex today at work. I am kicking the tires at home. In both cases I hope we keep moving more in the direction above. Without getting into specifics, my work is currently in the insurance industry, which is obviously drowning in data, under-automated, burdened by layers of "legacy" systems, etc.

Word

Via Pragmatic Dictator, I read recently Pat Helland's "Life beyond Distributed Transactions" (pdf).

Via Sean McGrath, I recently read Pat Helland's "Memories, Guesses, and Apologies".

Nicely done. Subscribed. Would that Pat Helland were working in the open world.

Unfounded Panic Ensues

The panic continues from really smart people (more than one), for some unknown reason...

how is that different than the bad old days when a site was developed for one particular browser?

I really have trouble understanding the concern. When I read about Flex and Apollo the first and most important aspects that caught my attention was the *emphasis* on being web compliant.

The point *is* to write web compliant services and run them through many kinds of web clients. Apollo is just one and should not be leading to locked in service providers.

That would be dumb and missing the point of the web.

Disconnected

Sean McGrath writes about the new world...

Software people need to realize this new reality and go visit with the hardware people.

The processor will stop doubling in speed and halving in cost. Instead, you will find more and more processors shipping in each computer.

This is the future because the hardware people are creating it that way. The software people need to realize that fact and start figuring out how to use all the processors. This future does not just involve just re-compiling your software. It involves turning it on its head in most cases.

Things are different now.

Disconnect your software: share nothing.

The Simplest Processes That Could Possibly Work.

We Are Evo -- Mostly

Congratulations Indiana, North Carolina, and South Carolina. I would not have guessed, and I apologize for that. Gold states: go green! Orange states: hello?

Even More On The Web Again

More responses to comments as I struggle to communicate -- I am glad to be receiving these comments because maybe there are things I am not getting, and maybe there are things I am not communicating effectively.

"visit the URL of the Apollo/Flex application. What, I need a plugin!" -- ok, then, what is the URL of your firefox executable? Actually the URL of the Flex / Apollo application, if you want one, can be on the web.

More important, however, is to recognize the Flex or Apollo app's URL is not as important as the URLs of the *resources* that app consumes. Especially since those resources can, and should, be fully restful, and so any app can access them.

One more time: Flex / Apollo apps can access *restful* services. Nothing about those services is specific to the Flex / Apollo runtimes. Take or develop any *restful* service and access them in any capable client. Flex / Apollo is just one specific set of components that can access these via URIs. It's just that once you use Flex / Apollo then that client "engine" is much easier to develop and much more expressive for the user than is a current Ajax toolkit. That is all I am saying.

"proprietary runtimes - that do not have the reach ordinary HTML, CSS, and JS do" -- well..

1. Flex / Apollo to me are *signposts* of the future for building these apps.
2. Flex / Apollo are becoming *more* open with hints of that continuing.
3. Apollo specifically supports all these, just like any other browser. Both support CSS. Actionscript is JS-like. (I am not crazy about the AS extensions, but oh well.)
4. Apollo apps can have HTML *or* Flex components. And the one can embed the other as desired. This is often overlooked I have found. Apollo uses the same open HTML components as Safari.

"what's planned for Firefox 3.0" -- I have looked a bit, and like what I see. Offline, etc. is good. I have *always* stated that I see Flex / Apollo as *directions* for RIA web clients, not the be-all-and-end-all-for-all-time. However from what I've read of FF 3.0 it will still have an Ajax + Canvas and some SVG. I think a rich, structured, retained, vector graphics capability in Flex is better than those things I think will be in FF 3.0. that said, I am interested in Flex / Apollo pushing FF and other web clients to be even better. Convergence could be good, but competition to some extent could be even better.

"I think you drastically underestimate what can be done with current browsers, even in a cross-browser manner." -- maybe, but it seems awfully painful and unnecessary. The key is, I believe, to get services more restful, less UI-oriented, and then various kinds of clients can interpret them in their own ways. Restful services are more important to me than semi-compliant HTML web browsers.

"it's better to evolve the browser rather than replace it" -- the browser is *stale*. As I said above, Flex / Apollo is useful for pushing the current browsers to the next level. Meanwhile it is also a hell of a lot nice to develop Flex / Apollo based apps than Ajax. With restful "data" services you have more choice in client components per se.

"WS-Deathstar" -- N/A -- misunderstanding on my part.

"Apollo and (especially) Silverspoon aim at replacing the deployed infrastructure, when they cd have enhanced existing browsers instead (as apparently Mozilla intends to do)." My response...

I agree, although arguably MSFT's and Adobe's current approach is more expedient for them. I would hope they are participating fully in the WHAT-WG or whatever (pun) that workign group is that's trying to push the browser forward.

A fairly good signal so far -- Adobe has donated their VM to open source, in particular Mozilla. The Flex API is opening sooner rather than later. The Apollo folks have said this is a likely direction for them as well.

Apollo did choose the HTML component used by Safari and others rather than Mozilla's. But they are using an open, popular one. I imagine they have valid technical reasons for this choice over Mozilla's.

All things considered, I think the state of the web client is moving in a positive direction by having many various clients. Given the browser stagnated for so long, this seems to be a time to expand choices and think creatively.

Thanks again for the comments! I hope this is helping all of us.

On The Web Again

Responding to comments from earlier posts, here are some qualities I think are part of being "on the web".

"hypertext and hyperlinking" - yes. And so Flex/Apollo applications can get resources that have links, can display resources that have links, and can respond to the results of following those links. So that is part of what makes them able to be "on the web".

Flex is a library of Actionscript. Apollo is an extension of that. Those libraries include the ability to do these "on the web" things. These things (and the web itself) can, and will, go *far* beyond what the current browsers can do. Don't get locked into thinking the only true web client is this unfortunately limited web browser you've been using for a decade or so. So yeah, ok.

"bookmarkability" - I don't put this in the "on the web" category per se. Although since Flex/Apollo apps can do linking and link-following then being able to save and recall these in various cirumstances would be useful. And so since they can be "on the web" then they can use bookmarking services that are also "on the web". Other kinds of bookmarking are possible as well, up to and including Apollo's ability to use a local (or other, really) file system. So yeah, ok.

"hypertext as the engine of state" - yes, well this gets back to linking, but the emphasis in this comment seems to be on the "engine" part. Flex/Apollo apps can provide an "engine" very much like a browser is an HTML "engine" or they could be used to implement other kinds of "engines". HTML is not the only fuel for "engines on the web". So yeah, ok.

"view source" - I don't put this in the "on the web" category per se, but it certainly helps the web evolve, so let's include it. Flex/Apollo apps are compiles to binary, but can also provide a "view source" capability if the developer desires. So yeah, ok. I would recommend using this in almost all cases.

But this is similar to "meaningful URIs" - are these required for the web? In some cases opaque URIs are more desirable. The developer gets to choose.

Misunderstanding RIA Some More

Peter Lacy is pitting Apollo/Flex vs. the web. Please don't. That is mistaken.

Adobe "gets" the web. These components run "on" the web, and are "of" the web. Yes, they have ways to use things in a non-web way, just as Java and C# have. But they fully support the web, just like Java and C# do. They are on, of, and for "the web".

Here's how you do it: write the server as if any kind of web-able client could consume it. Write the client in Apollo or just Flex to consume that server's resources.

OK? That is not "versus" the web in any way, shape, or form.

Boycott

The marketplace is the only place that will end this MSFT patent fiasco any time soon. The sooner people and organizations *stop* buying MSFT products, the sooner this ends.

I have trouble seeing any other resolution to this. Anyone giving them another dollar is a fool. It wasn't worth it a year ago, and it's certainly not worth it today.

Which of their products is indispensible, again?

What's that? You've completely built your data center to be dependent on Microsoft? Ha, ha, ha!!! You're *kidding*, right?

MSFT Goes SCO On Us

From Fortune magazine...

Microsoft is pulling no punches: It wants royalties. If the company gets its way, free software won't be free anymore...

Microsoft General Counsel Brad Smith and licensing chief Horacio Gutierrez sat down with Fortune recently to map out their strategy for getting FOSS users to pay royalties. Revealing the precise figure for the first time, they state that FOSS infringes on no fewer than 235 Microsoft patents.

It's a breathtaking number.

I guess they are ready to start their war of attrition and tangle some folks up in the courts for a while. I'm betting they'll "lose", not SCO-like since they have a ton of money and a big, ol'revenue stream. But still, they're now firing direct shots at their biggest competitors, not to mention many of their customers.

Of course they have lost already, and this is just the next big milepost of that path. Now it is about how much trouble they can cause as they struggle to find what they should become.

Tim Bray wishfully thinks... Litigate or shut up.

Of course the strategy is to drag out the FUD as long as possible while also racking up legal fees all around. The last thing MSFT wants is to settle or in any way resolve. They know they've lost. There is nothing to do but gum up the works.

The sooner people and organizations wean themselves from MSFT the sooner this will end. Nothing else will be as effective.

On and Of the Web

Apollo is like Emacs and people are thinking all you need is Notepad.

From an interview with Mitchell Baker of Mozilla...

Dan Warne (APC): One does wonder why Microsoft would bother with Silverlight when it is so late into the game.

Mitchell Baker: But it is so critical, I mean we're doing the same thing and we're doing the same thing because Flash - yes it's proprietary so to us that's kind of a problem, but why does it really matter? Well it doesn't live - it is on the web, but not of the web, it's not searchable, it doesn't share all the features of the browser, you can't operate it, it lives in a little box.

That's not the point. The point is a flash (flex) application can access data that *is* on the web, searchable, etc. by any kind of web client software. It's just the flash (flex) application will be easier to develop and more capable than the typical ajax application.

I hope mozilla gets this before too long. The current state of the browser is, well, poor. Before too long, apollo will be a much better platform for writing browsers and other web-based systems than mozilla/xul.

Reading this...

I imagine there are probably efforts to move it out of the box, but to really integrate with the rest of the web, some of those capabilities ought to be in the web client, which is the browser. And so we continue to hope on that front, but also to develop graphics capabilities ourselves.

...I just don't think she *gets* it. Apollo is like Emacs and people are thinking all you need is Notepad. Apollo subsumes the browser. It is not some other thing.

(Aside: The swf file itself (actionscript byte code) is not searchable, etc. unless you choose to provide the source -- it has a "view source" capability, a co-worker showed me the other day. But that's not a good way to provide web resources unless the resource is a swf file you want to execute in a flash vm.)

SlideAware Apologia

The SlideAware folks explain why they chose Erlang, including...

Who needs Oracle/Mysql when you have Mnesia, a free, distributed, in memory database ? The ability to store native Erlang structures out of the box is so liberating: suddenly the need for your object-database mapping layer almost vanishes (well, not 100% to be fairly honest, but a big chunk of it: no need to create a 1-to-n relationship or a n-to-n relationship and a mapping table in many simple cases)

Not to mention that Mnesia supports table replication and is fully distributed, with the ability to add new 'nodes' on the fly. All of this out of the box ! (did I mention it was free too ?) This makes scaling up almost a joke. Compare this to the usual nightmares (and cost) of trying to implement a distributed Mysql/Oracle...

We just introduced the ability to have live review sessions for PowerPoint slides. You basically see other people currently reviewing the same presentation, you can leave real time notes and also have to ability to send quick IM messages. Think about what really happens in the background for a second. Because all of this is real time, every user is constantly going to the server asking "is there any new note/IM message to display" ? Now, we decided to go with a simple polling approach (== no Comet). This means we have to handle a lot of tiny requests/responses. This would be almost suicidal in any other language (or you would need to start adding plenty of servers to support any decent number of users). But not quite so in Erlang since the language was designed for this type of workload... It just scales beautifully (and yes, we still need to add extra servers as well to handle a large load, but just not as many...)

Even pragmatic programmers like it...

This book presents Erlang and functional programming in the familiar Pragmatic style. And, it's written by Joe Armstrong, one of the creators of Erlang.

It includes lots of example code you'll be able to build upon. In addition, the book contains the full source code for two interesting applications:

• A SHOUTcast server which you can use to stream music to every computer in your house, and
• a full-text indexing and search engine that can index gigabytes of data and run either on a single computer or collaboratively on a parallel network. The indexing engine is specially written to illustrate how to maximize throughput on a multi-core CPU.

Mnesia, written *in* Erlang, for Erlang, is a testiment in itself to the benefits of building distributed systems in that language.