Text 9924, 359 rader
Skriven 2007-04-12 02:12:48 av Maurice Kinal (1:140/13)
   Kommentar till text 9905 av mark lewis (1:3634/12.0)
Ärende: Binkd
=============
Hey mark!

Apr 11 18:40 07, mark lewis wrote to Maurice Kinal:

 ml> as far as stand alone mailers, yeah...

I think it might be the only one.  Used to be a serial based one that could do
Fido but haven't even heard a mention of such things in quite some time now.

 ml> yeah, there's that, too... i run an all JAMbased system except for 
 ml> the one MSG area that my main mailer needs... the husky stuff won't 
 ml> work for me if it doesn't fully support JAM and offer the same 
 ml> functionality that i current employ... 

Hence what I said about the libsmapi dependency.

 ml> i think i'd agree... i've max here but haven't been able to get it to 
 ml> compile from the CVS sources in quite some time... and that's on an 
 ml> old box that used to compile it quite readily...

I did get it to compile but never really went beyond that then.  That was
awhile ago.

 MK>> As for complete Fido BBS systems are a concern then I'd definetly 
 MK>> give the edge to MBSE.

 ml> i think of a "complete" bbs as one that 
 ml> supports message areas (the original reason they were created) as 
 ml> well as file areas and external "door" apps (whether they are games 
 ml> or simply utils like archive viewers)...

Sounds like MBSE.

 ml> the problem with FTP and fidonet is that FTP doesn't lend itself to 
 ml> fidonet mailer handshaking and protocol negotiations...

Right.  It doesn't need to.  It is perfect the way it is.

 ml> FTP has to be 
 ml> set up seperately and outside of any fidonet software...

Yep.  Only concerns itself with getting a file transferred which is perfect for
transferring files.  :-)

 ml> heck, binkd 
 ml> is right there is that very same boat, too...

Not really but I think I know what you mean, and if so, then that fits moreso
into the original Unix philosophy which is to do one thing and do it well, even
if it is multieverything.  :-)

 ml> it depends on what i'm attempting to do at the time... sure, FTP can 
 ml> be a big help in a lot of cases... heck, the php-based gallery 
 ml> software that i run on my website uses FTP for all the uploading, 
 ml> moving and renaming of the photos... its ok, i guess... it works and 
 ml> that's the main thing...

So far it is the best and was the best way back when before Fido.  Doesn't
surprise me that a php-based gallery software would exploit that functionality.
 Picking a winner is always a good idea.

 MK>> That could work.

 ml> care to give it a try and submit it to the FTSC? :)

Maybe.  I am not sure I was going to go any further with it yet.  I got
distracted by the neighbour recently with some wireless networking ideas we
have going here but have the preliminaries still in my home account.  Probably
pick it up again in the near future.  It's been known to happen.

 MK>> 'acceptable standard'.  binkd cannot compete with ftp.  Not even
 MK>> close but so far it appears to be the most acceptable Fidoally
 MK>> speaking.

 ml> yep... part of that is due to that blinding light i mentioned earlier 
 ml> ;)

Probably.  I don't think it matters too much.

 ml> personally, i see nothing wrong with encapsulating fido stuff in 
 ml> a telnet stream...

That can work.  I've done simular before, usually in serial type programs.  The
last time was with a marine GPS reciever.  Worked great.

 ml> definitely before binkd came on the scene... doing this allows 
 ml> fidonet systems to even go so far as supporting FTS-0001 as mandated 
 ml> by current fidonet policy O:)

I suppose.  At the moment binkd takes care of where it *has* to and the power
that be hasn't complained thus it can sit on ye ol' 486 for now.  It seems
happy there on a secondary mount off a usb port which kept it's initrd down to
an absolute minimum and all I have to do is unplug it and it is history without
the main system complaining about anything.

 ml> there is... FTS is technical standards... FSP is standards 
 ml> proposals... seems easy enough to me ;)

Okay.  I guess I have it all covered then.

 MK>> What wheel?  I thought the wheel went flat a long time ago?  Did I
 MK>> miss something?

 ml> you must have... take FSP-0065 (mark kimes' Type 3 ASCII proposal) or 
 ml> FSC-0066 (mark kimes' Type 3 Binary proposal)... the type 3 binary 
 ml> stuff uses the concept of "chunks" of data... the chunk identifier 
 ml> indicated the type of data contained within the chunk... this data 
 ml> could be one of several things in much the same way that email, 
 ml> today, carries pictures and other binary data to be used in the 
 ml> presentation implementation...

Interesting.

 ml> there is also Jason Steck's Type 10 format which was actually 
 ml> implemented in the JMail mail processor (v2.10 and newer), unlike 
 ml> many other message transfer proposals... this one covers items of 
 ml> contention like 5D addresses, and also contains a form of "chunks" 
 ml> that include command blocks for system to system commands and 
 ml> requests (ie: making things like adding new message areas, removing 
 ml> message areas, purging old messages possible on a systemwide 
 ml> scale)...

That sounds too dangerous.

 ml> there's also Mikael St?ldal's type 3 proposal, FSC-0081, which 
 ml> defines transport layer (mail tosser) stuffs AND conforms to the 
 ml> existing basic type 2 packet version determination method in that the 
 ml> PKTTYPE field is in the same binary location as in the Type 2 packets 
 ml> as well as also having a capability word in the same place as in the 
 ml> Type 2+ packet format... this proposal also defines stuff for the 
 ml> message body which would be the presentation layer... things like 
 ml> superscript, subscript, bold, and italic are supported... also 
 ml> embedded files for a more true "file attach" methodology...

Too much.

 ml> there's also Stephan Slabihoud's XType-1 proposal, FSC-0082, that is 
 ml> more convenient than FSC-0014 (by wynn wagner iii) which was an early 
 ml> binary-style message format... this one offers even more multimedia 
 ml> capabilities...

Already got that covered.  Too little, too late.

 ml> kaleb axon even proposed a method of transporting RTF formatted 
 ml> messages within type 2 packets (FSC-0079)... character sets, pictures 
 ml> and other possible embedded objects (possibly like spreadsheets, 
 ml> charts, and videos), stylesheets, multiple column text, even support 
 ml> for left-to-right languages...

Not an issue.

 ml> of course, all of these except for FSC-0065 (Type 3 ASCII) fly right 
 ml> in the face of your desired minimalistic approach ;)

Heh, heh.  We'll see.

 ml> however, they 
 ml> all support what the users want and it has been that desire for more 
 ml> than text that has greatly contributed to the users leaving fidonet 
 ml> in droves of droves...

I doubt that.  Nice excuse though.  From what I've seen it is readily available
pornography that has most users attention as well as pirated software, movies
and the such.  Chatting with total strangers would be up there as that gives
them all the opportunity to pretend they are someone totally different from who
they really are, if they indeed know who they really are in the first place. 
Glitz over substance is the actual reason for the demise of Fido and simular
types of networking.  Also few around these parts use phone lines with their
computers anymore so that had the largest impact and before that the lack of a
suitable protocol when people were switching to browsers and MS's extremely
poor ppp client thingy.  That caused much grief for everyone back then.  Sure
don't miss those days any.

 ml> if it is widespread and common use, then it is "standard"...

I've heard that before.

 ml> i remember seeing your messages to the described effect... however, 
 ml> color me confused as i cannot see any way of you addressing an 
 ml> echomail or netmail message TO: me without information contained in 
 ml> the binary header that you appear to dislike so much...

It is there with or without the binary headers.  Same with From:, Subj:, etc. 
Not a biggie.

 ml> that i saw all of your messages appearing as "To: ALL" when you were 
 ml> replying to a specific individual...

I haven't done replies ... yet.  I did post to certain individuals as well as
ALL, whoever ALL turns out to be, in this very echo.

 ml> that, as it happens, is one of 
 ml> the most hated aspects of newsgroups...

I agree.

 ml> if i'm replying to a message 
 ml> that you wrote, then i'm writting to _you_...

Anyone can read it and reply to it if they wish to.

 ml> if i cared that my 
 ml> response should be in private where others couldn't read it, i'd send 
 ml> it via private messaging means (ie: email or netmail)...

Right.  Not a bad plan.

 ml> address my message TO: YOU and leave it in the public view for anyone 
 ml> else to add or respond to...

I prefer that concept.

 ml>> no, i'm not holding my breath on that... the problem i see is one of 
 ml>> NIH syndrome... there's too much of it out there ;)

 MK>> Right.  I agree 100%.  Heave-ho time methinks.  ;-)

 ml> heave-ho for what? those with the Not-Invented-Here syndrome or just 
 ml> eh syndrome, itself?

Sure!  That could work for me.  I actually meant the binary headers but there
is probably more that could safely get the heave-ho without hurting my feelings
any.

 MK>> Troublesome yes, but definetly doable.

 ml> i'll say... i easily saw where it could be done with a few scripts 
 ml> and standard *nix command line tools being available to users in much 
 ml> the same way that they are available to local command line logins on 
 ml> *nix systems...

