Development Ideas

[cognitivegears]

I'm currently working through the documentation on the rest of the views, I hope to have a PR for that in the next couple of days. In the meantime, I wanted to start a discussion about some of the ideas I had for development next, and get your input. Here is the ideas that I had to work on next, and wanted to get thoughts on these as well as see if there are any higher priority items I should be working on instead.

• Additional documentation cleanup, add missing module documentation

• Create a tutorial - either text based or video or both, for how to configure and personalize a Enigma 1/2 BBS

• Create a new generic theme. In particular, I was thinking about a generic theme + scripts so that someone could quickly put "header" art on all menus, make the menus fairly generic besides, and maybe a script to substitute out colors so you can define a "primary", "secondary", etc colors and have it re-skin it. Would make it a lot faster to get going on a new BBS.

• Pie in the sky idea - making a menu editor. In particular, Moebius is an open source, electron based app for editing art files. It would be possible to fork a version that does menu editing, etc right in the app. This would make it possible for non-developers to create a BBS without having to learn hjson, be able to read code for the modules to see what they do, etc.

• Plain ASCII friendly - make the configuration have the ability to be setup for non-ANSI clients. Make some or all of the views work with non-ANSI - i.e. a spinner or menu could work by listing the options and having them type in a response, etc. Then a mechanism to iterate through them one at a time for non-ANSI clients.

• Implement DOORS as v86. Per Native x86 Emulation #212 having an option for a totally embedded, no external dependencies DOOR would be amazing, and v86 seems like a great choice for this. Considering the current door module is "abracadabra", I think "presto" would be the perfect module name for this. :)

Anyway, that list is probably months worth of development. Wanted to get NuSkooler and everyone's thoughts on them, and any other priorities that you might want me or others to tackle first?

[cognitivegears]

Oh I forgot another one:

• Create a mechanism for standard and user/defined "session properties", and implement with some existing functionality plus MCI codes and ACLs. Some examples include: Ability to choose theme before logging in, multiple telnet ports, each one picking a different column width or some other layout etc, maybe even multi-language... Basically anything that could show differently, but only for that session instead of always for the user.

[NuSkooler]

Additional documentation cleanup, add missing module documentation

Yessssssss!

Create a tutorial - either text based or video or both, for how to configure and personalize a Enigma 1/2 BBS

There are a couple videos and blogs linked in the docs, but more are always welcome of course.

Create a new generic theme. In particular, I was thinking about a generic theme + scripts so that someone could quickly put "header" art on all menus, make the menus fairly generic besides, and maybe a script to substitute out colors so you can define a "primary", "secondary", etc colors and have it re-skin it. Would make it a lot faster to get going on a new BBS.

Part of what ENiGMA is about is customization and modding. In a way, I don't add much to the "out of the box" menus for this reason. This feels more like a separate effort to me than Enig itself -- but I'm happy to link to tools such as you describe.

Pie in the sky idea - making a menu editor. In particular, Moebius is an open source, electron based app for editing art files. It would be possible to fork a version that does menu editing, etc right in the app. This would make it possible for non-developers to create a BBS without having to learn hjson, be able to read code for the modules to see what they do, etc.

This has been attempted by a couple people so far. Both projects abandoned. Menus are just ANSI files as you know, but the configuration behind them is fairly complex due to it's flexibility. Or in other words, this is a huge undertaking.

Plain ASCII friendly - make the configuration have the ability to be setup for non-ANSI clients. Make some or all of the views work with non-ANSI - i.e. a spinner or menu could work by listing the options and having them type in a response, etc. Then a mechanism to iterate through them one at a time for non-ANSI clients.

This is really only blocked by #222 -- I plan on tackling that when I have time to mess with this code again. Once in place, some of the Views could be adapted to work in ASCII mode.

Implement DOORS as v86. Per Native x86 Emulation #212 having an option for a totally embedded, no external dependencies DOOR would be amazing, and v86 seems like a great choice for this. Considering the current door module is "abracadabra", I think "presto" would be the perfect module name for this. :)

I like the name :) I'm not sure that a new module would have to exist though, but perhaps. The first steps here are to get v86 working and stdio <> serial/COM or socket <> serial/COM working. Beyond that, it shouldn't be too terribly tricky.

Create a mechanism for standard and user/defined "session properties", and implement with some existing functionality plus MCI codes and ACLs. Some examples include: Ability to choose theme before logging in, multiple telnet ports, each one picking a different column width or some other layout etc, maybe even multi-language... Basically anything that could show differently, but only for that session instead of always for the user.

I may not be fully following this one. However, you can already customize the the login flow however you like -- this could include prompting for a theme. From there set it in the user's session properties (but don't persist) and viola. Same goes for the others as well. You can also use ACS to detect some of these things and direct users to e.g. a different layout/theme/whatever

[cognitivegears]

Additional documentation cleanup, add missing module documentation

