• Echomail Data

    From apam@21:1/125 to All on Tue Jan 30 20:18:20 2018
    So I've been thinking more on this topic..

    It's really not very portable. If you want to write a game or app for
    mystic, then sure it will work. If you want to write a game or app for Magicka, that will work too, but if you want to write a game or app for any bbs it
    gets a bit trickier.

    So if you write a door, you need to interface with the message base
    yourself, so that means JAM if it's mystic or magicka, SQLite if it's ENiGMA 1/2,
    WWIV's format if it''s WWIV, synchronet's format etc...

    I think given 90% of the people here run Mystic so it's likely that the majority will be mystic mods using this system. So it's really going to be InterMystic communication rather than InterBBS.

    Which is fine I suppose, given that people seem to prefer to write mods
    than doors anyway.

    So I wonder if there is another solution. What about something web based,
    but instead of a different script for a different door, it could be more generalized, kind of a service that many doors could use. You could do something
    like MQTT where your doors subscribes to a channel, and when a door
    updates, the message is stored in that channel, when it fetches, it gets messages
    from it's channel. That way someone could host this service, and anyone could use it, rather than a different service per door. If that makes sense.

    I'm on the fence about FSX_DAT now, in that I wonder if sending data over echomail is a good idea or not, regardless if it's going to be sent, then a seperate channel would be good.

    Andrew

    --- MagickaBBS v0.9alpha (Linux/x86_64)
    * Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)
  • From Al@21:4/106 to apam on Tue Jan 30 02:49:12 2018
    Re: Echomail Data
    By: apam to All on Tue Jan 30 2018 08:18 pm

    So I've been thinking more on this topic..

    It's really not very portable. If you want to write a game or app for mystic, then sure it will work. If you want to write a game or app for Magicka, that will work too, but if you want to write a game or app for any bbs it gets a bit trickier.

    I think it can work as it is and will likely get some use.

    I am not a developer myself but was reading some developers some time ago trying to come up with a "standard" for interbbs traffic.

    From what I understood a UDP port was what they were leaning toward but nothing came of it (that I know of).

    I'm not sure if that is worth looking at or not. I know nothing of UDP or TCP ports except that I have a couple open.

    Ttyl :-),
    Al


    ... What?! I'm missing Star Tre$#%$^ NO CARRIER
    --- SBBSecho 3.03-Linux
    * Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (21:4/106)
  • From CyntaxX@21:4/113 to Al on Tue Jan 30 15:34:04 2018
    I am not a developer myself but was reading some developers some time ago trying to come up with a "standard" for interbbs traffic.

    I'm there with you. I have no dog in this fight. I know how to manipulate
    basic code from others to hopefully get it to do what I need, but I couldn't tell you how it works.

    That said. It's very intriguing having an inside look at how developers go about solving issues such as this.

    --- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
    * Origin: Digital Wurmhole | digitalwurmhole.ddns.net:2323 (21:4/113)
  • From Avon@21:1/101 to apam on Wed Jan 31 09:53:08 2018
    On 01/30/18, apam pondered and said...

    I'm on the fence about FSX_DAT now, in that I wonder if sending data over echomail is a good idea or not, regardless if it's going to be sent,
    then a seperate channel would be good.

    I plan to set this up in the coming 24 hours when I get home from work
    tonight. The general consensus is it's a good idea and in the end if it dies a death due to inactivity (which I doubt) we can always remove the echo from active service. I have certainly enjoyed the discussions on this topic :)

    Will post an update here and in the general echo when things are set up.

    Best, Paul


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Al@21:4/106 to CyntaxX on Tue Jan 30 13:50:20 2018
    Re: Re: Echomail Data
    By: CyntaxX to Al on Tue Jan 30 2018 03:34 pm

    I am not a developer myself but was reading some developers some
    time ago trying to come up with a "standard" for interbbs traffic.

    I'm there with you. I have no dog in this fight. I know how to manipulate basic code from others to hopefully get it to do what I need, but I couldn't tell you how it works.

    Overnight my BBS machine shutdown (reason unknown).. so it was unavailable. These kind of things make me lean toward an area like FSX_DAT. When the BBS is ready it can deal with new messages and nothing is lost.

    Ttyl :-),
    Al


    ... Hors d'oeuvres--a ham sandwich cut into forty pieces.
    --- SBBSecho 3.03-Linux
    * Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (21:4/106)
  • From RiPuk@21:1/136 to apam on Tue Jan 30 23:07:42 2018
    On Jan 30th 10:22 am apam said...
    I think given 90% of the people here run Mystic so it's likely that the majority will be mystic mods using this system. So it's really going to be InterMystic communication rather than InterBBS.

    Yeah, this.

    On Jan 30th 10:22 am apam said...
    So I wonder if there is another solution. What about something web based, but instead of a different script for a different door, it could be more generalized, kind of a service that many doors could use. You could do something like MQTT where your doors subscribes to a channel, and when a

    This is what I was getting at with my last message about hosting some sort of web service. The bit that bothers me though is that it would need to be decentralised for it to not just get lost when someone gets bored of it. You then get into the situation where you have a shit-tonne of infra just to solve
    a small problem, so then you might as well have just used echomail anyway.

    Not wanting to get onto the 'blockchain gives me a boner' bandwagon (like every
    other tech person in London right now) - but this is exactly the kind of problem it solves. Decentralised, i etc etc. I haven't looked but I'd be amazed
    if there wasn't a simple implementation for basic data storage in existence.

    The BBS's written in modern languages would be able to interface with something
    like this easy, might be somewhat harder in Pascal though, which means adoption would be limited to the cool kids.

    Just my 0.02!

    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 8.9.4)
    * Origin: fORCE9 BBS - London, UK - bbs.force9.org (21:1/136)
  • From apam@21:1/125 to RiPuk on Wed Jan 31 09:52:28 2018
    RiPuk said....

    This is what I was getting at with my last message about hosting some
    sort of
    web service. The bit that bothers me though is that it would need to be decentralised for it to not just get lost when someone gets bored of it.
    You
    then get into the situation where you have a shit-tonne of infra just to
    solve
    a small problem, so then you might as well have just used echomail
    anyway.

    But does it really need to be decentralized? I mean if it's opensource, couldn't someone else just pick it up when who ever was hosting it disappeared?

    It's the same with echomail. If Paul one day gets bored of BBSes and shuts
    down fsxnet, that would leave all the FSX_DAT using programs cut off, but
    they could then just go to another net.

    I think the problem in the past with people getting bored or whatever is
    that they didn't share there scripts.

    Andrew

    --- MagickaBBS v0.9alpha (Linux/x86_64)
    * Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)
  • From Static@21:2/140 to apam on Tue Jan 30 20:16:50 2018
    On 01/30/18, apam said the following...

    So if you write a door, you need to interface with the message base yourself, so that means JAM if it's mystic or magicka, SQLite if it's ENiGMA 1/2, WWIV's format if it''s WWIV, synchronet's format etc...

    This isn't really any different from modular database support in a web application. Though of course those have the advantage of having access to well-vetted public libraries for the purpose.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Subcarrier BBS (21:2/140)
  • From Static@21:2/140 to apam on Tue Jan 30 20:24:12 2018
    On 01/31/18, apam said the following...

    It's the same with echomail. If Paul one day gets bored of BBSes and
    shuts down fsxnet, that would leave all the FSX_DAT using programs cut off, but they could then just go to another net.

    As long as the net is able and willing to pick a new coordinator, it can't really be shut down. You would just have a new nodelist maintainer and zone-level peering arrangement.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Subcarrier BBS (21:2/140)
  • From Ktulu@21:2/122 to apam on Tue Jan 30 20:07:52 2018
    Let's hope this never happens. Paul does such a great job with both the
    network and user support.



    It's the same with echomail. If Paul one day gets bored of BBSes and
    shuts down fsxnet, that would leave all the FSX_DAT using programs cut off, but they could then just go to another net.

    --- Mystic BBS v1.12 A38 2018/01/01 (Windows/64)
    * Origin: Insane Asylum (21:2/122)
  • From apam@21:1/125 to Static on Wed Jan 31 13:15:08 2018
    Static said....

    On 01/30/18, apam said the following...

    So if you write a door, you need to interface with the message base yourself, so that means JAM if it's mystic or magicka, SQLite if
    it's
    ENiGMA 1/2, WWIV's format if it''s WWIV, synchronet's format etc...

    This isn't really any different from modular database support in a web application. Though of course those have the advantage of having access
    to
    well-vetted public libraries for the purpose.

    It depends on your point of view really, for interbbs via a web/database
    you don't need to support several types of databases, because you only need
    one webserver/database to handle interbbs stuff.

    Though I get what you're saying, there could be an common interface to
    various message base formats via some kind of compatibility layer, but who wants
    to write that? and in what language?

    Far easier to write something to post / get data from a web server using already available libraries.

    Andrew

    --- MagickaBBS v0.9alpha (Linux/x86_64)
    * Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)
  • From xqtr@21:1/111 to All on Thu Feb 1 18:04:20 2018
    My thoughts on the matter...

    1. Echomail Data?
    Yes... its a unique way to transfer data through echomail, which is proven to be time-proof :) I mean... we use it till now. Sending some data packets through echomail, won't harm anything. You can de/activate the area whenever you want, its an asynchronous way to transfer data and in a way, its decentralized. Should developers/admins put some restrictions? Definitely.

    2. DOORS Vs Scripts!
    DOORS!!! If someone want to make an App or Game, it should be a DOOR. We should consider Scripts, as a fast way to do something that a DOOR can't or its overwhelming to do as a complete program. We still use DOORs from the DOS
    era.. where are all those scripts from the past? Nowhere. The same will happen again. BBS software developers, should provide an API/Platform for DOOR programmers to use all features, like in this case Echomail Data. An idea is for DOORs that will use echomail data, to import the messages like semaphore files. If a MSG/PKT file exists the DOOR will import it as DATA. So BBS Software must provide the means to export those MSGs in files, even if the message base is stored in the JAM format or in SQLite or other ways.

    3. Web Servers/Services?
    For me... definitely NO! Its not the BBS way. BBSes should be indepedent from the internet. Even now, that we only use Telnet connections, for me is a mistake. Its simpler, its easier, but it shouldn't be the only way. So by using web services we are getting of the "tracks" of the BBS way. Its way more centralized than echomail data and needs more knowledge for simpler/amateur users/programmers to use.

    .----- --- -- -
    | Another Droid BBS
    : Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
    . Contact : xqtr.xqtr@gmail.com

    --- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
    * Origin: Another Droid BBS (21:1/111)
  • From Gryphon@21:1/120 to apam on Sat Feb 3 09:51:52 2018
    On 01/30/18, apam said the following...

    So I've been thinking more on this topic..

    It's really not very portable. If you want to write a game or app for mystic, then sure it will work. If you want to write a game or app for Magicka, that will work too, but if you want to write a game or app for any bbs it gets a bit trickier.

    So if you write a door, you need to interface with the message base yourself, so that means JAM if it's mystic or magicka, SQLite if it's ENiGMA 1/2,
    WWIV's format if it''s WWIV, synchronet's format etc...


    I think I've made it pretty clear that the whole reason I wrote these IBBS
    apps is to make use of an existing app used in Synchronet (and inherent methodology) Until now, that app was only availble to Synchronet sysops.

    I think given 90% of the people here run Mystic so it's likely that the majority will be mystic mods using this system. So it's really going to
    be InterMystic communication rather than InterBBS.

    And the Synchronet BBS List app was only going to be useful to Synchronet BBSes... until somebody came along to change that.

    Which is fine I suppose, given that people seem to prefer to write mods than doors anyway.

    That's probably a discussion for another thread. Suffice it to say that maintining different code repositories and build environments for each platform is not something that I want to do. At least with MPL, I know that my app
    can be used by any Mystic BBS, whether its on Linux, MAC, Raspberry Pi, or Windows. Conversely, if I wanted to do development in Pascal or C/C++, I'd need to maintain code that would compile and run in each platform, or simply stake a claim on one platform and let the rest go.

    So I wonder if there is another solution. What about something web based, but instead of a different script for a different door, it could be more generalized, kind of a service that many doors could use. You could do something

    I suppose you have to also consider the plusses as well as the minuses for
    this method of data delvery, as opposed to other possible methods.

    like MQTT where your doors subscribes to a channel, and when a door updates, the message is stored in that channel, when it fetches, it gets messages
    from it's channel. That way someone could host this service, and anyone could use it, rather than a different service per door. If that makes sense.

    Anything else that you can offer is going to have an additional overhead that you wouldn't have for the echomail method. With the echomail method, all you have to do is point to an exiting message base and you're done. Echomail is an integral part of any networked BBS, so there's no learning curve or any
    new apps to install and configure. With the MQTT (or http, or ftp etc) option, you force the sysop to download, install, and configure a whole new internet client/server suite onto their system. FWIW, I've seen more than a few
    people have problems (including myself) just setting up python for MRC. I think that using some other service would be a barrier to access.

    I'm on the fence about FSX_DAT now, in that I wonder if sending data over echomail is a good idea or not, regardless if it's going to be sent,
    then a seperate channel would be good.

    So what it really boils down to is the policy of the network. I suppose the beauty of it is that this conversation is only relevant to the different networks and not the technology or methodology of the apps. True, other networks might have a different policy for such an echo base, but their
    policy should not make any difference in this network.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Cyberia BBS | cyberia.darktech.org | San Jose, CA (21:1/120)
  • From Gryphon@21:1/120 to xqtr on Sat Feb 3 10:05:48 2018
    On 02/01/18, xqtr said the following...

    My thoughts on the matter...
    2. DOORS Vs Scripts!
    DOORS!!! If someone want to make an App or Game, it should be a DOOR. We should consider Scripts, as a fast way to do something that a DOOR can't or its overwhelming to do as a complete program. We still use DOORs from the DOS era.. where are all those scripts from the past? Nowhere.

    I'm not sure I agree that an app or a game should always be a door, as
    opposed to a script. I look at MPL as pretty robust programing language. Consider that the BBS functions in MPL are merely library functions. Is MPL's WRITE() function any less of a libray function than OpenDoor's OD_PRINTF(). Also, I seem to remember g00r00 making a comment that he's considering
    removing many of the BBS functions (one-liners, voting booth, last 10
    callers, BBS list) from the BBS itself and using MPL/LUA/Python replacements.

    The other feature for using MPL is that it is platform independant. The MPLs
    I write are the same for all the different platforms of Mystic. If I were to write a game in pascal or C/C++, I'd have to maintain different code
    libraries and build environments. That's not something I really want to do.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Cyberia BBS | cyberia.darktech.org | San Jose, CA (21:1/120)
  • From xqtr@21:1/111 to Gryphon on Sat Feb 3 22:07:16 2018
    I'm not sure I agree that an app or a game should always be a door, as opposed to a script. I look at MPL as pretty robust programing
    language. Consider that the BBS functions in MPL are merely library functions. Is MPL's WRITE() function any less of a libray function than OpenDoor's OD_PRINTF(). Also, I seem to remember g00r00 making a comment that he's considering removing many of the BBS functions (one-liners, voting booth, last 10 callers, BBS list) from the BBS itself and using MPL/LUA/Python replacements.

    First of all, the answer to the question DOORS or Scripts, is something, personally for everyone. Others like scripts, others DOORS. I do my self started writing scripts for Mystic, because it was easy (for me) and as i originally thought cross compile. But after reading some messages from Apam and giving it a second thought, i realized that scripts even if they maybe cross
    OS platform, they are not cross BBS platform. A script for Mystic doesn't work under Enigma and vice versa. So a programmer/developer should ask... does he write programs for a specific BBS server or for ANY BBS? And is this right?

    Its not that i underestimate MPL or other scripting languages. The matter is that scripting languages are for specific systems. BBS software from the beginning of the BBS era, has vanished or not being used any more. At the other hand we still can use DOOR games that was written as programs and compiled unde DOS! And this... because of exactly that! There were programs NOT scripts. When a BBS Software is disappearing, all scripts written for that, will also vanish.

    Another thing is that when you are programming in a Programming Language you have the advantage of having lots of documentation, examples, source code etc. which in Script Languages is not always the case. I don't miss at all, looking and search for documentation about MPL functions (just as an example because i only used Mystic). I am sure that the same thing is going on and for other BBS Programs / Script Languages. Also, in programming languages it would be extremely rare to change the name, type, usage of an all ready well known command/procedure, when in Script Languages happens more often. Other stuff lik memory limits is also a thing, that Programming languages don't have and more.

    The other feature for using MPL is that it is platform independant. The MPLs I write are the same for all the different platforms of Mystic. If
    I were to write a game in pascal or C/C++, I'd have to maintain
    different code libraries and build environments. That's not something I really want to do.

    If we use a crosscompile platform like FreePascal, C, Python then there is no problem about that. It may need some more coding or writing in a more compatible way, but for me personally is acceptable. Also if there is a DOOR library that is all ready written in a cross compiled way, then the most job has all ready done and the programmer is not needed to do something more. Personally i prefer FreePascal which is cross platform and i use or make my
    own libraries/units that are all ready cross compiled.

    Maybe... the mistake we all do, is that we start writing scripts/DOORS using script or programming languages, but we should first build a universal library for DOORs that would be cross compiled. Python would be a great solution for that, even if i don't like it :(

    So, for me... my answer is that i will try to write more DOOR apps than Script for now on. Its not the "right thing" its just how i see the BBS scene, how it started and how it may be better to keep going on in the future. For the same reason i avoid Windows and Web Based solutions for BBS and i prefer Unix/Linux. Its just my way of thinking :) I don't have anything with Mystic or other BBS software, but for me Mystic is not the whole BBS scene and other system / platforms should and must have support.

    So the question is not just "DOORS vs Scripts" but how we should make sure that the BBS scene will stay alive in the future and not make mistakes of the past.

    In summary:
    Doors Vs Scripts : Doors!
    Windows Vs Linux : Linux!
    Closed Source Vs Open Source : Open!

    .----- --- -- -
    | Another Droid BBS
    : Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
    . Contact : xqtr.xqtr@gmail.com

    --- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
    * Origin: Another Droid BBS (21:1/111)
  • From NuSkooler@21:1/121 to xqtr on Sat Feb 3 13:25:06 2018
    On Saturday, February 3rd xqtr was heard saying...
    In summary: Doors Vs Scripts : Doors! Windows Vs Linux : Linux! Closed Source Vs Open Source : Open!

    Depends on the usage. BBS package specific mods are slick. The problem comes when you start talking inter-BBS, games, and so on. For that, doors are certainly nicer.

    It's incredibly easy to write multi-platform code, so that shouldn't really be a barrier to anyone. Language need not matter, either. That's why dropfiles were created.

    There isn't a "best" option for a lot of this stuff. But, BBSing is a small community now, so causing further fragmentation isn't helping anyone. Work together and come up with solutions that works across the board for best results.



    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 8.9.4)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Gryphon@21:1/120 to NuSkooler on Sat Feb 3 13:33:14 2018
    On 02/03/18, NuSkooler said the following...


    On Saturday, February 3rd xqtr was heard saying...
    In summary: Doors Vs Scripts : Doors! Windows Vs Linux : Linux! Close Source Vs Open Source : Open!

    Depends on the usage. BBS package specific mods are slick. The problem comes when you start talking inter-BBS, games, and so on. For that,
    doors are certainly nicer.

    It's incredibly easy to write multi-platform code, so that shouldn't really be a barrier to anyone. Language need not matter, either. That's why dropfiles were created.

    Incredibly easy? Writing the code? Maybe. Compiling the code? Not as
    much. We've heard many times from g00r00 how he's had issues with some platform versions of Mystic while other platforms didn't have the same issue. Back in the day, we had platform options too, just like we do now. We had MS-DOS, PC-DOS, CP/M-86, Sinclair, IBM, Apple, commodore, pet, trs-80. Not
    all software would work with all platforms; just like now. If you look at
    some of the history of some BBS-related doors, you'll find that this
    discussion is not a new phenomina. Space Dynasty was written for Atari ST
    BBS systems but was ported to IBM. But WT-LORD and Virtual Sysop were very popular door games that only ran on on BBS platform each. MajorMudd and Tele-Arena were very popular doors that only ran on MajorBBS. Virtual Sysop was another very popular door that ran only on TBBS systems. I'm not
    familiar with writing games for MBBS, but I do know that TBBS games were in a dBaseIII format, so the code was not portable. Seth Able did write a version of LORD for MBBS, but it too was separate, non-portable code.

    So in the end, we are still dealing with the multi-platform issues, just like we were 30 years ago.

    In the end, I see a matrix

    OS platform: Linux, Windows, Mac, Android, FreeBSD, OS/2
    BBS Platform: Mystic, Synchronet, BBBS, Enigma, <other>
    Language : <native>, C/C++, Pascal, Python, etc.

    In the end, it's not feasable to be all things to everybody. You either play to your own preferences, or you play to the vectors that will grant the most exposure.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Cyberia BBS | cyberia.darktech.org | San Jose, CA (21:1/120)
  • From RiPuk@21:1/136 to Gryphon on Sun Feb 4 01:06:54 2018
    On Feb 3rd 11:07 pm Gryphon said...
    Incredibly easy? Writing the code? Maybe. Compiling the code? Not as much. We've heard many times from g00r00 how he's had issues with some platform versions of Mystic while other platforms didn't have the same issue.

    Isn't that just a product of using a language with very little community behind
    it, based on architectural decisions made eons ago? True, cross platform issues will always exist, and even do with languages that run atop a VM like Java does, but by using a language which has the power of numbers these kinds of issues will be kept to a minimum, and fixed quickly when found.

    Take a look at this: https://insights.stackoverflow.com/survey/2017#technology

    It charts language popularity in 2017 - no prizes for guessing which language doesn't feature ;-)



    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 8.9.4)
    * Origin: fORCE9 BBS - London, UK - bbs.force9.org (21:1/136)
  • From NuSkooler@21:1/121 to Gryphon on Sat Feb 3 23:53:34 2018
    On Saturday, February 3rd Gryphon muttered...
    Incredibly easy? Writing the code? Maybe. Compiling the code?

    Both. We're having a discussion about writing software for modern-ish systems, which is basicaly *nix and Windows. If you're off trying to create a multi-platform system that works with Atari and DOS, then yeah of course that's
    a pain. The systems we're *actually* talking about here though, not really any
    harder to write (or compile) code that work on any of 'em.

    If you use FPC Pascal, Python, Node/JS, C or C++, you can very easiliy have the
    matrix you showed (again, *nix and Windows really) abstracted away from you.

    Perhaps a resource of do's and don'ts for this kind of thing would help people.







    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 8.9.4)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)