You could fire the service asynchronously, and use postmessage to update the client with progress. You need to pass $instancepath:$instancename to the service to provide a reply address to send the messages to. When the final message is erached, you can either pass the results back via postmessage, or fire a second operation to fetch them from the service.

What I usually do in those cases is launch a form with a progressbar that shows estimated finish time. Actually, this forms shows: - progress bar - init time - estimated finish time - remaining time - customizable message The service executes the form with the number that expresses what means 100% for the process (for example, occurrences to be processed) and a customizable message. Then, when you want, the service sends progress info using postmessage statement so the form refreshes itself. Or, cheaper but uglier, message/hint "Processing 5 of 10000"

javascript API's communicating from the service back to the client session and then displaying some kind of busy 'throbber' on the client using the HTML widget?

Colin said Before services it was easy just display a message every 100 or so records. Now, of course that can't happen.

Hi Colin, can you explain a bit more why messaging was possible before you changed it to a service? For me, it's still not clear what you really do right now: running a synchronous service on the client? No need to make it self contained, so you can use your messaging as before. running a self-contained service asynchronous "remote" on an apppication server? - you can use postmessage as described because on your client the structure editor is still active and handles the ASYN. - or you can use a UTIMER as a pulse to inform the user until you get the "finish" postmessage from the service