Adam writes: > an attribute to prevent some protocols > from being called by js from the internet. I touched upon this briefly, suggesting a theoretical way js could get at local files. TBH, I don't think js should access any of our plugins, period. It fetches files via transport, that's it. I must have been thinking this at a subconscious level, because it's already implemented, at least 3/4. In the following program, zipx://hole.zip@:@talk is a valid url to extract a file from my zip archive. The db3 log follows.

hello world * b create js context 0 css source zipx://hole.zip@:@talk 894 persistent cookies, 0 expired the zipx protocol is not supported by edbrowse could not fetch CSS execute eb$qs$start execution complete js source zipx://hole.zip@:@talk the zipx protocol is not supported by edbrowse could not fetch javascript execute jg at 9 fetch frame zipx://hole.zip@:@talk plugin ebunzip zipx://hole.zip@:@talk text type is ascii create js context 1 execute eb$qs$start execution complete xhr zipx://hole.zip@:@talk the zipx protocol is not supported by edbrowse execution complete 52 * qt 894 persistent cookies, 0 expired As you see, a frame can tap into our protocols, and I wanted that because frames are often youtube videos, and I want to type exp and listen to the video. An approach here might be that frames can run players, but not converters. A frame will never be a word doc, for instance. What do you think? Karl Dahlke