I find the use of binary IMS files a big nuisance.

CoffeeCup has the same weakness. I cannot make "massive" changes involving many edits without tediously recreating the pages. That's why I looked at SiteSpinner.

Have you given any thought to making the IMS files editable with a text editor, i.e. to making the files ASCII?

I know an editable version of an IMS file is not very feasible, but have you thought about releasing the file format (layout). That could open up a world of 3rd party tools to use with SiteSpinner.

I'd love to see either of those options. A very useful "extra" would be a global search and replace. Currently I can do that with a hex editor, but only if there is no change in the text length

I should think an ASCII IMS file would be feasible -- technically, anyway. But third-party suppliers could also be competitors, if VMI chose to incorporate a function supplied as an add-on by a third party. And there is the issue of support when finger-pointing starts.

Also, users might damage the IMS files. But when I worked at Applix, whose Words word processor uses ASCII files, I found this not to be a problem. Occasionally, a customer would mis-use the word processor's scripting language, but no one ever edited the document files directly.

Anyhow, I want ASCII IMS files. So that's my marketing contribution for today!

A worthy idea. As pointed out it would allow people to expand what SiteSpinner can do. However, making the format public would require a significant amount of work. It means, for example that, the format would need to be completely re-written to allow for not only ASCII but human readable ASCII (can't just have a bunch of numbers to indicate options as it is now, etc), all the internal API interfaces must be bullet proofed (rather than counting on our developers to write-out the correct data). It must all be documented. It cannot be modified as easily by us after that. And so on.

My guess is we will probably first put our efforts into improving the usability with, for example, built-in global search and replace of some or all options. But I can see in the future, perhaps some kind of XML format that would be ASCII (or UTF) and self describing.

Yes, changing the file scheme is non-trivial.

How about a stand-alone converter between IMS and ASCII? It need not be bullet-proof; it need only issue error messages when it discovers bullet holes.

Or how about converting HTML to IMS? (My apologies: I've been reading so many forums, I don't remember whether this has been discussed here.)

Perhaps your Developers have "private" debugging tools to display IMS file contents in readable form, which could be productized, or even distributed "as is, no support".

Anyhow, other WYSIWYG web tools use binary, and provide no ASCII facility. It might be an advantage!

OK, consider it now in the laps of the demi-gods for their beatific consideration.