- From: Maciej Puzio <puzio@zodiac1.mimuw.edu.pl>
- Date: Thu, 11 Jan 1996 15:21:02 +-100
- To: "'Henrik Frystyk Nielsen'" <frystyk@w3.org>
- Cc: "'WWW Library Mailing List'" <www-lib@w3.org>
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. :-) [ snip...snip.. 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 stream? > > [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. Thanks and Happy New Year! Maciej Puzio puzio@laser.mimuw.edu.pl
Received on Thursday, 11 January 1996 09:11:49 UTC