Good to know, thanks. I'm still not sure about these issues:

*-- Does it (for legal usage at least) require the full version of Acrobat on the client machine?


The full version of Acrobat is required to save the form with data. You can however store data to the form in memory and print the form with data and extract data from the form in memory.


*-- Does it work cross-domain, or does it need to? are there any other security considerations that might stop it from working in some user environments for which the app is destined?


I don't know bout using it cross domain. We pass data via xml for cross domain. The xml can be read and then the formfields populated from it manually or the xml can be stored in an xfdf file that matches the formfield layout of the pdf form and loading the xfdf file automatically populates the form fields with the data from the xml file.

... so I'm still interested in pursuing a web services approach. But you knew that.

I like the web services approach too. We are doing something similar to pass data from our parent company to clients for quotes that print out on pdf forms. We could of course use the server version of acrobat and display the pdf in the browser and have the user print it from there. That is the most common approach, but also more expensive.
I'd definitely be interested in learning what you decide to do in the longrun. I know that there is usually a better way to do something and I always want to know what that is! :o)