> (Why is the presence of a UI requirement -- above and beyond nsIPrompt,
> of course, which most of our protocols use -- a barrier to entry into
> the hallowed netwerk/protocol/ tree? I'm not unhappy with it being an
> extension, I'm just not clear on what the criteria are.)
The requirement of no 'UI' is a small bullet point. I think the most important
requirement is that
netwerk/protocol is for required or official protocols.
Protozilla is not a protocol. That in itself will prevent it from being in
netwerk/protocol.
Protozilla is a user interface to create dynamic handlers that read/write to external
application's
fd's. For example, if I wanted to, I could create a ls:// url scheme which would map
to the 'ls'
command line application. If I entered "ls:///home/dougt/builds/" in the url bar, a
listing of the
files in /home/dougt/builds would be displayed. Get the idea?
I am not even sure that this is a necko thing at all. It is really tapping into the
bridge between the
URI loader and necko. It just so happens to use the protocol handler to do it. I
think that a better
solution for this part of Protozilla is that it makes use of mscott's external
application handler.
Maybe they could add some of this support to it.
S/MIME Cryptographic Signature