Skype and the Future (past and present)

A very few years ago CIO's and CTO's were declaring that web applications were the future.  Significant software projects were launched to convert best-of-breed programs from being desktop applications to being something presentable in a web browser - often at the expense of improved or new functionality.

Having spent a few years on such projects in niche financials for medical pricing and business risks, I have a question for top managers who drank the kool-aid: explain Skype.

Skype is not running in my web browser.  It is a desktop application which happens to run over the internet. Had the FCC ruled otherwise, it could even have been ruled in the USA to be telecom software or have been barred from dialing POTS subscribers or cell phones.

It is not always very well-behaved. It does not update in the background.  Smart is not a word that comes to mind.  It is very popular and it is on handheld devices as an application.

Would you want it running in an HTML browser under HTML5?

Why?  HTML pages are delivered over HTTP using TCP/IP.  Text-chat, audio-chat and video-chat software   may run using a protocol which is neutral as to whether TCP/IP is the protocol or UDP or other.

That Skype is a desktop application comes as no surprise to those who continue to use IRC.

Would we ask developers why Eclipse or Visual Studio have not been converted to run in a Web Browser?

At least no one is asking whether Skype is acceptable as an instance of a RESTful architecture.

Someone may want to argue that Skype is a variant of an RIA for some of its more annoying 'features' that come and go.  Because the Skype client app's internet communication protocol is proprietary, a Gnu video chat is due: perhaps it will be RESTful and run in Firefox.

If Skype can be on your desktop, why is the only "browser" on your desktop running HTTP with HTML as the content markup?  Perhaps a million browsers did not bloom, but at least two alternatives to HTML appeared.

What does strike me when looking at opensource web application server frameworks is that they are almost all tightly coupled to HTML.  They are not likely going to survive communications services 3.0 (whatever that proves to be.)

The irony will be when the Chrome browser dissolves into applets running on an OS - applets for which HTML will be the exception rather than the rule for applets doing anything beyond lookup/display, err, 'browse'.

Curl Graphics: extensions packages

There are beautiful page changing options to be seen in the early edition of COM.CURL.EXT over on SourceForge.

These are extensions to the Curl web-content language from www.curl.com and rival anything else available for dynamic business applications on web or desktop.

It is hard to imagine a business having to choose from among ONLY Adobe Air, Microsoft Silverlight and the various Googlisms when the Curl option is now so strong visually (it was always very strong as a framework and in terms of security.)

Other extensions which are not at all eye-candy include spreadsheet-like "worksheet" objects which should interest many of the large corporations already using Curl internally (a third-party package has long been available in Japan.)

Aules evolve

Over at my Aule blog I have a post on evolving an Aule as a "home page" - but one that it is with me and not at Yahoo or Google or AOL.

For some time it has been my habit to set the browser home page to a file on my PC or netbook by using an address bar entry of

file:///c:/webpages/home.html

or

file:///home/grs/websites/home.html

but those should soon go to being

aule.html

or

aule.curl

or

aule.dcurl

as Aules evolve towards being user-defined entry points with access to

remote-astronomy_aule.html

and such.  I had hoped to use a variant of Seaside for Smalltalk to generate these "pages" and another   Squeak Smalltalk framework to make them both portable and persistent.  I am now leading more towards using Robert Parlett's new variation on the Icon language and its libraries as ObjectIcon.  And in time there may be Laurie Tratt's Converge.

Two largely ignored programming options still hold my interest: the Logtalk framework for Prolog (swi-prolog is both constraint and RDF-friendly) and Oz (rules, constraints, dataflows ... )

As Smalltalkers know, it is not just the language, it is the environment, the established patterns - and the ease of testing and debugging.  I will still keep an eye on Seaside for Pharo Smalltalk and watch for Dolphin+Lesser's NG Smalltalk.  But an Aule layout keeps coming back to being a structured String specification to be parsed, persisted and built.  Rebol3 looks to be mired-down (the latest distraction for Carl Sassenrath is running his alpha on an Amiga before that alpha has stumbled into a first beta.  Oh vey ... ) and don't hold your breath for an environment.

