Text 6863, 191 rader
Skriven 2013-02-23 20:07:01 av mark lewis (1:3634/12.42)
   Kommentar till text 6851 av Michiel van der Vlist (2:280/5555)
Ärende: ö is o umlaut, œ is the British Pound, ¼ is the Yen.
============================================================
 ml>> i know this but this factor was decided long ago and only since 
 ml>> then have erronoeus implementations been done...

 MvdV> As the "deciders" had no authority, going against their decision 
 MvdV> can not be "erroneous".

man, you are getting to be quite the prick about this stuff... the decisions
were reflected in the standards proposal documents... stop being such a danged
lawyerly weasel type... please... you'll get along with others much better...

 MvdV>> So the new developers decided they were not bound by that
 MvdV>> decision.

 ml> highly doubtful... i dare say that the majority ot "new 
 ml> developers" never heard of NET_DEV and if they did, they weren't 
 ml> around to read those posts and that then means that they did not 
 ml> know of that decision so they could not decide that it did not 
 ml> bind them...

 MvdV> Now that you mention it, that is indeed more likely. The result 
 MvdV> is the same, the new developers took another fork in the road. 
 MvdV> We may never know, but my guess is they would have done that 
 MvdV> anyway, even if they had know about what happened in the early 
 MvdV> ninetees.

possibly... but it is, as you say, nothing more than a guess...

 MvdV>> And rightly so, the participants of the late NET_DEV are not an 
 MvdV>> authoritative body that can decide for all eternity what the
 MvdV>> next generation may or may not do.

 ml> NET_DEV was never intended to be authoritive... the FTSC publishes 
 ml> documents that it accepts as standards... the developers create 
 ml> those standards and the software that adheres to them...

 MvdV> Yes, the FTSC does not create the standards, the developers do 
 MvdV> that. But once the FTSC has accepted it as a standard, the 
 MvdV> developers are no longer free to create something that conflicts 
 MvdV> with it.

sure they are... how do you think the standards get changed and updated? the
developers have added to or changed what they were doing... the FTSC either
updates the current documentation or they accept a new proposal that may be
submitted if one is developed...

 ml> this is the main reason why i stated in the MAKENLNG echo that 
 ml> they should just go ahead and fix the problem(s) regardless of 
 ml> what the standard states because they are setting the new 
 ml> standard...

 MvdV> So what is the point of documenting standards if anyone can just 
 MvdV> ignore them and do the opposite. Seems like an exercise in 
 MvdV> futility to me... 

welcome to reality...

 ml>>  when we lost Goram Eriksson, we also lost NET_DEV and thus the
 ml>> discussion area for this work...

 MvdV>> NET_DEV was dead long before Goran's demise. The professional
 MvdV>> programmers left for greener pastures.

 ml> no sir, it was not... it was slower than it had been in years past,

 MvdV> For all intents and purposes, it was dead. The developers that
 MvdV> mattered had left.

and yet we have a whole new crop that could have benefitted... are you saying
they don't matter? it sure reads like you are saying that...

 MvdV>> So just consider the kludge lines part of an extended header
 MvdV>> and parse them too.

 ml> it adds complication when one is performing a header only listing

 MvdV> Yes it does.

 ml> (as was given as a recent example by someone else)... especially since
 ml> control lines can be spread throughout the message body as has been
 ml> done in the past...

 MvdV> Too bad.

and it blows yout theory about a so called "extended header" definition to
hades...

 MvdV> Look, I did not invent this mess.

neither did i... i have, however, tried to follow along with the intent and
desire... but like others in our history, i've had to fight folks like yourself
danged near every step of the way... i've told you before that you were one of
the reasons why i shelved a lot of my development work... you didn't believe it
but it is true... you and your attitude of being holier than others and acting
the political lawyerly weasel... and not just you but you are the top of the
pile and it isn't a good pile to be in...

 MvdV> I was not me who decided every baylifwick in the world should 
 MvdV> have their own language. I was not the architect, nor the 
 MvdV> builder, not the realtor of the Tower f Babel. Also it was not 
 MvdV> me who decided that every bayliffwick should not just have its 
 MvdV> own language, but also its own character set for the written 
 MvdV> version.

no doubt... and as long as there is such, there can never be one united
world...

 MvdV> Neither was it me who decided that ASCII should be enough for
 MvdV> everyone. I am also not the one who later decided that CP437
 MvdV> should be enough for everybody. So don't blame me.

i'm not blaming you for that...

 MvdV>>> Sorry, but current practise is that text in the header uses
 MvdV>>> the same encoding as that for the message body. Like it or
 MvdV>>> not, it IS current practise.

 ml>> i definitely do not agree there...

 MvdV>> You can disagree all you want, that does not alter the facts.

 ml> sure it does... /some/ current practise may be doing that but not
 ml> *ALL* current practise is doing it...

 MvdV> The fact is that the main stream took another fork as the one
 MvdV> that you are on. The reason is simple: limiting the text in
 MvdV> header fields to CP437 just does not work. You do not really
 MvdV> believe that a Russian writing in cyrilic is does NOT use that
 MvdV> same character set in the subject field of messages? Of course he
 MvdV> does! having the message body in cyrilic and the subject in
 MvdV> CP3437 just does not work for them.

of course but they also do not spew that into the rest of the international
echos, do they?

 MvdV> So like it or not, they use the same character encoding for the
 MvdV> message body and the message header.

just as everyone did in the beginning as well with the IBMPC/CP437 character
sets...

 MvdV> Yes, that means having to hunt for the CHRS kludge if you want to
 MvdV> properly display the text in the header.

fail...

 MvdV> It could have been avoided if it had been done right from the
 MvdV> start and if the founding fathers had made provisions to extend
 MvdV> the header in some way, but they didn't, they made the header
 MvdV> very rigid. So instead of putting the encoding information in the
 MvdV> header where it belongs, it had to be in a kludge line in the
 MvdV> message body. Not nice, but that is the way it is.

SO GET A NEW PACKET FORMAT IN PLACE AND START USING IT! jeeze louise! quit
whining and whinging about what we have and create something better that suits
things the way they are... don't do it in secret... do it publically in an area
specifically created and maintained for such work on ideas of these types and
their proposals...

 MvdV>> You can moan and groan, stamp your feet and dig up 20 year old 
 MvdV>> "decisions", it is not going to turn back the clock. The ASCII 
 MvdV>> only age is over and the default encoding is not CP437.

 ml> sure it is... it is one of several used throughout the network... 
 ml> so please correct your statement by replacing "the" with "a" and 
 ml> removing "not"...

 MvdV> No. One can not have more than one default.

sure we can... on a CP437 machine, CP437 is the default... on the CP850 machine
beside it, CP850 as the default...

 MvdV> The fact is that the new generation of (mostly Russian) 
 MvdV> developers took another fork. They are not going back to what 
 MvdV> you want - CP437 only in the header - because that does not work 
 MvdV> for them.

i don't expect them to... what i do expect them to do is NOT break what is
already in place and working... there are at least 3 other PKT proposals in the
FTSC library... surely one of them can easily handle what is desired... if not,
since it was never accepted as a standard, it can be used as a starting point
and adapted... that or it can all be done from a clean start...

 MvdV> So... you can either track back to the forking point and follow
 MvdV> the rest, or you can stay on your own.

sheeple say "baaaaaa baaaaaa"...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)