= Сообщение: 1106 из 7127 ====================================== FTSC_PUBLIC = От : mark lewis 1:3634/12.71 14 Jan 14 12:49:20 Кому : Michiel van der Vlist 14 Jan 14 12:49:20 Тема : CHRS kludge implementations FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.71+2d57a700 На : area://FTSC_PUBLIC?msgid=2:280/5555+52d549a5 = Кодировка сообщения определена как: CP866 ================================== ==============================================================================
On Tue, 14 Jan 2014, Michiel van der Vlist wrote to mark lewis:
BF>> From what I've seen so far, there's not a single person that BF>> will advocate the level part of the CHARS kludge, so lets get rid BF>> of it once and for all.
ml> you're seeing a few people in here talking about it... what you ml> are not seeing is current practise which is done by all the ml> software being used on the network... as long as a majority of ml> software emits and/or uses the level parameter, the documentation ml> is correct... what are you going to do when you remove that level ml> parameter and break software all over the network?
MvdV> As I see it, there is no added value in dropping the level MvdV> parameter, but doing so may break backward compatibility. So no MvdV> pros for dropping it, just cons.
agreed and that was my point as well... thank you! ;)
MvdV> When we were to redo Fidonet from start, we would probably do MvdV> without the level parameter. It is not very useful. Sometimes MvdV> however we just have to live with the consequences of decisions MvdV> made in the past. We do not know if there is still softare around MvdV> that will break when the level parameter is omitted, but why take MvdV> the chance?
very true... if we were to redo fidonet from the ground up, i wuold maybe suggest to use procedures more like what is used on the internet in numerous cases... especially where character sets come into play... even their methods of encoding in the control lines (from, to, subject)... but i would still carry the binary capabilities we have without their overhead of MIME, UU and/or XX encoding of binaries...
speaking of binaries, it would be an idea to also look closer as the type 3 pkt formats as well as the type 10... i recall at least one pkt type that used a form of xml or maybe what is known today as JSON where each section of messages is encapsulated within its specific section... this was all before xml and JSON were really being used like they are today ;)
MvdV> It doesn't eat bread, so the recomenation for new sofwtare to MvdV> include it when writing and ignore on read seems to be adequate.
+1 :)
)\/(ark
Not only is the Universe stranger than we think, it is stranger than we can think. - Werner Heisenberg
