Does Lotus Symphony really need LotusScript support? Redux

July 23 2008

(Sorry for the title only post before, was me setting blogs in the future for writing, and then didn't get to it ... all comments deleted)

So this should be a fun topic. I would like to throw out this topic: Does Lotus Symphony really need LotusScript support? And by support I mean native classes.

My answer right now is No. Here is why.

First, Lotus Symphony already supports the UNO API. For example, you can use the following LotusScript to put text into Lotus Symphony Documents:

Set SM=CreateObject("")
Set Desktop=SM.createInstance("")
Set WriterApplication=Desktop.loadComponentFromURL("private:factory/swriter","_blank",0,args)
Set WriterText=WriterApplication.getText()
Set Cursor=WriterText.createTextCursor()
Call WriterText.insertString(Cursor,"Hello World!",False)

Those who have been to my integration presentations at a conference will notice that this is the same code to automate The UNO API support is a carry over. But most people consider it a real pain in the ass. You are basically pushing Java code thru OLE via LotusScript. Trying to figure out the correct syntax is difficult and ends up being a waste of time. This is not a solution that most corporations will accept.

Then we have the Lotus Symphony Add-in model. The toolkit shows you how to build add-ins for Lotus Symphony. Think Composite Applications. Yep, you are using and writing Java code and dealing with Plug-ins. Oh, and those only work in the stand-alone version of Symphony, not the version that embedded in Notes 8.X Standard (until sometime next year). Yeah, most companies aren't going to accept this as a realistic development strategy.

So I see two options. IBM can either add LotusScript classes to both Notes and Lotus Symphony or they can add JavaScript support. Shocking as it is, I am of the opinion that JavaScript support is the way to go.


First, we can use COM/OLE today. Yes, it is limited to Windows, but it works. But we need something cross-platform. We need something that works inside Lotus Symphony and outside. The outside client needs to be Lotus Notes first, but I can see a need for support Outlook, Apple Mail, and other mail clients. We also need this to work with XPages, because whatever folks want to believe, they are the future of the Notes platform (and yes, there is a future folks .. ignore the people who believe the new shiny object will replace Notes from the earth). There is also this project inside IBM called "Beyond Office" which should not surprise anyone. I have heard this talked about on public TechTalks, so it's not NDA. Think Google Docs based on Lotus Symphony. Developers there will want JavaScript as well.

Now I am not sure how we make JavaScript externally available on all platforms, but I think that is easier with JavaScript that LotusScript. Yes, I know, if we had LotusScript added to Lotus Symphony, we should be able to include the classes like we did with the SmartSuite classes. But that limits us to Notes, and Lotus Symphony has to look outside the Notes world to succeed.

I am the hard-core LotusScript and OLE/COM guy. I loved when Lotus Word Pro added LotusScript. I am just not convinced that is the smart move today.

Ready, Set, Debate!

7 Responses to “Does Lotus Symphony really need LotusScript support? Redux”

  1. 1) Julian Buss says:

    John, I follow your argumentation towards JavaScript. It seems to be the way to go.

    But: for short term success, we need the ability to script Symphony from inside Lotus Notes, for example from agents or from Notes UI events. And we need to do it cross platform.

    So when thinking about JavaScript, the question is: can I solve for example this:

    - a Notes documents opens

    - in the PostOpen I detach an attachment to a temp directory and open it in Symphony

    - I wait (!) my PostOpen until Symphony opened the file

    - then I access bookmarks / textmarkers in Symphone to add text, which I computed from my just-opened Notes document.

    THIS is - from my point of view - the short time goal. The whole integration of Symphony in Notes is useless when I does not have that capability.

    And don't tell me that I could do it via Java and UNO. As you said, UNO is not usable at all if you are not a full time OpenOffice developer who worked with that shit since his whole lifetime.

  2. 2) Dan Sickles says:

    I'd like to see a higher level Symphony API in Java. It would be available to all Expeditor apps and could be scripted from the XPages Javascript engine, which hopefully will be available clent side (Expeditor not just Notes?) soon. You wouldn't have to deal with UNO. It's cross platform and the Symphony/Notes dicstinction is moot.

  3. 3) Richard Schwartz says:

    Let's see if we can reconstruct my previous answer...

    Does Symphony need to be a LotusScript host application, allowing code to run within its environment? No.

    Does Symphony need to allow LotusScript code running in other host applications (e.g., Notes client) to automate its operation? Yes.

    Does LotusScript code need to be able to access and modify data in Symphony files? Yes.

    And one new point, in response to your full post... Yes, it would be acceptable to have the access go through JavaScript, as long as LotusScript code can invoke the JavaScript to do the job!

  4. 4) John Head says:

    I am not sure you are going to get anything but UNO for the short term Julian ...

  5. 5) John Head says:

    The issue with a full Java API Dan is that it misses the target of who typically builds integration apps. It is not the hard core developer, it is the script developer type. Java would be lost on 95% of their target audience. I am not against it, but it is not a first pass support for me

  6. 6) John Head says:

    Richard, I can use LS today, via the UNO API, to automate Symphony. I am talking about native classes, in either Symphony or Notes. That is what I think IBM should skip at this point ... if I can use the the JavaScript API in the Notes client (we agree here)

  7. 7) Rob McDonagh says:

    You know how I feel about JavaScript. I think it's the right language for the future. My only significant question is about the timing. People will need to ramp up a bit on JavaScript before it can fill the sort of need you're talking about. And better JavaScript support everywhere (XPages in the client?) will help that a lot. But there's still going to be a gap. How do we fill that?

    The UNO capability is painful, as you said, but if we had some excellent documentation and code samples, we could live with it while the JavaScript details are ironed out.

Leave a Reply