99338 - nsStorageStream is not registered (was nsPipe)

Status: RESOLVED DUPLICATE of bug 235744

(Core :: XPCOM, defect)

Description

[Pavel Hlavnicka]

There is no way how to create instance supporting nsIPipe using XPConnect.
Contract ID ought to be created and registered for nsPipe object.

Comment 1

[Pavel Hlavnicka]

Just FYI.

I can see that you are not in a hurry about this :), so I tried to fix it and it
works for me; I'll send you a patch against 0.98 next week (I hope). I'm writing
this to prevent you to do duplicate work (0.01% I guess)

Comment 2

[Pavel Hlavnicka]

Attachment: patch for 0.98

patch registering the nsIPipe interface

Comment 3

[Pavel Hlavnicka]

Attachment: new header extracted from nsPipe2.cpp

Comment 4

[Pavel Hlavnicka]

Here is my patch. I'm not sure, how many rules I've broken, but it works.

What I've done:

- new header file from nsPipe2.cpp (just copy/paste)
- define contract id & Co in nsIPipe.idl
- exporting nsPipe2.h and nsSegmentedBuffer.h (I modified Makefile.in and
MANIFEST, but I really didn't know, what I was doing; if somebody gives me an
explanation...)
- nsNetModule.cpp - include, constructor def. and registration

I can test only with Linux RH 7.2, no leaks checks done.

If this were helpful and if you could accept it for 0.99, I'd be REALLY happy.

Comment 5

[Doug Turner (:dougt)]

pavel, do you intent to build a product against this interface knowning that it
is not frozen and is subject to change without any notice?  nsIPipe is not
slated for any API freeze and has not gone under any API review.  I would prefer
that this kind of patch be held until the the nsIPipe is at least api under review. 

With that said, I defer to darin.  what say you, darin?

Comment 6

[Darin Fisher]

i agree: nsIPipe is not only frozen, but is very likely to change significantly
before it is frozen.  how critical is this bug?  moz1.2 seems like a fine
timeframe for freezing this interface to me... it's very unlikely that there'll
be time to freeze this by moz1.0.

Comment 7

[Doug Turner (:dougt)]

that should read *NOT* frozen.. :-)

Comment 8

[Darin Fisher]

yes yes.. ignore the _only_ ;-)

Comment 9

[Pavel Hlavnicka]

You know... I don't know anything about freezing interfaces and such processes.
I just need it. We started to use Mozilla for application development and I
found, that some (and pretty important) features are accesible internally, but
hidden from scripting.

Typical problem I solve is serialization/posting XML/RDF data source. Its flush
method doesn't work (and probably never will - according to some discussion I've
read) and the only usable interface method is 'serialize' - taking the output
stream as the parameter. Another interface - XMLHTTPRequest (its send method)
takes input stream. So there is the origin of my need for the pipe.

W/o the pipe the only way is using local files etc. Once I need to send the data
via HTTP 1.1 chunked transfer encoding, the need for pipelining is essential.

I'm surprised, that there are so many I/O object accesible, but pipe. :(

Of course, I can keep my changes private for some time, patch is quite easy and
All what I need is an access to input/output streams of the pipe - I have no
more requirements to the interface.

Generally it seems, that Mozilla is in the state, when it is excellent for xpfe
desing, but using it as an application framework is still a bit limited (e.g.
the thread sync. is an another issue)

BTW I walked trough as many docs found at mozilla.org, mozdev.org etc. as I was
capable, but what I'm missing is some background documentation about project
management (interface freezing...) and source tree/configuration. Did I miss
something, have you some tips for me?

Comment 10

[Kathleen :Brade]

Composer's publishing had to be implemented in C++ because there isn't a way to
have a pipe or create any other stream via JS.

Some day, Composer may want to extend publishing functionality in JS.  It'd be
nice to have pipe and/or other stream mechanisms (nsStorageStream comes to mind
;-) ) registered so that they can be used in JS.

Comment 11

[Darin Fisher]

pavel: for that application you do not want to use a pipe.  that is because a
pipe has limited storage space.  another way to look at is, you have to know how
much data you want to store in the pipe before you create the pipe.  it is
really meant as a mechanism for transfering data between two points... not for
storing an entire entity.  instead, you should use a storage stream.  it is
similar to a pipe but does not place any restrictions on data size.  also
nsIStorageStream has a much better chance of being made publically available
than nsIPipe at this point in time.

this bug should IMO be changed from "nsPipe is not registered" to
"nsStorageStream is not registered."

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, the now-morphed bug was fixed in bug 235744

sounds like in comment 11 darin wontfixed the original bug.

marking dup of 235744.

*** This bug has been marked as a duplicate of 235744 ***