On Sat, 28 Feb 2015, Michiel van der Vlist wrote to mark lewis:
MvdV>> When I am hunting for a file, I do not want to wait for the
MvdV>> other system to call in.
ml> when you've made the req, there is no more hunting... you've already
ml> found it and requested it from a/the system that has it...
MvdV> From my POV, the hunt isn't finished until the file is in my
MvdV> inbound. The other system may advertise it has the file, but I do
MvdV> not know for sure until it is confirmed.
true... in hunting that's called a missed shot but one may or may not try again
on the same target... they may move on to another or give up altogether...
ml>> we used to do that all the time...
MvdV>> "used to" past tense....
ml> we still do it, too... present tense...
MvdV> I was quoting your own words... So now you change your own
MvdV> words... Anyway, it is not "we" that still do it. You may still
MvdV> do it, but I never did, so there is no "we".
there's more people than you and i... others use it, too... at least two others
in this facility and i know of more outside of it...
ml>> then the remote would pick it up and deliver the file on its
ml>> dime...
MvdV>> I never did that. It was considered annoying behaviour in this
MvdV>> part of the world. And rightly so...
ml> maybe, maybe not...
MvdV> You would get rid of th e"maybe not" very soon if you were a node
MvdV> in 28 during the CSO wars. It definitely was considered annoying
MvdV> behaviour here. No maybe about it.
that's when i would simply turn on the option of NOT picking up requests...
simple and easy to do...
ml>> that's why there was created the mailer option to not pick up
ml>> file requests that may be waiting at the remote...
MvdV>> And that file may even be a mail bomb. It has happened...
ml> how can a file request (req) be a mail bomb? that has not happened
ml> before...
MvdV> Sorry, my bad. What I meanmt was thet a sysop not having your
MvdV> beat interest at heart, knowing or guessing that you were going
MvdV> to request a certain file, would send you a mailbomb instead of
MvdV> the desired file...
oh, that's always possible... the thing is, though, that most FREQs are not
known of in advance...
ml> sure, someone might create a garbage file with an extension
ml> of .req and send it to your system but that's not a mail bomb... mail
ml> bombs are mail archives that expand much larger than they would
ml> normally...
MvdV> I know what a mailbomb is. I had my (un)fair share...
in the not too recent past, many others had something similar but that one was
apparently due to a screwed up filesystem... it certainly wasn't done on
purpose and it traversed numerous hubs to arrive at quite a few leaf systems
and points...
MvdV>> If the possibility to put file requests on holf had not been
MvdV>> created in the first place, there would have been no need to
MvdV>> build a defence against it would there?
MvdV>> Of course that is all water under the bridge. Now that cost has
MvdV>> dropped to virtually zero, there is no need any more to
MvdV>> consider file request on hold as annoying. But then there is no
MvdV>> incentive to do it at all is there? The requester may as will
MvdV>> pick up the zero cost himself...
ml> not everyone has zero cost for their internet connections... there are
ml> still many on metered connections... placing reqs on hold may still be
ml> desirable to some...
MvdV> In the IP age it does not help to reduce cost on the metered
MvdV> connection. The cost is not paid by the initiator of the
MvdV> connection, it is paid by the amount of bytes transfered. The
MvdV> requester pays either way.
not in all cases... some are metered by their outbound requests... i've worked
with several that have this setup...
ml> you and i are not the ones to determine that nor are we the ones
ml> to tell others they cannot do that...
MvdV> I am not telling others what to do, nor am I making it impossible
MvdV> for them do do as they always did. All that I want is that I can
MvdV> perform certain functions without the need to jump through hoops
MvdV> in order to support ballast that I no longer need.
then perhaps binkd and the BSO format is not for you... the fact is that these
hoops are needed and they always have for the BSO format... those of us who
have used (and been spoiled by) dynamic mailers with all their nice features
that do these things for us do find some of these activities to be unnecessary
hoops but they aren't... they are SOP for the format being used...
MvdV>> Does your car still have a crank to start it by hand in case of
MvdV>> a broken starter engine or low battery? My last car with that
MvdV>> functionallity was a Volkswagen Beetle form the 60ties...
ml> actually, yes, we do still have an original VW Bug...
MvdV> Of course, I could have known...
hahaha... i also still have my third car... a 1979 toyota celica... my first
one was sold on the the road on my way back to the east coast when i left the
USAF... it had died and i didn't have the funds to fix it so i sold it to a guy
that pulled the motor and transmission for use in a house boat... i used those
funds from the sale to get the rest of the way home... my second one was sold
while i was out traveling (hiking across country) to the west coast...
MvdV>> On the contrary. I want to leave the stone age behind ond move
MvdV>> on the 21st century.
ml> then you are using the wrong mailer technology... BSO is about as
ml> stoneage as you can get...
MvdV> So is the wheel. Does that make a modern car stone age
MvdV> technology?
no but putting solid wooden wheels on them knocks them back some years :)
ml> the only thing modern about this mailer is its transfer mechanism...
MvdV> Exactly. And as a result we can ditch some ballst that was only
MvdV> needed in the POTS age. We no longer need support fior spanning a
MvdV> horse in front of the car.
ml> nothing more... so back to that analogy...
ml> you want an electric powered horse cart with solid wooden wheels :)
MvdV> No, I just want to get rid of the horse.
good luck with that... this mailer requires the horse ;)
)\/(ark
* Origin: (1:3634/12)
|