William Bardwell wrote:status flag "FROZEN" will not change. You can grep for something like this:
In general, you can do this. Pull a 1.2.1 tree. Any interface marked with theI am trying to write some code using the necko socket (and HTTP) code, but I was a bit supprised to discover that 1.2.1 (which matters to me because it is what RedHat is shipping) has some async IO methods on nsISocketTransport, but doesn't have nsIAsyncInputStream, and for newer Mozilla's it is the reverse. Are there any async IO interfaces for sockets that will work in 1.2.1 and now and in the future?
@status FROZENYeah, this is a good theory, but as far as I can tell 1.2.1 doesn't have
enough frozen interfaces to do async socket IO reading and writing
with only frozen interfaces...
(nsIStreamListener is frozen, but the nsIStreamProvider that was in 1.2.1
isn't (and it was removed in more recent versions), and as mentioned above,
those interfaces have similar problems...)
And unless I am missing something, it looks like there are STILL not enough
frozen interfaces to do async IO with sockets using only frozen
interfaces... Am I missing something?
Alternatively, you can just use the SDK for 1.2.1:William Bardwell
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.2.1/gecko-sdk-1.2.1-win32.zip
There isn't a linux version of the SDK, but this will list the interface that were frozen at the time 1.2.1 shipped.
Regards,
Doug Turner
[EMAIL PROTECTED]
_______________________________________________
Mozilla-netlib mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-netlib
I presume you're coding at the C++ level. If you were interested in coding at the JS level, there is a pretty good wrapper library called "jslib" that provides a more stable socket API.
That said, I do not expect major changes to the current necko stream API. It's probably time to stamp a bunch of those interfaces as frozen. There are still some inconsistencies in the interfaces, such as when a nsIEventTarget parameter appears and when it is assumed that the calling thread's nsIEventTarget will be used. It would be nice to clean up that issue.
At any rate, it is OK to use non-frozen interfaces in C++ code provided you always verify the IIDs of the interfaces you need. For example, when you call CreateInstance, you pass the IID of the interface you want to use. If you are trying to get access to the nsISocketTransportService, then CreateInstance would fail in a future build if the IID changed (corresponding to an interface change). This means that you should be very careful to catch and handle all errors when dealing with non-frozen interfaces. You could have some code issue a warning to the user telling them that they need to upgrade your extension.
I know this is far from idea, but hopefully it helps a little bit.
Darin _______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib
