The extension I’m going to focus on this week is the  YUI Media Player. The Yahoo! User Interface (YUI) Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Media Player is a javascript/flash application which recognizes all links to mp3 files in your web page and embeds a player into the page. This decreases the dependency of the user’s local applications to play the mp3 file along with giving a great user experience.

To install the YUI Media Player follow the instructions here. Once installed add the following code to any Deki page that has mp3s attached or linked on:

{{ yui.mediaplayer{} }}

The extension will take over from there and automatically add a play button next to your mp3 links and expand a player on the left side of the screen like the following:

To see the extension in action check out the documentation page.

If you have any questions please feel free to contact us.

Have you ever wondered who is the best person to contact within an organization? Whether it is sales, partnership opportunities, or just trying to make a connection; the new LinkedIn extension for MindTouch Deki will help you with that.

To start follow the steps here for installing the LinkedIn extension.

Once installed you can add the name of the company you are looking for into the Extension and and find the contacts that work their. Here is an example:

Paste the following into a MindTouch Deki page(LinkedIn Extension needs to be installed first):

{{ linkedin.companyinsider("google", "noborder") }}

Once entered you will ge the following output:

You can even take it to the next step and make a dynamic form that will update the extension so you don’t have to change the code everytime. To do so you would paste the following code into your page:

 Enter the name of a company to check your insider connections:

{{ dhtml.form{inputs: [ { label: "Company", value: __request.args.company ?? "mindtouch",

field: "company" }], button: "Find", publish: page.uri} }}

Then paste the following code right after the above code:

{{linkedin.companyinsider(__request.args.company ?? "mindtouch", "noborder")}}

This will look as follows:



Now you have a dynamic field that anyone on your team can enter company information into and it will bring up details right away.

If you have any questions please feel free to contact us.

OpenGarden.org has finally taken its rightful place as the MindTouch Developer Center. For now, not much has changed except for the new address: http://developer.mindtouch.com. Your login continues to work and your bookmarks are redirected automatically. But in the coming weeks and months, we’ll be giving MDC a facelift and a new structure that will make it easier to find, contribute, and connect with fellow community members.

Why are we doing this?

There were really two needs I felt we had to address. First, the artificial dichotomy between OpenGarden and MindTouch created a semblance of a two-class structure: MindTouch and the Community. This was never the case, as we all know from our active collaboration on the forums and the wiki. Yet, appearances matter sometime. This small adjustment simply makes it clear to new members that we are one family.

Second, there was some overlap in content between MindTouch and OpenGarden, which caused confusion as to the purposes of the two sites. MDC will be specifically tailored to address the needs and wants of those who want to get the most out of MindTouch Deki: its capabilities, its extensions, its API, and its multi-platform support. To that end, the new structure will make it easier to discover the full set of features, as well as provide an equal home for contributions from MindTouch and the Community alike.

The MindTouch Developer Center is a long-term investment. Its build out will continue over months and years. And it will happen in small incremental steps so that everyone can participate to move it in the right direction.

I’m looking forward to creating with your help the best place for learning and sharing everything there is to know about MindTouch Deki!

In preparation of the upcoming big release of Deki Wiki v8.05 “Jay Cooke,” we’re also releasing updated versions of MindTouch Dream and SgmlReader.

MindTouch Dream 1.5.2

MindTouch Dream is a .NET REST framework for developing lightweight, highly decoupled web-services. It runs on Microsoft .NET 2.0 and Novell Mono 1.2. Dream is the foundation for web-oriented architecture of MindTouch Deki Wiki. Learn more about Dream here.

• support for ICredentials with Plug
• support for IPv6 based network addresses
• support for HTTP Range headers
• enhanced methods for manipulating XML documents with XDoc
• improved performance for deployments with large number of aliases
• removed status filters on service features
• and other bug fixes

MindTouch Dream 1.5.2 is available for immediate download from SourceForge.

SgmlReader 1.7.3

SgmlReader is a versatile .NET library written in C# for parsing HTML/SGML files. The original community around SgmlReader used to be hosted by GotDotNet, but it has been phased out. MindTouch Dream and MindTouch Deki Wiki use extensively the SgmlReader library. We found and fixed a few bugs in it as well. In the spirit of the original author, we’re providing back these changes.

