NOBODY SUMMONS MEGATRON!!!
Remember when I said there'd be some exciting news here this week? Well, it's time.
Bob Balaban posted on his blog a few weeks ago about the idea of a data-only URL API for Domino, where you could retrieve the DXL for a document directly through a URL. This was an idea I had discussed directly with Bob before he ever posted about it (and I'm sure I was FAR from the first one to talk to him about the idea) so I'd already had some thoughts about this cooking around in my head. Well, shortly after that conversation, I thought of a very simple way to use Internet Site substitution rules to capture requests for data content through a broker database. I told Tim Tripcony about it, and two hours later, he had a proof of concept in place.
Well, lucky me, Tim also decided to come work with Lotus911. So we had an opportunity to take that proof of concept and turn it into something real.
The basic concept is straight forward. We want to be able to use standard Domino URL syntax, but with a different argument to return the DXL, like so...
http://server/db.nsf/view/key?ReadDocument
But to return the DXL content, we need an agent call to actually perform the action. Enter substitution rules...
/*/ReadDocument* --> /nathan/dxlbroker.nsf/broker?OpenAgent&OrigURL=*/readdocument*
Now we have an agent call with a pointer to the original syntax. And our agent can take the QueryString, parse it, and return the result as DXL. (Note: we didn't actually use ?ReadDocument, as substitution rules apparently can't redirect arguments. We used an additional forward slash instead.)
Once we do that, why should we limit to documents? Why not have...
http://server/db.nsf/form?ReadFormDesign
Which leads us to another substitution rule...
/*/Read*Design* --> /nathan/dxlbroker.nsf/broker?OpenAgent&OrigURL=*/read*design*
Now we use these rules to send to a central NSF with an agent that parses the QueryString and send back the DXL. But what else might be useful to do with that? As long as we're working with a DXLExporter, why not use the pipelining capabilities of the parser and be able to do a transform? All we need is a source Stream to plug in.
So we added the capability to store XSLTs into the broker database, which would handle inline transforms via XMLProcessor pipelines.
http://server/db.nsf/form?ReadFormDesign&Stylesheet=ItemSummary
And with that, we'd created our transformer. Decepticon, REST-bot in disguise!
At that point, I started to get concerned about performance. If someone really wanted to use this as an AJAX tool to extract design and data DXL from Domino, would we end up with 50 million URL requests to export, transform and deliver names.nsf/Person/ReadFormDesign? Yuck!
Logical choice: implement a cache. Store the resulting XML output into a notes document that can then be served up the next time a request comes for the same URL. The Domino Command cache already does something similar, except we're just putting the cache into a document in the Decepticon database!
We're still tuning this part, but you can get our beta version of Decepticon at OpenNTF.org!
More to follow here soon!
Comments
just my 50 cents:
1. idea with cache is good, but you should also take care about user rights, hide-when formulas, computed sections, etc.
2. i have implemented a similar approach in august 2006 for a small project (not finished because I got a job not related to development, but I have a working version
3. another approach is to evaluate some of hide-when formulas and computed text when XSLT (or other) transformation occurs, unfortunately this is not possible in all cases, but may be I'm wrong.
Posted by Egor Margineanu At 06:02:09 PM On 05/24/2007 |
Posted by Lance Spellman At 08:01:23 AM On 06/13/2007 |