Right.  That is what I did with the header stripping part (inbounds).  Nothing
in there that isn't available to any Linux distribution I've seen thus far,
even minimalized ones such as ttylinux.

 ml> anyhow... hell, one could even go so far as to say that *nix is 
 ml> nothing more than an elaborate BBS system in and of itself but that 
 ml> would probably get the goat of many *nix elitists O:)

I doubt it.  I originally heard that said before I ever had a Fido node and
believed it then as much as I believe it now.  Also text messaging to handhelds
should be a breeze without jumping through too many hoops ... other then the
required original Linux hoop jumping.

 ml> hehe, yeah... also with your mention of point-ish and i assume 
 ml> end-node-ish,

That would work too.  Also offlining although wouldn't need to worry about any
Fido standards there as it could be tacked on by the BBS upon upload.

 ml> i can easily see where you come by the lack of need for 
 ml> the information in the binary headers of the PKTs and messages... 

Right.  They just get in the way.

 ml> systems in the middle definitely use that information a lot more than 
 ml> leaf nodes... in fact, the only reason a leaf node has of looking at 
 ml> them is for security purposes to ensure that they contain mail for 
 ml> them and not for some other system...

I doubt that is a need given the nature of echomail.  Perhaps scanning for
undesirable encoding within a mail packet that potentially could screw up a
display or something of that nature.  However then it makes even more sense to
NOT send binary headers.

 ml>> the internet and believing that it is somehow better over there O:)

 MK>> Really?  Name one thing.  I dare you!!!

 ml> one thing on which side? the fidonet side or the internet side?

Errr ... the internet but I already took care of that for you somewhere above.

 ml> as a leaf or bud node, yes... i can see where they can be dispensed 
 ml> with... however, i don't believe that i can say the same for an 
 ml> intermediate mail mover system...

Not at present, but I think it has potential even there.

 MK>> anything other then kludges.  It is all there.  What more could
 MK>> anyone want? 

 ml> somehow i think we're confusing a few layers of fidonet mail... now 
 ml> you're talking about the presentation layer but you seem to balk at 
 ml> the stuff necessary for the transport layer??

Both but first things first.  We'll get wherever we're going eventually.  At
the moment things seem to be taking care of themselves without anyone's
interference.

 MK>> That one is the easiest to ignore and tack on (outbound) and farm
 MK>> out to the bitbucket (inbound).

 ml> that one is the _first_ line of security outside the mailer to mailer 
 ml> handshake...

No it isn't.  Nothing in the pkt is even looked at until it is tossed.  Heck a
poll can happen without any pkt's being transferred at all nevermind their
headers.

 ml> on the contrary! messages are seperated by null characters...

Too many other nulls in a pkt to make it reliable, also many nulls in the
headers themselves that have nothing to do with delimiting whatsoever.  More
bitbucket material methinks.

 ml> only other place a null will show up is in the 58 byte binary 
 ml> header...

As well as at the end of the pkt itself.  No uniqueness to a null to make it a
reliable character to identify headers or any other unique feature within the
entire pkt.

 ml> no useful information?

None that can't be gotten a better way (patent pending).

 ml> the sender's name isn't important? 

Still there without any of the binary stuff.

 ml> neither is 
 ml> his address?

That as well as the sender's address is still there.  PATH is there.  MSGID is
there.  REPLY is there if and when it is there.

 ml> and the date and time aren't important, either??

Still there in the silly original format.  I ignore it and assume it is wrong
simply because it usually is.  It is relative and make a very poor reference at
best.  Still there though.

 ml> i definitely agree when it comes to processing _echo_mail and the 
 ml> trailing seenby and path lines... those should have been at the top 
 ml> with the other control lines...

Not a bad idea.  That would simplify and speed things up a tad.

 ml> it would definitely have made a lot 
 ml> of stuff easier when it came to processing messages...

Definetly.  You got my vote.

 ml> another facet on the binariness of messages is that once upon a time 
 ml> major need to save space way back when systems were run on floppy 
 ml> drives and small hard drives... storing the numerical data in binary 
 ml> form saved a great many bytes and made room for more messages! ;)

What is a floppy drive?  ;-)

I've always hated those damn things.  Good thing they no longer have any
influence.  I don't miss those one little bit ... errr byte?

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: Coffin Point BBS (1:140/13)