Parsing in Icon is almost as fine as in Rebol - and there remains in my back pocket the Qtk for Oz.

No option will be as elegant as a declarative Curl UI in a web page - so they will continue - but as an option.  My next iterations are for Tcl and Ruby links over at logiquewerks.com because the Tcl aule (entry point, home page, portal, mashup) must itself evolve as Tcl 8.6 and TclOO become old-hat.  And Ruby may yet get cleaned up.  And then Java 7 and a VisualWorks 8.  And oh yes - a Rebol 3.

Surge, the RIA platform; Curl, the language

As an enterprise RIA vendor, Curl, Inc. might well opens its platform even further than its recent embrace of SQLite, JSON and AMF.

At that point the Curl language would be just one aspect of their RIA offering.

When a Java developer is learning Curl, I often have occasion to make the reminder that a procedure or a method return is an expression, that is, we use {return} or {return result} or {return asset, valuation}. But I also remind developers to select a word and tap the F1 key in order to take advantage of the Curl Documentation Viewer to take advantage of its live code examples.

If you use Help to open a search in the docs viewer for return you may miss what you would have seen with a simple F1 on a return word in your code. The return word is a macro.

The return macro is defined in the package CURL.LANGUAGE.COMPILER

It may well be that the time is coming when ordinary Curl developers will be able to look at that macro implementation code in that package.

With the new Curl 7.0 library access modifier, it should be possible to expose much more of the implementation of the Curl language to interested Curl developers.

In the long-term, the Curl language should move into the public domain. The return could be macro.

The Future of Curl

Over at Curl I have added some comments to an invitation by Richard Monson-Haefel to weigh-in on improving Curl.

Divining the future of Curl means thinking outside the box. Here's a few attempts.

Pair up Curl as a client-side to Gemstone as has been done by Seaside.

Beef-up Curl on the client-side by getting serious about the future of expression-based languages: if there is not room in the marketplace for ICON, UNICON, REBOL and Curl then look to partner with the remnant of the ICON team at U. of Arizona.

If the Curl team cannot partner-up, then look to go beyond one of those languages by having more effective goal-oriented programming than UNICON or more user-friendly parsing than REBOL.

The option of viewing Curl as a platform and not a language seems to close off many avenues unless Curl, the platform, is able to embrace languages such as ICON which appear to be in need of a new home.

Or is there a niche for Curl in the future of Perl with Parrot, or Ruby with an industrial-quality VM, or distributed OZ?

One interesting place to look is GROK and what they are looking to do with Python ZOPE. That project alone might ensure the future of ZOPE.

Then there is RDF. Somehow RDF has become tied to clunky XML implementations or worse. Even now that W3C has embraced "sparkle" for RDF Data Access, we need not ignore the prospects for Curl as a potentially RDF-friendly language. Prima facie, ICON back-tracking and REBOL paths make either look more promising as a language. But Curl, the platform, could be a powerful starting point for a more language-neutral approach to RDF triples. Mozilla XUL has moved away from RDF (blame XML there, where the 'X' is for 'Xtra-heavy' rather than eXtensible.) The real-issue is how to effectively provide metadata. As more people look to HTML and XHTML itself as the answer, Curl appears to be a natural: Curl has always been metadata-friendly.

Curl CSPD could even be used to help ensure that meta-data that would disclose too much would be suppressed where privacy is an issue (think blogging in China and i-journalism most anywhere.)

CURL6 in the RIA news

