[ Home | GoingWare's Bag of Programming Tricks | Michael David Crawford | mdcrawford@gmail.com]
I'm afraid this page is,
as they say,
Under Construction
For now I'll just give you the basics.
Word Services allows any application that edits text, such as a word processor, to use the services of any application that revises text, such as a spellchecker.
It has the significant advantage that the user need only have one spelling dictionary. When new words are added to that one dictionary, they are available to all Word Services clients.
Perhaps more importantly, the user only need learn to operate the user interface for a single spellchecker or a single grammer checker, rather than the many different UIs they'd face if the spelling or grammar checkers were all built into each individual word processor, grammar checker and spreadsheet, as was the common practice before Word Services was invented.
You'll need the Word Services SDK.
The SDK contains the protocol specification, tutorials and sample code for both the BeOS (including Haiku) and the Mac OS (including Classic and Mac OS X).
I'll do my best to upload it this weekend. :-D
Word processors, databases and spreadsheet are known as Word Services clients.
Spellchecker and grammer checkers are known as Word Services servers .
Developers of client applications don't need to pay any license fees for OEM spellcheckers, they don't need to debug OEM spellchecking SDKs, and they don't need to worry about OEM SDK vendors failing to provide bug fixes, ports to new platforms or support for operating system upgrades.
All client developers need do is support the protocol defined for the platform their application runs on. A standards-compliant client program will work reliably with every standards-compliant server.
Developers of server applications don't need to sell OEM kits to all the myriad word processor, spreadsheet and database vendors. You'll save tons of money, what with the expense of marketing, dedicated sales staff and developer support headaches.
Instead, you'll market your product - just one version of it, for each supported platform - directly to end-users.
You also won't need a different SDK API for each kind of client software architecture - just one version of your application for each platform you support.
All server developers need do is support the protocol defined for the platform their application runs on. A standards-compliant server program will work reliably with every standards-compliant client.
Clients aren't limited to word processors, spreadsheets and databases. Similarly, servers aren't limited to spelling and grammar checkers. In principle, any sort of software that operates on text could be either a client or a server.
Word Services is presently defined for four different operating systems. In each case it uses a platform-specific inter-application communication protocol.
In principle, Word Services could be defined for any operating system provided a suitable communication method is provided.
For example, Microsoft COM or CORBA would both do just fine, as would Unix-domain sockets or even TCP.