don't offer the option to save changes when you are viewing read-only

[zooko]

If you view a tiddly wiki through a read-write capability, like this:

​http://testgrid.allmydata.org:8123/uri/URI%3ADIR2%3Aedsdo6ees7ugabbyyy65635y5y%3Axthwymetpwjs5brmobmcjg7zeld37hdnc6jxyw5crayykraaufma/wimm.html

Then you should have a "Save Changes" button. But if you are viewing it through a read-only capability, like this:

​http://testgrid.allmydata.org:8123/uri/URI:DIR2-RO:kjtsjg4qrpzgjymiupf7qt2beu:xthwymetpwjs5brmobmcjg7zeld37hdnc6jxyw5crayykraaufma/wimm.html

Then you should not.

Note that those are two views on the same file, so for example if you edit and save the file using the read-write view, your changes will be visible in the read-only view.

Currently you get a "Save Changes" button in both cases, but if you try to use that button in the latter case then it fails.

One way to implement this feature -- the feature of showing the Save Changes button only in the case of the file being writable -- would be to parse the URL and see if it is a tahoe /uri/URI:DIR2 URL or if it is a tahoe /uri/URI:DIR2-RO URL. However, it would be too bad if adding this feature made the
!HTTPSavingPlugin become Tahoe-specific, because currently the !HTTPSavingPlugin is entirely general -- any server which respects the simple REST notion that "HTTP PUT to a URL ought to overwrite the resource located there" will work with the current !HTTPSavingPlugin.

So one way to go about it that might be more general is to have the HTTPSavingPlugin do a test PUT when it loads. If that PUT succeeds, then enable the "Save Changes" button. If that PUT gets an error, then keep that button hidden.

[zooko]

Also, when you are viewing a tiddly wiki which is writable, then it should be visually distinct from one which is read-only, to avoid that you accidentally give someone the URL to the read-write one when you thought you were giving them the URL to the read-only one.

[zooko]

Tiddly Wiki already has an option named chkHttpReadOnly. This ticket is basically asking for that option to become cantWriteReadOnly. Instead of disabling the editing features whenever it is loaded over HTTP, disable the editing features whenever it fails to write a test file.

[zooko]

Fixed by [20081211012631-92b7f-3486a89c4cee8c42004e865cef5a93f31b87ce4e].

[zooko]

really fixed nicely by [20081215213214-92b7f-a7a45362ebc3624aa062a0ac3a4523790c249754] and associated patches. :-)