RE: HTBlackHole problem & dealing with stream return codes in HTTee

Hi Henrik,
Thanks for your answer!

> Sorry for not answering _this_ mail before :-) 

That's OK. I'm very glad that my mail didn't get into a HTBlackHole. :-)


  To www-lib@w3.org readers:
  If you don't know what I am writing about, please read previous mails.
  This is a fourth level reply, so I had to cut all the original text to make 
  this mail readable. :-)

> I really would like to let HTBlackHole return HT_OK as it is a "neutral" 
> return value that normally doesn't cause any reaction from the upstream 
> modules. 

To be frank I have changed it in my copy of wwwlib to return HT_ERROR (I have
also changed HTTee implementation to take special care when HT_ERROR is 
sent from a BlackHole). The result code is somewhat tricky, but works perfectly 
well in my application. I haven't introduced any special result code (e.g. 
HT_STOP_BLACKHOLE), as I suggested in my previous mail, because I wanted
to avoid making changes in the whole library (I don't get paid for that, 
unfortunately :-(   ). Still I think that a special result code is a good solution 
(or perhaps it should be HT_ERROR or'ed with some special flag?)

> If the user has pushed 
> "cancel" then there is really no more reason for continuing downloading the 
> file (unless it goes in to some sort of shared cache). The stream prompting 
> the user (HTSaveLocally) can therefore kill the request directly. This should 
> work even if the instance of the HTSaveLocally stream is in fact a part of the 
> request (however, testing it would be a good idea!). As the creation method 
> for the HTSaveLocally gets passed the request object, it can immidiately call 
> the HTRequest_kill() and then just exict when this call returns.

I think this could be a good solution in many situations (in mine too). But please
consider what would happen if HTSaveLocally stream were not a primary

> > [snip...snip...]
> > Here's the problem: bitflags [in stream return codes] won't allow you 
> > to indicate the importance of each return code.
> But the upstream module can then check for both codes and then decide what to 
> do... The important thing is that both codes (or in general all codes in case 
> of multiple T streams) get propagated upstream.

I need to think about that.

> > My proposition:
> > [snip...snip...]
> > 2. Who knows what the importance of a stream is? The function which created it,
> > of course. So, the function which creates HTTee and then attaches two streams
> > to it should pass HTTee a special callback function as a parameter. This callback 
> > function would be used for resolving the stream return codes conflicts. To ease 
> > programming, HTTee should have a default resolving function, something similar to 
> > merge_results in Hakon's version.
> Not a bad idea. 

Thanks. :-)

> The resolving function could also be a direct part of the 
> upstream module which will be activated each time the T stream returns. As I 
> see it, both ways will do, but maybe a callback function is a more flexibel 
> solution.

I've got a point of view on it, but I need to think a little.
I'll write to you soon.



Happy New Year!

Maciej Puzio