"R. Saravanan" wrote:
> In the long run, the code probably belongs in netwerk/,
> but this would need to be approved by the Necko module owner.
> In the short run, it may be better to let it sit and bake for a
> while as an extension. Although it needs to be reviewed for
> code quality by the Necko folks, it should need approval only
> from mozilla.org.
>
> It is true that if extensions/ipc is not turned on by default, the whole
> exercise would be pointless. So I expect it will be added to the
> list of default extensions, rather like chatzilla. However, I believe that
> if the compilation of an extension fails, the build continues without
> the extension (I haven't checked this; could someone confirm it?)
>
> If and when mozilla code outside extensions/ starts using IPC, it would
> make sense to move it all into netwerk/.
Here is what I am thinking after digging into protozilla this afternoon. There are
two significate ideas here. First is process related stuff, invoking an executeable,
getting and recieving stdout, stderr and setting stdin, ect. The second is a method
for adding generic protocols plus a UI for it.
I think that the way this best can be intergrated into mozilla is that the process
related stuff be cleaned up and migrated into the nsIProcess interface in xpcom.
(http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl). I am the
owner of this file, and would be happy to help with the oversight of these changes.
The second part is interesting. I believe that there are two things that we can do.
First we can see about getting this to be an extension. I do not believe that this
is a core protocol so it does not belong in necko. To address the mailto: lack of
support, I think that we should leverage what we have and specifically address this
protocol.
As for defaulting this component/extension on, that should be a seperate discussion.
(baby steps)
How does this sound?
