Do we really want to overload XMLHttpRequest with "comet-style"
functionality?
XMLHttpRequest is already used for "comet-style" functionality and with
interactive mode supported in several browsers, it is currently may be the
most heavily used and functional transport for server-initiated messages,
and is undoubtedly not going away anytime soon. Even if the multipart
support as implemented in Mozilla is not standardized in XMLHttpRequest,
there is one very obvious problem that multipart support solves, that needs
to be addressed. With interactive mode streaming in XMLHttpRequest with a
continuous long-lived response, there is unbounded memory growth as the
collective sum of the stream of messages continually grows since the
responseText continually grows. If multipart support is not added, would it
be possible to include a resetResponseText() method that would reset the
responseText and allow memory to be reclaimed? Or alternately, responseText
could be a settable property, where newly received content is always
appended to the end of the responseText, setting it to an empty string would
effectively reset the content and allow memory reclaimation.
However, I still believe it would be preferable to actually have real
multipart support.
Thank you,
Kris
