Hi MagoArcade, It's nice to see, that the plugin also works in a "real" windows server setting. ... I couldn't test it, since I don't own an IIS server.
Using Windows Auth with an ActiveDirectory setting should be more secure, than the "basic auth", that I did in my videos <https://www.youtube.com/watch?v=tpkQhKyqPzc&list=PLuiC_HFhI4OwoVDb-B-VK0ydj-mBPNn-1>. But with a windows-client only setting I don't have ActiveDirectory set up. .. So basic-auth is the only possibility left. I should have pointed you to the WebDav intro page <https://groups.google.com/forum/#!msg/tiddlywiki/kBfqChfLnRk/EJrgG7zBBwAJ>. Because it shows, that* it should be possible to use server side compression* with this plugin. .. Which imo is important, if your users are on the web. Switching it off initially, as you did in your video is a good thing for testing. In an optimization step 2 it can be switched on again. Saving and reading the file from a local network, doesn't make a difference, since compression also needs some time, which eats up the time savings for network transfer. But it the internet gets involved, server side compression should make the user experience better. empty.html is about 1.8 MByte, because all the js code is contained in plain text, which makes "user hacking" much simpler. ... empty - compressed is about 350kByte. Which makes a difference for web-based users. ----------- a bit of background The TW default WebDav saver uses etags, to create a "modified" warning. Since the plugin was developed with an Apache WebDav setup, which seems to use no compression with the initial setting. The saver worked. ... In the group here, there should be a thread, where users found out, that other environments didn't work: IIS and nginx-webdav I did a lot of experimenting and reading about etags. ... It seems the different server vendors do implement etag handling in different ways. ... So it is close to impossible to create a generic saver, that works with different server brands, server side compression and etag cache handling. .. That was the reason, why I did create the plugin. last-modified and if-unmodified-since header info should be more forgiving, since they basically use the file timestamps to detect a "modified" status. In your video you did enable "file locking", which imo shouldn't make a difference for the client, since TW doesn't detect it. Nice video! .. Now I'll have to have a look at the blog post. have fun! mario -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/50063ca2-69d9-4abf-8103-a52dcd05f868%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
