My suggestion has been that a 'value added' OpenACS package should start with tWSDL. With the interactive features of a web application, you could provide even more assistance to the developer than what is provided with TWiST. For instance, you could guide the developer through the process of proc selection, type development, testing, documentation, etc. These are the logical processes required to create and document the web service, but the developer doesn't necessarily need to know the details of the API, if they have a wizard type package. BTW, both tWSDL and TWiST are already wizard like since the main function calls simply fill a database and write code, setting up the server, TWiST handles the boring details needed to please tWSDL.
However, if I were to write a quick 'integration' package for OpenACS, it would import the correct version (for the OpenACS package) from the google code repository. After that import, it can then be packaged up into an .apm file for distribution, or maybe the package would simply do the import upon installation. The package would then provide the TWiST API. The next step would be a wizard type interface which would produce a TWiST configuration file.
