In an attempt to get you mission critical information when and where you need it the most, a crack team of developers from the Lotus Online Community are working on a new OpenNTF project: MoWiki, a mobile device client and data proxy for IBM Lotus XPage Wikis. Led by Bruce Lill of Kalechi Design, this published-when-it's-done OpenNTF project will result in mobile device clients for Blackberry, iPhone, and Android devices as well as a MoWiki NotesDatabase that will proxy all live-data requests.

The idea is pretty simple actually, leverage the NotesData proxy-capabilities of YellowCake in combination with a consistent-as-possible UI/UX for the major mobile device platforms, all in an attempt to allow quick access to IBM Lotus XPage content while on the road.

(Click thru for more...)

Now that we have RESTful Web Services that we can run with to support IBM Lotus Notes Domino Application NotesData CRUD (Create, Read, Update, Delete)... we might as well push the envelope and create a complete MVC (Model-View-Controller) proxy!

I recently found a need for YellowCake - my never-released (in version 1.0) NotesData CRUD proxy - so I thought it would be an excellent time to put some serious development effort into YellowCake 2.0. This recent need was a multi-developer effort to create a series of Mobile Device Clients for the IBM Lotus Product Wikis. The original intention was simply to add integration hooks into the new IBM Lotus Notes Domino XPage-based Wiki Template. Fairly straight forward really: you need to add additional functionality to an application in Lotus Notes Domino, you crack open Domino Designer.

(Click thru to read more...)

I was asked the other day by a fellow developer if I had an example of a really solid Web UI for creating, reading, updateding, and deleting (notice the order) NotesDocuments in a target NotesDatabase.

My immediate thought was to create a simple NotesDatabase example and download that did just this... but I wanted to make sure that it was something that anyone could apply and see immediate results with... so here's the idea:

• I'll create a really solid Web UI for a data proxy that will handle all creates, reads, updates, and deletes of NotesDocuments for any target NotesDatabase (HTTP-accessible or not) on any Server (HTTP-accessible or not).
• This data proxy will use a series of configuration-styled NotesDocuments to set not only the target NotesDatabase, but what is returned on Read requests, what data is submitted for Create and Update requests, and what should be done with Delete requests.
• As I'm basically re-creating the Domino CRUD API with my own custom CRUD API - I'd do it right: I will allow total separation of UI and NotesData; I will support any and all content types HTTP responses; I will allow for custom HTTP Header responses, including etag support.

This all sounded great. In fact, it sounded like something I had done before... in fact, I had... although it was never officially released.

So before I pour hours into a version 2.0 of Yellowcake - a configuration-based Domino NotesData REST CRUD Engine - I wanted to make sure that there was both an interest and an need in such a solution.

The pitch is this: BYO-UI. I don't care what the front end is; this is an engine that will proxy (and logic-defined handle) requests for NotesData Creates, Reads, Updates, and Deletes. Yellowcake will be more of a Cloud proxy - taking Lotus Notes Client applications to the web within minutes and via configuration versus the need to secure and enable a single Lotus Notes-accessible Only to be accessible not only via any front-end UI, but also from any device and client type that can interact with CRUD API calls.

Thoughts? The more I talk about it, the more interested I am in putting this as the next project on my list - I just want to make sure that there's an interest before doing so...

The typical application architecture for a user client interacting with a Domino application is this:

Simply put, the user client accesses the Domino application - which has been designed/modified to account for the given user client type - with direct reads/writes to said Domino application. The application design requires that security, functional UI elements, and such be built directly into the given Domino application. This architecture is nothing new to Domino Developers, but can often cause issues when a given developer does not recognize the need for separation between data and functional application UI.

The more advanced application architecture for a user client interacting with a Domino application is this:

Basically, the user interacts with a conduit or API that allows an interaction point between applications. Now, this conduit/API is typically pretty hard coded - and you see that with the web service APIs that are out there today. Check out the Google Maps API, there are statically-defined API that allow for some pretty amazing extended functionality. The problem with this approach - you are often afraid to touch anything. The conduit app is fairly hard-wired, designed for this singular need (the given API). This can often restrict both development and administration efforts, as not only is it a chore to expand the scope of functionality in your Domino applications (and forget it if you need to bring in a fresh developer who is not familiar with the given conduit design...), but the admins can't easily move databases to other servers or directories without full-well knowing that it will break something, somewhere, at sometime!

