1 - Nathan - You are definitely missing the opportunity. The LSX toolkit is an excellent way to build functionality into the core Notes product, whereas the Expeditor approach will be adding around the outside. Also, an LSX extends LotusScript (and Java if you like), which is where something like 85% of developers still are. Obviously, I am biased, as my Midas LSX has paid for one kid to get through college and will do the same for a couple more, but I'm not sure that is the wrong kind of biased. I think you, in particular, would be amazed at how cool it is to build functionality right inside where most people work. - Ben

2 - I had posted this over on Ed's site -
I think that the LCLSX tools work, but they are very difficult to use due to a lack of code samples. Andre Girard's sample DB from 2005 is very good, but is so all encompassing that it's difficult to extract the individual methods. Some more examples of common uses of LCLSX would offer the most relief for users of the current tools.

3 - This is good news!.
I started to use the LSX Toolkit a few month ago and found that is is easy to generate the source stub. But it was hard for me to figure out, how and where to insert the needed code to make things working.
There are several samples in the toolkit, but they seem to be not written for end-users.
So , if there were a adequate documentation and some more simple samples, I think the LSXToolkit would be a great enhancement for developers.

4 - I have wanted to use the LSX toolkit on numerous occasions but have never done it due to the simple fact that it was too outdated and that the documentation just isn't adequate. I think that the tool and libraries can be *almost* as cryptic as needs be as long as it is backed by quality document that demonstrates how to install and setup a working development environment. Additionally *real*, documented/commented examples would be nice.

And please - update it for current development tools.

THANKS!

5 - I, too, gave up trying to use the LSX Toolkit because of the dearth of good documentation. I ended up using the C API instead.

@6 - Bob's not talking about LC LSX. He's talking about the toolkit that is used to create LSX's. I'll reserve my comments on LC LSX for my own blog.

6 - In light of the programmability of Notes 8 in the Expeditor context, I'm honestly not sure where LSXs are likely to contribute significant value in the future.

And to be perfectly clear, I'm a HARDCORE Lotuscript guy. But certainly the future direction of that level of control is Java in the client.

Maybe I'm just missing the opportunity here.

7 - - Long ago in a land Far Far Away, I integrated a C-based PKI digital signature system with Notes, and I used LSX to do it. My memory of that project is that LSX is a fairly good system with little or no usable documentation, but Willie Arbuckle filled in cracks for me, so it was pretty good.
- I also seem to recall that the "wizard" to generate the code was essentially useless. I used it for the very first stub, then I abandoned it and coded the remainder by hand, which required quite a learning curve to figure out how all the pieces worked together. I seem to recall in particular having tons of trouble coding methods that accepted a variable number of parameters, which LotusScript quite obviously supports in its native objects. There was some horrible mess with how Variants are handled, and String conversions between LMBCS and C++ left a lot to be desired in certain situations, but details on either have sadly been lost to the mists of obscurity.
- Utlimately I wound up having to instantiate C objects from the C++ ones, and finally reached a point where updating a signature would consistently RBoD Notes. Though a workaround was discovered at LotusSphere that year, the project was scrapped.
- Unfortunate, that, because I really liked extending LotusScript with C++ code. "They" seem to have become soured on the entire idea, because I never wrote an LSX again. (little boy pout)
- I think, after that mono-log, that usability should be paramount. If I follow the documentation I should not be able to stump the actual LSX Toolkit developer with my bug; they guy (darn I wish I could remember his name!!) did find a workaround, but the overall level of the toolkit simply smacked of early beta-ware.
- Still, I miss LSX coding. It was fun, in its own convoluted way. (wistful sigh)

8 - When I worked with LSX toolkit I had problems with debuging. I don't know how to release dll from memory. I had to close LN made a changes in dll (recompile) and then start LN and perform tests with new dll. It's boring.

9 - The Lotus Enterprise Integrator nLCLSX was build using the LSX Toolkit. Lots of caveats ... the toolkit was the root for the early development but it was a "code generation" starting point. Also, that was 1995/1996. Since then, the code has grown and been ported extensively.

some of the reasons for the divergence may have been addressed. At the time, they were a few bugs but the big thing had to do with the richness of objects, object constructor/destructor, dynamic properties, and the volume of code that make the underlying LC API much simpler for the end user.