home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   HOTDOGED      Support for the HotDogEd software      1,000 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 118 of 1,000   
   mark lewis to Ulrich Schroeter   
   No Echolist with hotdogED?   
   23 Oct 13 05:58:46   
   
   On Wed, 23 Oct 2013, Ulrich Schroeter wrote to Mark Lewis:   
      
    US>> CDP proposal   
    US>> FSP-1016.003  Automatic configuration of Points in Fidonet   
    US>> has answered this question regarding echo forwarding lists ....   
    US>> in section   3.1.2.1.2 ECHOZZZZ.ZIP and  3.2.2  Transmitting the   
    US>> application date   
      
    ml> -> Freq  ECHOLIST   
      
    US>> The only thing to consider ... nodes supporting HotDogED clients   
    US>> should add the freq magic ECHOLIST in their system and   
    US>> ECHOZZZZ.ZIP to be sent. So on the supporting system the echo   
    US>> uplink lists have to be compiled and named ECHOZZZZ.LST and zip'd   
    US>> thereafter ...  =;)   
      
    ml> is there anything wrong with sending the existing, published and   
    ml> distributed Echolist?   
      
    US> yes, it probably doesn't reflect the nodes "echoes" capabilities    
      
   that's why the request is passed on upstream to the feed's uplink for   
   processing... if they don't have the areatag, then they forward it to their   
   upstream etc etc etc until it reaches "the top" and either finds the area or   
   not... if the area is found, then it propogates back downstream... if the area   
   is not found, the "not found" message should travel back downstream as well so   
   that the original node requesting the area will know that it is not   
   available...   
      
    US> so one node only supports the official "international echoes"   
    US> (known under BACKBONE.NA and ELSTYYMM   
    US> the next node supports international + zonal + regional specific   
    US> echoes and the 3rd supports all node 2 supports + have a list of   
    US> own nets and local areas, and also supports some specific areas   
    US> from other languages ESP.*, BR.*, RU.*   
      
   all of those would be listed in the %AVAIL response... provided, of course,   
   that the feed has "properly" gathered those lists from their upstream feed(s)   
   and configured them in their tosser... without them, the tosser can't forward   
   unfullfilled requests upstream for fullfillment so they are needed anyway...   
      
    US> so you have 3 different potential link partners with 3 different   
    US> capabilities. One uses backbone.na + local.na, the next uses list   
    US> fareas.bbs and a third uses the standardized ECHO0002.LST that is a   
    US> local compile of the lists the node supports   
      
   it doesn't matter where the feed comes from, does it? a point wants an echo so   
   they request it from my system... my system has lists for each of my upstream   
   feeds... my tosser finds the requested area listed in one of those and sends   
   the request to them for fullfillment... the point system doesn't care where it   
   comes from as long as they are able to pull it from my system...   
      
    ml>  is the above perhaps talking about something   
    ml> else other than the Echolist?   
      
    US> a local compilation of one or more or many different echo   
    US> forwarding lists    
      
   the tossers do this with the %AVAIL request...   
      
    ml>  something, perhaps, like the list of   
    ml> available areas (%AVAIL) from the feed's uplinks?   
      
    US> some support, some may not ...   
      
   true... those that do not could loose market share ;)   
      
    ml>  where are other,   
    ml> unlisted, area names to be found?   
      
    US> default path: ask the NEC, REC, ZEC  =;)   
      
   that's not a distribution path... those are coordinator positions... they are   
   not required to distribute echomail and never have been... Zone1 dealt with   
   dictators in those positions back in the 90s and showed that free market is   
   better... especially when some of those *ECs were playing politics with the   
   message areas... besides, *ECs are created by their *C as an assistant to the   
   *C... a *EC does not have to exist for any *C...   
      
    ml>  how is one to know of the existance   
    ml> of an area if it is not in the %AVAIL or %LIST areafix responses?   
      
    US> hearsay, discussions in echoes, requests in a sysops chatter    
      
   and if one is just joining and had nothing to go by other than lists they can   
   get from their feed?   
      
    US> freq echolist from a CDP flagged node in Zone 1 will probably   
    US> result in a complete different list than frequesting echolist from   
    US> a CDP flagged node in Zone 2, so the localy compiled echolist is as   
    US> is, a compilation of the echoes a downlink can request via areafix   
    US> from the node where the node/point is connected to. A CDP system   
    US> schedules a echolist freq monthly, so if new areas are available,   
    US> the compiled list will be updated.   
      
    US> The request is a kickoff for connecting to a node, you have no info   
    US> how fidonet works, whats echoareas are. Thats why the CDP package   
    US> starts with a compiled list of available echoareas a CDP point can   
    US> request via an option list. Here there is no joker available ...   
    US> If you want more, and have learnt more you can do more like write a   
    US> netmail to areafix of your uplink ... netmail what ?   .-)   
      
    ;)   
      
   oh yeah, i almost forgot [/devil's advocate] O:)   
      
   )\/(ark   
      
   --- FMail/Win32 1.60   
    * Origin:  (1:3634/12.71)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca