|
|
|
|
|
The computer- and software business are quite similar to most other businesses! Whenever man finds a problem, he tends to want to overcome the problem, or make it easier to live with. This basic "problem solving" also goes for API developers! So, if the Notes C API is complex, there are other ways to get goin'.
First and foremost LotusScript is there to help. As a Visual Basic-like, interpreted language it utilizes many of the same areas as the Notes C API, and it hides the complex structures in easy-to-understand-and-use methods and properties. This is good!
However, LotusScript doesn't expose all of the Notes C API, because of many reasons. First and foremost because of it's language model, not all aspects of Notes core design has been "converted" yet. For example do we see a fairly slow transition in the area of Rich Text. The first versions of LotusScript did not have many features working with rich text. This has graduatly become better over the later releases, and now you can do a lot of different stuff. There are however still many limitations.
Ok, what to do next then ? Take a look at the Notes C++ API. It's logic closely resembles the LotusScript way of working with Notes data, but are exposed with more features. Shortly put, one could say that C++ API is somewhere between the raw Notes C API and LotusScript.
But then there was speed.... Even if LotusScript has become fairly fast over the years, it's still interpreted (or semi-interpreted via it's so-called tokenized images). Heavy operations involving working with large numbers of documents or large documents may bring LotusScript to a painfully slow model, especially if LotusScript is put in an scheduled agent which runs often! With the C++ API you can create compiled (no interpretion here) applications working through the documents much faster than LotusScript.