Chris Waterson wrote: > Right now, it's hacked to only let `file:' URLs be flushed. At the time > I implemented it, there was no way (that I knew of) to do an > asynchronous HTTP write transaction. (I'm not even sure I know what HTTP > transaction I should be doing here. PUT? POST? Would Necko take care of > everything if I just did AsyncWrite() on an HTTP channel?) Anyway, it > might be possible to remove the hack now and implement this... > > chris > nsIChannel::AsyncWrite is actually going away in the near future. For a detailed discussion of why, see the various "channel" threads on n.p.m.netlib. Since HTTP is a transaction oriented protocol, instead of AsyncWrite'ing data someplace, you'd much rather tell HTTP where to find the data for posting. This is done via nsIHTTPChannel::SetUploadStream. In this case, you are free to generate the stream bytes on the fly as the HTTP channel requests them. There is little difference between the POST and PUT method. If you call SetUploadStream with a non-null value, the HTTP channel will use the POST method by default. You can alternatively set the method to use via nsIHTTPChannel::SetRequestMethod. So, the stream you wish to upload is made available one chunk at a time? And, you want to feed this data stream to HTTP some way? There's not really a good way to do this as the data streams in. Your best bet would be to buffer the data someplace and then hand off that buffer to HTTP for uploading. You would not want to start posting until after all data had been written to the buffer. In the future, I am thinking about adding another way to upload data to an HTTP server. Consider a nsIHTTPChannel::SetUploadStreamProvider method that takes a nsIStreamProvider. The stream provider would be called by HTTP for data after HTTP had written out the headers. The client would be handed a nsIOutputStream, roughly corresponding to the socket, whenever the socket becomes writable. In this way, HTTP would not be responsible for buffering data :-) You could maintain a pipe between the upload stream provider and your own data source. Darin > > Fabio Trevisani wrote: > > > > Hello, > > I'm trying to use RDF in/out operations in a XUL interface and > > everythings works as expected as longer as I test it locally. My goal is to > > have the files on a web server, so I've moved them (three files: tree.xul, > > tree.js and tree.rdf) on my home web server : > > http://cern.ch/Fabio.Trevisani/xul/tree.xul > > But now the data isn't modified anymore, or at least it looks like it is > > not sent back to the server on the Flush() command. I went through the > > various documents on RDF, security, XUL, etc... and also checked the access > > rights on the server, but still this small example doesn't work. I should > > have missed something very basic. Could someone help me ? > > Note that there is no error message appearing in the JavaScript console. > > > > Many thanks, > > > > Fabio Trevisani