Now what is Project: Yellowcake? Project: Yellowcake is, simply put, a configurable REST API for Domino applications.

I came up with this approach and thought that I had invented the wheel - only to have someone tell me that it was a REST API - or a Representational State Transfer API. So a public thanks to Nathan for that one!

So here are some specifics about just what Project: Yellowcake is, for those of you who are still reading this far into the post...

You - the Developer/Admin, can define an Application Profile. The Application Profile will contain information about the target Domino application - both server and database, as well as allow you to define a specific dbkey - which is to be used as a key for any interaction with this particular application. One of the best parts? Admins can move the database to another directory (or another server for that matter), and all you will need to do is update the Application Profile with the target Domino applications new location! (see that, it's ADMIN-friendly!!)

You can then create either a Query Template or a Save Template for your given Application Profile. While the names should prove the following description unnecessary...

Query Template:
You will define both Content Type (by default, you can return HTML, Plain Text, XML, CSS), the result set formatting, and a given appkey. When the given appkey is invoked - typically via a GET/POST of sorts, the Query Template Author-defined API arguments are passed to the REST API, returning a NotesDocumentCollection from the target database. The Query Template then will iterate through the collection, and merge your result set on-the-fly (think of a Mail Merge), and build your resultant markup.

Save Template:
You will define one of the only static API parameters - docid - and invoke the Save Template via (typically) the result of a Form element's processing agent. The Save Template will then iterate through a series of WebQuerySave-like events that will be evaluated against the target document (defined via a combination of the dbkey and the docid parameter). Currently, the trigger options are running in-line Formula, running an Agent in the target database, or redirecting to a specific URL.

I'll post a few more entries defining the real-world usages of Project: Yellowcake in the upcoming days... while I search for a private alpha team for testing this thing out while I clean up some things...

If you're interested in being on the angel-round private alpha team, please contact me. Otherwise, check back here for more details in the upcoming days...

16ms...

16 milliseconds!

Google took 78ms to load... and it wasn't--

-- but I digress...

I've spent the past three days hammering away at Project: Yellowcake, and I've gotta tell ya - it's been well worth it! I mean, sure -- I crashed a server (once), but that was testing; that's what testing is for!

And a lot of people have been asking me "What is Project: Yellowcake?". I don't think I'm ready to give away too many details on the project as of yet, but some people that I really respect that I've bored with the details discussed this with or even gave a preview, seem to be all-in with the idea. I mean, with statistics like that (16ms!!!)... well, I was amazed myself quite honestly! Maybe they'll feel free to comment on this blog (and they can feel my pain of wanting to shout it all from the rooftops while also understanding that it's not really ready to be discussed in public just yet!!).

While I won't go into exactly what Project: Yellowcake is, I will give you the story behind it's name.

Mike, Tim, and I were standing around chatting while at Islands of Adventure on the Wednesday evening of Lotusphere 2008. In the middle of swapping manly geekly stories...

• Me: (feeling obligated to prove my geekiness amongst Mike and Tim, despite them being two of the coolest guys I've ever met - maybe it was their matching outfits?!) I did X-Y-Z once!
• Mike & Tim: Oh, that sounds really cool. (basically - they're really supportive like that)
• Me: Yeah, would make a great product if I could just weaponize it!
• Mike: Weaponize it?!
• Me: Yeah, right now, it's hacked together. I'd have to give it a go and make it completely configurable to the admin/user...
• Tim: Weaponize - What're you going to do, enrich the Lotuscript?!
• Me: (laughing) - Yeah, we'll call it Project: Yellowcake!
• Me: (few seconds later, grabbing the Blackberry to write this post) ... Hold on a sec!

Wow, my memory must be going - that conversation, despite having only had Diet Coke that evening, is a little fuzzy. It could be all of the coding I've done over the past few days. I think after the three solid days of coding, testing, coding, testing, killing a server, re-coding, and testing some more, I just need some REST!!