Yessssssss!

This is my first priority with the views anyway. As I've been going through them, I've been finding some probable bugs and improvements as well. Some views look like they render more often then they need to, and there are a few other "weirdness" stuff so far. So hopefully besides the documentation I'll also be submitting some PR's for fixes if that is ok.

This has been attempted by a couple people so far. Both projects abandoned. Menus are just ANSI files as you know, but the configuration behind them is fairly complex due to it's flexibility. Or in other words, this is a huge undertaking.

Plain ASCII friendly - make the configuration have the ability to be setup for non-ANSI clients. Make some or all of the views work with non-ANSI - i.e. a spinner or menu could work by listing the options and having them type in a response, etc. Then a mechanism to iterate through them one at a time for non-ANSI clients.

Yeah I kinda figured. Seeing that Moebius is in JS made me a bit interested, as there could even be a bit of code reuse there, but still that one is an outside shot for me to work on at best, and even then long term. :)

Create a new generic theme. In particular, I was thinking about a generic theme + scripts so that someone could quickly put "header" art on all menus, make the menus fairly generic besides, and maybe a script to substitute out colors so you can define a "primary", "secondary", etc colors and have it re-skin it. Would make it a lot faster to get going on a new BBS.

Part of what ENiGMA is about is customization and modding. In a way, I don't add much to the "out of the box" menus for this reason. This feels more like a separate effort to me than Enig itself -- but I'm happy to link to tools such as you describe.

Absolutely, in fact this might be better that way to avoid code bloat. Probably not the first thing I'd do, but might be something I might play with later.

Plain ASCII friendly - make the configuration have the ability to be setup for non-ANSI clients. Make some or all of the views work with non-ANSI - i.e. a spinner or menu could work by listing the options and having them type in a response, etc. Then a mechanism to iterate through them one at a time for non-ANSI clients.

This is really only blocked by #222 -- I plan on tackling that when I have time to mess with this code again. Once in place, some of the Views could be adapted to work in ASCII mode.

Awesome. This one is high on my priority list. I started playing with Enigma 1/2 to work on a BBS that caters to retro computers (I'm also a big retro computer fan) and this is actually a must-have as an option for the BBS I have in mind.

Implement DOORS as v86. Per Native x86 Emulation #212 having an option for a totally embedded, no external dependencies DOOR would be amazing, and v86 seems like a great choice for this. Considering the current door module is "abracadabra", I think "presto" would be the perfect module name for this. :)

I like the name :) I'm not sure that a new module would have to exist though, but perhaps. The first steps here are to get v86 working and stdio <> serial/COM or socket <> serial/COM working. Beyond that, it shouldn't be too terribly tricky.

Yeah, I'm not sure either how hard it would be to integrate into the current module - probably depends on whether the current one would become a if/else maze by adding another type of door to it. This one I'd really, really like to do, as I've also worked on a couple of webassembly projects in the past and it's a lot of fun, but never had a chance to do it on node yet.

Create a mechanism for standard and user/defined "session properties", and implement with some existing functionality plus MCI codes and ACLs. Some examples include: Ability to choose theme before logging in, multiple telnet ports, each one picking a different column width or some other layout etc, maybe even multi-language... Basically anything that could show differently, but only for that session instead of always for the user.

I may not be fully following this one. However, you can already customize the the login flow however you like -- this could include prompting for a theme. From there set it in the user's session properties (but don't persist) and viola. Same goes for the others as well. You can also use ACS to detect some of these things and direct users to e.g. a different layout/theme/whatever

That's great to hear, I'm still digging through code and didn't see that yet - I thought that all properties were persisted, that's fantastic. The over all idea combines with the ASCII one above - ultimately I'd like a BBS that supports plain ASCII, ANSI DOS 40, ANSI DOS 80, ANSI UTF-8 term, and web at a minimum, and stretch goal would be PETSCII and some others. :) Want to make something that is as widely usable as possible. But can't (or don't want to) persist all those, because hopefully people are hopping around from one retro machine to another :)

Thanks so much for the feedback and all your help and involvement. Enigma 1/2 is an impressive achievement, and it's been a lot of fun to start to dig into it. Thank you!

[NuSkooler]

Awesome. This one is high on my priority list. I started playing with Enigma 1/2 to work on a BBS that caters to retro computers (I'm also a big retro computer fan) and this is actually a must-have as an option for the BBS I have in mind.

Totally agree. I can't even "dial" into my own BBS with my DOS machine with my favorite terminal clients as they don't support CPR :(

Currently Enig supports CP437 (DOS) and UTF-8 out of that list. Technically ANSI/ASCII don't matter to enig, other than the issue of MCI codes (the #222 thing). 80/40 can be handled with a theme and a ACS check currently. PETSCII probably just needs a encoder implemented and perhaps some work in the art handling (mapping of ext -> encoding, etc.)