Text 9905, 142 rader
Skriven 2007-04-11 19:09:42 av Maurice Kinal (1:140/13)
   Kommentar till text 9904 av mark lewis (1:3634/12.0)
Ärende: Binkd
=============
Hey mark!

Apr 11 14:02 07, mark lewis wrote to Maurice Kinal:

 ml> the idea is/was to have links to software that will run on *nix 
 ml> regardless of its DOSish nature... it is all we have, ya know ;)

At the moment that will be a very short list.  So far binkd seems to be at the
top with a few others either abandoned or in a holding pattern for whatever
reason.  The Husky stuff started out quite promising (still using it as we
speak) but stagnated somewhere along the line.  Offhand I think it is the
libsmapi dependency as many thought squish was the way to go.  Originally I
fell into that camp but since back then have reevaluated and came to the
conclusion it might have been a bad idea.  However if backwards compatibilty
with a Maximus-think system is something of value then the Husky stuff is the
way to go.  As for complete Fido BBS systems are a concern then I'd definetly
give the edge to MBSE.

Personally I'd rather stick to what has proved itself to be the best over the
many years and that has been ftp.  I've been able to adapt that to suit all
sorts of so-called newfangled thingies, up to and including mutilmedia
streaming, both audio and video.  I have yet to see anything beat a well
configured ftp server when it comes to ANY type of transfers to ANY client
based system, including a DOS-think one.  Have you?

 ml> one document pointing to each of those currently listed that are 
 ml> acceptable... that could be done...

That could work.

 ml> the thing is that there are many 
 ml> acceptable standard for the transfers...

I would convert the above to 'acceptable practices' rather than 'acceptable
standard'.  binkd cannot compete with ftp.  Not even close but so far it
appears to be the most acceptable Fidoally speaking.

 ml> enumerate those for the actual processing and handling of mail and 
 ml> files ;)

Right.  I've been reevalutaing all that over the last decade, and then some.  A
decade is close enough.

 ml> i don't see a problem with having proposals available...

Understood.  However there needs to be some identification and isolation to
what *IS* at the moment.

 ml> without 
 ml> them, one would have to start from ground zero and could very well 
 ml> reinvent the wheel...

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

 ml> widespread and common use, then the proposal would be elevated to a 
 ml> standard...

Do you actually think much of that requires standardization at all?  I've been
using different things, for different reasons, all along without any of it
requiring standardization.  For instance recently been using a couple small
apps just to strip and tack on the binary headers without me requiring them
locally for any reason whatsoever.  I even tested that in this particular echo
and it worked just fine.  No squish, no JAM, no QWK, no bluewave, no ANYTHING
related to ANYTHING ever found in a Fido-think system.  I didn't see any
complaints about any of it so I am assuming it is quite doable.

 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 ;)

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

 MK>> Good luck.  You'll need it.

 ml> hehe, well, there aren't all that many, really...

That makes it easier.  To be honest it has been doable all along without any
ports.  Troublesome yes, but definetly doable.

 ml> seems that no one, 
 ml> other than you, has any real interest in doing anything with 
 ml> fidotech...

I've noticed that.  Probably explains why I haven't done all that much. 
However every once and awhile I like to play with it just for fun.  I think I
have a foundation for a suitable Fido point-ish system without nodes or hubs
needing to change anything wrt their setups.  They can keep their abandonware
and everyone is happy.  Right?  ;-)

 ml> seems they are all blinded by the artificial light from 
 ml> the internet and believing that it is somehow better over there O:)

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

 ml> well, those binary headers contain important information that just 
 ml> can't be thrown away...

Sure they can.  I've done it and the end result is vastly more condusive to all
sorts of archiving, editors, etc. that I threw at it.  Faster too.  Everything,
and then some, is there.

 ml> converting it to something more useful in a 
 ml> text format is always possible and i have no problems with that...

Neither does any app I through at it.  I can easily imagine a java or cgi web
system having absolutely no issues displaying the result to the pointy-clicky
crowd without any real issues and without requiring ANY conversion.  Some
possible filtering (kludges) if that information isn't desirable to display but
that is readily done simply because of a proper delimiter that isn't used for
anything other then kludges.  It is all there.  What more could anyone want?

 ml> we should also note that there are two sets of binary headers... one 
 ml> for the PKT file

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

 mb> (currently 3 possible one in use) and one for each 
 ml> of the messages contained within the PKT...

That one was more tricky since it can be anywhere and doesn't readily identify
itself as such.

 ml> what data in the above headers would you throw out and why?

All of it.  Why?  Simply because it contains no useful information that cannot
be obtained using better methods and it slows down processing due to a silly
stucture as well as the marriage to 16-bit integers, the message headers being
the biggest slowdown in processing.

 ml> how would you handle fidonet's current capabilities without that data 
 ml> being present?

It is all there without the headers.  The headers are the biggest drag on the
system and provide no additional or even useful information.  Pure drag is all
they are.

Life is good,
Maurice

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