• never close the BODY tag early (can cause loss of content)
• remove “<![CDATA[" inside CDATA sections
• remove "]]>” inside CDATA sections
• convert elements with invalid tag names into text (e.g. <foo@bar.com>)

SgmlReader 1.7.3 is available for immediate download from SourceForge.

Hi, this is Vivien.

If you’ve popped into the Dream page recently, you’ll see that Steve has nicely reorganized the whole thing so that configurations, tutorials, specs, and services are easier to locate. For the past month or so I’ve been working on two tutorials that act as a way to show users how to use Dream and the advantages of using Dream.

The tutorials are: Building a Web Scraper with Dream(which uses the Dream library) and Building a Web Scraper without Dream (which uses the .Net libraries).

Experience-wise, making the two tutorials were interesting because of the vast difference in the amount of code and hassle to get the exact same thing setup. I had initially started off building the Web Scraper using the Dream library, it was nice, easy, and everything I needed was right there. Unfortunately, this led me to the assumption that building the Web Scraper without Dream would be equally as smooth. I could not have been more wrong. Building the latter was like pulling teeth as I realized that I had to add in yet another arbitrary class yet another library. The code just seemed to grow exponentially, along with all the extra fiddling around with XSLT just to get HTML conversion working. All in all, the latter was quite annoying to deal with. So, unless you’re getting paid by lines of code, I would definitely recommend using Dream for ease of programming and less code.

This morning I read Objects at REST written by Rick Jelliffe. It’s an article about how object-oriented concepts can be mapped to REST.

I don’t agree. The similarities between REST and object-oriented software are far less than their differences. REST is set of design principles that decouple software systems in a flexible and scalable manner.

First, REST is about resource representations and stateless protocols. In order to achieve stateless protocols at the object level, all engineers would need to stop using interfaces as they are designed today or rely on something like Software Transacted Memory (STM), which is heavy and doesn’t solve all the inherent problems.

Second, pretty URIs are not relevant. It’s something for humans to enjoy. If you have them, great. If not, it’s irrelevant. Sub-structure relationships are discovered by interaction and never constructed unless told so by the source representation (through a form or code-on-demand). This insulates the client from hard-coded information about the server’s topology. Something, the client shouldn’t know anything about anyway.

Third, not all objects are equal. The first wave of object-oriented programming was about class inheritance. The second wave was about matching interfaces at the instance level only (prototype inheritance). Notice how both have to do with generalizations, not instances. REST cares about the instances and not the mechanism used to create them. You can use structured programming or object-oriented programming to implement your web-services and web-applications. Again, the methodology is not relevant, only the properties of the running system are.

Lastly, and most importantly, is the guaranteed decoupling of the resource’s state from its representation. This means that you have made the major leap already where the consumer’s view of the world is decoupled from the producer’s view of the world. And certainly, this is where REST has made it’s mark. This is how the web works and why it works! In object-oriented design, programmers fundamentally think about sharing objects. This is relevant, because it ties back into the first point. Avoiding state entanglement in object-oriented systems is hard because of the high degree of interconnectedness of objects. In REST, on the other hand, everything is decoupled since the bits are never directly manipulated, only their representations. Hence, this problem is avoided altogether. This is important, because it’s a hard problem to solve after the fact.

In short, mapping concepts from object-oriented programming to REST will make people think about it in the wrong way and therefore do more harm than good.

MindTouch Dream is designed from the ground up to enable developers to build their applications and services in a RESTful manner. We recently put a technology page on our main website that explains the architecture and its motivation.

Beyond web-architecture, I’m also a believer that the REST architectural style will enable us to build better software for multi-core machines. REST web-services already have the properties that are desirable by high-performance CPUs: safe out-of-order execution (stateless protocol), no shared memory (message based), and uniform addressability (URIs).

Lots to think about, just don’t think about objects when you do so!

As you might already know, all Deki Wiki functionality is exposed through a service API that can be invoked via HTTP requests. I have developed several client applications that consume the Deki Wiki API, such as the Desktop and Outlook connectors. During the development process, I was wishing for a tool to make it easy for me to view and experiment with the API… so I decided to write Apitest.exe.

Apitest.exe is a Windows application that enables users to view a list of all service features/parameters and invoke them. It works with any Dream service, but I mostly use it with the Deki Wiki service. To run Apitest:

1. Install Dream SDK & Source
2. Navigate to the install destination and copy \src\mindtouch.apitest\DefaultData.xml to \redist.
3. Launch redist\mindtouch.apitest.exe
4. Select File->Load Blueprint From… and enter your Dream service location (for Deki Wiki, enter http://<hostname>/@api/deki)
5. You are now ready to try out any of the service features!  Note: if you’re connecting to the Deki Wiki API service, many requests require an authenticated user; it is a good idea to first login. Select Get:users/authenticate, enter your credentials, and Submit. In the results tab, you will see the headers and data returned from the request.  All subsequent requests will be made with these credentials.

Over the past few days I’ve been grinding away on the most comprehensive written explanation of MindTouch’s technology completed to date, at least, high level laymen explanation. I finished it today and then Steve polished it and added a couple sections.

Technology - MindTouch
MindTouch is the developer of Dream and Deki Wiki. Dream is a Distributed REST Application Manager that Deki Wiki is built on. Deki Wiki is a wildly popular wiki, but it is much more than just a wiki. In fact, Deki Wiki is a wiki interface to a composition of loosely coupled web services that serve as a distributed application platform. Meaning, users of Deki Wiki get the immediate value of a wiki: improved collaboration around text, file, and email, but are also able to connect and mashup systems, databases, external services, and Web 2.0 applications in the form of composite applications and data mashups. This is achieved while still allowing a site administrator, presumably an enterprise IT professional, to provide governance of the data and services that users can access. The end result is a user-centric interface to data that is dynamically generated from data silos and the ability to create business user specific applications (situational applications).

I encourage everyone to read the full write-up. The quote above is just the abstract and the article should be accessible even to the less technical reader. I’m amazed at how far ahead we are of anyone else in this emerging space. Our technology is easily a couple years ahead of anyone else and there are some very big companies entering this space including IBM, BEA, SAP, etc. I know we have a brilliant team, but in comparison to the big boys our resources are just a drop of water in an vast sea.

I frequently marvel at what we’ve built, but what I find even more amazing is how we’re dominating the market. Primarily because I’ve always known we have a team of amazing engineers, but I guess I never realized just how damn good we are about getting the word out. Case in point, there isn’t any vendor that is seeing the kind of distribution and adoption that MindTouch is driving. To be honest it is shocking when one realizes how much more market penetration MindTouch has. I knew we could build some bleeding edge technology, but I hadn’t thought we would be equally successful in marketing it to the extent and as quickly as we have managed. Especially since it’s been entirely organic. People find our software by searching for “MindTouch” and “Deki Wiki”. Our SEO is atrocious. Anyway, if you look at only our download stats at Sourceforge you’ll see we’re driving around 1100-1200 downloads a day. It is important to note that this only accounts for a portion of our total distribution. Deki Wiki is now in several build systems and other people are regularly redistributing our software from places other than Sourceforge. MindTouch Deki Wiki is being distributed well over 2,000 times a day! There is no other vendor even remotely close to this in our space. What about adoption? Well, I looked at some stats earlier this week and I was stunned by our total count of unique users. That is to say, it was more positive than I ever imagined. Of course, we can only count a percentage of the total unique users of Deki Wiki, but we have a really good idea what percentage we’re counting. As I said, I was stunned and very very happy with what we’ve accomplished in this first year and half of Deki Wiki being public. I will announce these numbers at a later date.

Now it’s time for the obligatory “thank you”s. Credit to the Gardeners, these are the folks that have been spreading the word. It certainly wasn’t due to any PR or advertising efforts on our part because MindTouch just began these campaigns near the end of last year. So, MindTouch users and customers please continue to spread the word and we’ll continue to make kick ass software.

MindTouch Dream is a .Net library for REST-oriented programming. It ships with a REST micro-server for Windows and Linux (thanks to Mono) that can be embedded into applications or used as a standalone .Net REST web-server. Dream is open source, written in C#, and licensed under LGPL. You can download Dream “Emerald” 1.5.0 from SourceForge.net.

Dream “Emerald” is the follow-up version to “Denim” which shipped last September. Since then, we’ve done many improvements to this versatile library and server. The mission of Dream is to make REST-oriented programming as simple as possible without introducing abstractions that obfuscate the versatility of HTTP. Dream includes classes such as Plug and XUri that make the WebRequest and Uri/UriBuilder classes obsolete. They promote better programming practices and require less lines of code. Similarly, the XDoc class is a generalization of XmlDocument, XmlNode, and XmlNodeList that streamlines direct operations on XML documents, alleviating the need for generated wrapper classes.

Dream also provides a concurrency and asynchronous execution library that enables efficient programming. Most of the complexity is encapsulated through the versatile Result class, which acts as synchronization point for future results.

Dream includes a REST micro-server that can act as a standalone host or embedded into applications to provide a REST API.

Improvements in Dream “Emerald” include:

• performance tuning
• memory footprint tuning
• simpler instantiation of the host service
• XDoc diffing and 3-way merge
• catch handlers for asynchronous operations
• eliminated all uses of NameValueCollection (it’s slow, a memory hog, and buggy)
• support for independent culture per request for multi-lingual services
• much improved support for instantiating objects from a database catalog
• and many more…

Dream is robust and well tested as it lies at the heart of Deki Wiki, the most popular vendor-backed wiki platform.

Let us know about your Dream projects on our our forums!

In previous posts (here and here), I introduced the building blocks for asynchronous programming in MindTouch Dream. In this post, I want to introduce the Async class, which provides common methods for asynchronous programming.
(more…)