There has been good news lately at the CURL.com site with Curl winning the InfoWorld 2008 RIA development platform award and with Richard Monson-Haefel coming on-board to replace the late Marc Orchant.
I continue to try to create the urban legend that CURL stands for {url

My latest enthusiasm is to see features of ICON and UNICON appear in CURL 7 as an alternative to regexp - an extension which would also see back-tracking added to CURL. There must be a way to start that rumor ...

Some other sites seem noticably quiet, such as VistaScript.net but I continue to watch the DLR site of IronPython.

It was also great to see a new Win32 package for IO available at iolanguage.com

And of course there is a lot of activity via the ALTME link of REBOL.net with the alpha-release of REBOL3 ... and that page has a link to Carl Sassenrath's Rebol3 Frontline blog.

Cool Curl 'live' code widget

Over at eclectic-pencil I have a post on a very cool Curl widget that rivals almost anything I have ever seen expand and collapse on a web page.

What I neglect to mention is that in the example, the only code to create the XMl tree is this:

   let xmldoc:XDMDocument =
{build-xml preserve-whitespace? = false, loc}
|| ...
{XDMTreeControl open? = true, xmldoc.root}

Which you would be hard-pressed to beat in Seaside for Smalltalk or in Groovy. Concise.

TiScript also has an alternative DOM and some nice features as a JavaScript alternative, but Curl 5.0 is a mature, full RIA product with 'live' code for inspection and a focus on the client-side. It is almost Smalltalk but it was also built for the web (in fairness, Curl goes about as far back as Smalltalk VisualWave.)

The only cool but alive technologies as neglected as Curl 5.0 must be Gemstone/S and Rebol 2.6.3 ... and the latter is soon to be 2.7.x with 3.0 in the wings ...

Watch for a Seaside for Gemstone/S beta in the news soon ...

PS For people living on AIR and FLASH, Rebol/FLASH went 2.0 today ...

Curl and Occasionally Connected Computing

I have added a page on OCC at wikipedia. What is really interesting to me is the use of a custom URI scheme in Curl. Such a scheme might be

curl://occ/this-redirects-as-needed

which could be used to redirect to a resource depending on whether the user is connected.
If you have experience with OCC, please do contribute to the article. When I have some experience with Curl OCC I will add a page at eclectic-pencil with details and caveats.
To complement the article, I also opened one on CSPD. There are trolls at en.wikipedia.org who delight in suggesting page deletions so your contributions to articles to maintain NPOV or to suggest sensible article merging and separation are much appreciated. No edit wars, please. Solid references for articles are usually the key to survival of any given contribution in my experience.

The Zend of PHP

July 2007 saw the release of the 1.00 'production' release of the Zend Framework. To quote:

The Zend Framework project has developed solutions to solve frequent needs of web application developers, including the following areas:

* Powerful MVC framework
* Database access solution that balances ORM with efficiency and simplicity
* Lucene-compatible search engine
* Advanced I18N support
* Robust authentication/authorization classes and input filtering
* Rich web services client interfaces, including Google Data APIs and StrikeIron
* Many other useful classes to make you as productive as possible
* Thorough and high-quality test suites and documentation
* Open-source development process with an active community provides continuous review and testing

One of the many criticisms of PHP as a scripting language for web development is the lack of enforcement of separation of content from logic. Now Zend proposes an MVC framework for PHP.

MVC (Model-View-Controller) is usually associated with Smalltalk and the thick client even before client-server, let alone the web and RIA. MVC used in conjunction with frameworks such as Struts for J2EE is MVC in name only. The concern is this: keeping domain models and business models from being entangled in presentation issues. The web MVC variant is usually called Model 2 MVC. In Smalltalk, the evolution of MVC to Morphic (from Self) or to M/V without controllers (Cincom Smalltalk Widgetry) is a topic in itself. Dolphin Smalltalk has MVP (Model-View-Presenter) and provides a nice introduction at their Object-Arts site.

PHP starts with a bad rap for not having adequate modularity: it still lacks namespaces. Smalltalk itself is evolving to embrace namespaces and away from classic MVC so we have something curious occurring.

Here is what the Zend Framework appears to offer. I quote:
<qt>
Put simply; models contains your domain specific code such as a user class, views contains your templates, or view scripts as they are called, and controllers contains the files that process data to and from the models and views. Following this simple practice not only introduces a design pattern into your programming arsenal, but also organizes your code in a way that makes it more maintainable than a great many existing PHP applications.
</qt>
What we really have here is the front controller pattern that arose in J2EE in frameworks such as Struts where it is combined with a Command pattern.

In terms of security, PHP with the Zend Framework remains a filtering approach. What is not yet clear to me is how this chaining of filters and validators constitutes a framework. A Framework is not just a library of classes and certainly not a cookbook of recipes. A Framework can usually be understood as providing for the interoperation of services identified with components by enforcing constraints. The constraint might be: this service must be presented as an interface (now you are constrained to implement against a minimal abstraction.)

To have a framework it is not enough to have a class library providing a mechanism which removes ? and & from PHP URL's or adding more filtering.

You may want to check out the Zend Framework site with its webinar and demo wiki application. The site also links to manuals for the API and a developer reference. The latter opens on Access Control Lists; scroll down to find Controllers. What is missing is an overview of the framework such as is readily communicated by the Rails folks promoting Ruby. Having the familiar directory structure in itself does not establish 'convention-over-config'.

Perhaps whether you have 'c-over-c' comes down to 'GUI-shootouts', but that sort of thing does not impress architects concerned about security+maintainability. Saying you are using a 'framework' only goes so far. If what you meant is a library of classes that will be familiar to Struts developers, then why not Java with JavaServer Faces with jars, ears and Maven with the Spring 2.0 framework for security? What ties anyone to PHP in a business setting?

PHP has likley gotten to where it is because it posed no steep learning curve. And then it got a bad case of bloat. What results could be called 'wading through muck' rather than 'slogging uphill'. But when I arrive to perform on a maintenance contract, knowing what the framework was and that it was respected means a whole lot. Knowing what libraries were used gives very little indication of what you are in for.

Example is the Curl developer's example macro

This little Curl script could be the web developer's best friend.
As a web content language, Curl 5.0 provides a powerful RIA platform. This applet using the macro 'example' might convince you.
The macro 'example' creates a live code example in your browser which will open a child applet window.
First we run the following code snippet as an applet in the Curl IDE, embed it as a web applet or launch it with the Curl RTE with a dbl-click in a file explorer.

{curl 5.0 applet}
{applet license="development"}
{curl-file-attributes character-encoding = "windows-latin-1"}
{import * from CURL.DOC.CONTENT.ACCESSORIES}
{example 
{bold Hello {italic there}! }
}

Example is a Curl macro. The result is a web page in which to execute Curl, revert and save Curl applets. It you know something slicker than this, I would want to see it.
You may notice that in my example I have thrown in a {VBox }
I could hit REVERT and I would be back at the original. Here is the result:



If I like my changes, I can save the code from the web page with 'Save Applet'.
In practical terms this also means the ability to create web-based developer documentation with 'live' code snippets. And the eample maco nests: you can have a nippet which is used to demonstrate another snippet.
Curl comes with a visual test framework, but this little 'example' macro should give you a hint of what is possible in Curl 5.0
Note that 'example' is made available by importing the Curl package

CURL.DOC.CONTENT.ACCESSORIES

RIA Plugins: Curl Surge versus Adobe LiveScript/Flash/Apollo

This is just an IOU

If LiveScript/Flash is thought to be the answer for a browser-based commercial software project, then surely Curl must have been considered and eliminated. Likely not.

If a captive audience of cubicle domiciled users is to use plugin-Y, then there is at least a plugin-Z that merits consideration: the Surge plugin.

The Curl case is two-fold for RIA: the 'gentle slope' and the 'one-language-mastery' versus journeymen of many languages and apprentices in more.