What to name a project...

[EArmbrust]

So here's my idea...I'd like to (and have for some time) write a Worldgroup/MajorBBS compatible BBS software. Mind you, certain things would be stripped from the baseline...such as PPP/Modem, C/S, File Libraries, GUI frontend, Web/Mail (basically of the ICO), and Teleconference.

However, they wouldn't be gone, per se. Things I would like to do are:
* Make the server a script host for LUA scripts, and possibly Python/PHP as well. (This is simply because the interpereter can be a part of the script host, unlike most Java implementations)
* Port over ircii (heavily modified) or create a new irc client that has an ircii/BitchX/ScrollZ-like interface with a user customizable interface and settings (like CTCP version replies).
* Server linking in the baseline, with statistics reporting between servers. Somewhat similar to how irc servers link.
* Apache/ISAPI modules to allow crosstalk between the server and a web server.
* A (e)links-like web browser in the baseline.
* Module forwarding, so that the server can be streamlined to function as a host for nearly any module/script rather than having to dig through endless menus to get to a module, or screen scrape for the proper commands. Basically, this would allow third party clients to be made so that they could be placed directly into a module to handle C/S communications specific to the implementation, rather than the somewhat cludgy interface many C/S clients utilize.
* include support and version checking of MBBS, WG1/2, and WG3/NT modules, so that all may run against the new server. (This would require a bit of work and patience, somewhat like emulating a console system)
* Remove the 256 user limit (effectively remove the GSBL in favor a more standard multithreaded environment), as well as the current channel implementation, while maintaining a channel "compatibility" layer so that modules relying on the information will still function. Channels could be referred to by their octal in the dynamic array/list that is the socket set or similar.

For modules, the "standard" modules would include:
-Local and linked teleconferences
-A sysop "console" similar to the MBBS/WGDOS pre-up server interface, as well as the post-up server interface.
-Dialup access, like was done originally with the ICO.
-PPP Access layer that functions as a C/S type module, so that existing ISP's still running Worldgroup can efficiently convert.
-File libraries module, with support for removable media, and remote media such as NFS and remote FTP/HTTP repositories.
-A brand new C/S client and module which would function on top of TCP and Dialup, using the Gecko rendering engine for cross-platform compatibility. (Mozilla/Firefox)
-A mail serving module, with an Apache/ISAPI module, that allows full email access through SMTP/POP3 as well as webmail.
-SSL/SSH connectivity layer so that connections can be made securely for all users, including the Sysop.

I know it's a bit ambitious, but taking a look at the roster of individuals, and the experience they bring to the table, I don't see it as being out of the question. Now, I'm fully aware that the ability to use Worldgroup, MajorBBS, or Galacticomm in the name is most likely out of the question. I think having at least support for Worldgroup 2.0 modules would be paramount to it's success. 1.01 and 3.0 would be wonderful, but from what I see there are very few actual upgrades on the 3.x series, and almost all of the 1.xx modules either work on 2.0 systems, or have 2.0 compatible counterparts. So, ideally, getting full compatibility with 2.0 modules would be of high priority.

All of this would likely be released under a modified BSD or LGPL license, so that widespread use could become possible easier. One of the initial downfalls of BBS', in my opinion, was the secretive and greedy nature of many developers. (Greedy as in with their code, not their money.)
Galacticomm was, in my opinion, fairly liberal with it's code distribution policies compared to most other BBS software developers. I see no reason why we should try to "turn a buck" on something that we love and want to see make a return. Interfacing with, and leveraging against, current technologies would be the best course of action at this point. There's no way BBS' will topple the internet in their current state, if ever.
I'd love to put something together, at least a proof-of-concept, to show people that BBS' don't die, they just hibernate.

With all of that said...what do you guys think a good name would be?

[dspain]

So here's my idea...I'd like to (and have for some time) write a Worldgroup/MajorBBS compatible BBS software. Mind you, certain things would be stripped from the baseline...such as PPP/Modem, C/S, File Libraries, GUI frontend, Web/Mail (basically of the ICO), and Teleconference.

However, they wouldn't be gone, per se. Things I would like to do are:
* Make the server a script host for LUA scripts, and possibly Python/PHP as well. (This is simply because the interpereter can be a part of the script host, unlike most Java implementations)
* Port over ircii (heavily modified) or create a new irc client that has an ircii/BitchX/ScrollZ-like interface with a user customizable interface and settings (like CTCP version replies).
* Server linking in the baseline, with statistics reporting between servers. Somewhat similar to how irc servers link.
* Apache/ISAPI modules to allow crosstalk between the server and a web server.
* A (e)links-like web browser in the baseline.
* Module forwarding, so that the server can be streamlined to function as a host for nearly any module/script rather than having to dig through endless menus to get to a module, or screen scrape for the proper commands. Basically, this would allow third party clients to be made so that they could be placed directly into a module to handle C/S communications specific to the implementation, rather than the somewhat cludgy interface many C/S clients utilize.
* include support and version checking of MBBS, WG1/2, and WG3/NT modules, so that all may run against the new server. (This would require a bit of work and patience, somewhat like emulating a console system)
* Remove the 256 user limit (effectively remove the GSBL in favor a more standard multithreaded environment), as well as the current channel implementation, while maintaining a channel "compatibility" layer so that modules relying on the information will still function. Channels could be referred to by their octal in the dynamic array/list that is the socket set or similar.

For modules, the "standard" modules would include:
-Local and linked teleconferences
-A sysop "console" similar to the MBBS/WGDOS pre-up server interface, as well as the post-up server interface.
-Dialup access, like was done originally with the ICO.
-PPP Access layer that functions as a C/S type module, so that existing ISP's still running Worldgroup can efficiently convert.
-File libraries module, with support for removable media, and remote media such as NFS and remote FTP/HTTP repositories.
-A brand new C/S client and module which would function on top of TCP and Dialup, using the Gecko rendering engine for cross-platform compatibility. (Mozilla/Firefox)
-A mail serving module, with an Apache/ISAPI module, that allows full email access through SMTP/POP3 as well as webmail.
-SSL/SSH connectivity layer so that connections can be made securely for all users, including the Sysop.

I know it's a bit ambitious, but taking a look at the roster of individuals, and the experience they bring to the table, I don't see it as being out of the question. Now, I'm fully aware that the ability to use Worldgroup, MajorBBS, or Galacticomm in the name is most likely out of the question. I think having at least support for Worldgroup 2.0 modules would be paramount to it's success. 1.01 and 3.0 would be wonderful, but from what I see there are very few actual upgrades on the 3.x series, and almost all of the 1.xx modules either work on 2.0 systems, or have 2.0 compatible counterparts. So, ideally, getting full compatibility with 2.0 modules would be of high priority.

All of this would likely be released under a modified BSD or LGPL license, so that widespread use could become possible easier. One of the initial downfalls of BBS', in my opinion, was the secretive and greedy nature of many developers. (Greedy as in with their code, not their money.)
Galacticomm was, in my opinion, fairly liberal with it's code distribution policies compared to most other BBS software developers. I see no reason why we should try to "turn a buck" on something that we love and want to see make a return. Interfacing with, and leveraging against, current technologies would be the best course of action at this point. There's no way BBS' will topple the internet in their current state, if ever.
I'd love to put something together, at least a proof-of-concept, to show people that BBS' don't die, they just hibernate.

With all of that said...what do you guys think a good name would be?

MajorLinux MajorUnix MajorBSD
sorta keeps its old familiarty but shows what its powered by so people know its what they used to know without DOS/NT


would you do a gui portion compatible with gnome/kde,etc?

[EArmbrust]

Well, like I said...it would likely be a "module". In this case, the "module" would hook via either a TCP or UNIX port on the remote/local system (respectively) and have a WG 3.2 "basic" interface or advanced interface similar to the ansi one we all know in love. On the flipside, I was thinking of blasting back to the past with some pdcurses based CLI interface, nearly identical to the server interface (remember the fast two finger toggle shutdowns?) Given that the DLL interface for most of the MBBS/WG modules are fairly exposed through different means, and that the format is a bit "dumb" compared to some of the newer compiler schemes, it should be fairly simple to interface with them. Granted, simple could mean "easier than hacking a gibson". I can assume that majormud would be a royal nightmare...though likely the bar for which to aim. Lately, I've had my work cut out with me porting some *nix stuff over to .NET (don't even ask), but I hope to get something pounded out for at least a proof of concept.

[frcorey]

Well, like I said...it would likely be a "module". In this case, the "module" would hook via either a TCP or UNIX port on the remote/local system (respectively) and have a WG 3.2 "basic" interface or advanced interface similar to the ansi one we all know in love. On the flipside, I was thinking of blasting back to the past with some pdcurses based CLI interface, nearly identical to the server interface (remember the fast two finger toggle shutdowns?) Given that the DLL interface for most of the MBBS/WG modules are fairly exposed through different means, and that the format is a bit "dumb" compared to some of the newer compiler schemes, it should be fairly simple to interface with them. Granted, simple could mean "easier than hacking a gibson". I can assume that majormud would be a royal nightmare...though likely the bar for which to aim. Lately, I've had my work cut out with me porting some *nix stuff over to .NET (don't even ask), but I hope to get something pounded out for at least a proof of concept.

Majormud?
thats funny, even the people who own it can't fix it.

[dspain]

Well, like I said...it would likely be a "module". In this case, the "module" would hook via either a TCP or UNIX port on the remote/local system (respectively) and have a WG 3.2 "basic" interface or advanced interface similar to the ansi one we all know in love. On the flipside, I was thinking of blasting back to the past with some pdcurses based CLI interface, nearly identical to the server interface (remember the fast two finger toggle shutdowns?) Given that the DLL interface for most of the MBBS/WG modules are fairly exposed through different means, and that the format is a bit "dumb" compared to some of the newer compiler schemes, it should be fairly simple to interface with them. Granted, simple could mean "easier than hacking a gibson". I can assume that majormud would be a royal nightmare...though likely the bar for which to aim. Lately, I've had my work cut out with me porting some *nix stuff over to .NET (don't even ask), but I hope to get something pounded out for at least a proof of concept.

Majormud?
thats funny, even the people who own it can't fix it.

its actually funy i have the code to 1.1m and if you look at it theres a point when executing a thievery skill where it switches the mbk prf's a message block then prf's another message block thats supposed to be in another file but its trying to read it from its current mbk.
therefor you get a catastro error. simple fix would be to do a rstmbk(); or setmbk to the other file pointer but nope that thievery bug still crashes in 1.11p the newest one they have.

if they wopnt fix anything that small imagine if there were big problems, lol

[EArmbrust]

So, I know I'm digging up and old thread... but, I thought an update might be in store.

I've actually begun work on this. Right now it has the inauspicious name of "mbbsclone". Yeah, truly amazing. Here's some of the stuff currently in the works:

* c++ core, designed to handle multi-core/cpu systems.
* ncurses (and possibly pdcurses) "frontend" a la MBBS/WG 1/2
* library of "window" functions for console
* Python 2.5 scripting interface, allowing "module" development without the need for a recompile, or even a restart of the server
* telnet server, for remote connection
* MySQL/sqlite data backend. Even sqlite, being a disk based database is as efficient as BTRIEVE.

Some things I've planned to remove from the "feature list" that MBBS had that I found to be limitations in a current setting:

* 256 max user limit. This is a no-brainer.
* Local sysop emulation. This isn't needed, since emulation will be able to be done through a remote or local (unix socket) connection. On Windows machines, a local network connection can be made as well.
* GSBL. Yes, the GSBL won't be implemented. At least, not in the way it's recognized currently. Much of what the GSBL did has been implemented in the OS now.
* Phar Lap. This is just way too antiquated and useless at this point.
* Btrieve. See above.
* Maintenance. Yes, no more 3AM downtime. Maintenance will be part of the core. A database optimization can be run for MySQL, if need be.



One of the really cool things about Python, and why I chose it over LUA (which is incredible for embedding...) is the ability to drop out to a module, or library (so or dll). That means that a developer, if they wish, can develop code and compile it to native code and use the Python script as a stub. While that doesn't prevent decompilation at all, it does provide some people with more "peace of mind". Additionally, it would allow commercial modules without preventing open source ones. Plus, anyone with Python knowledge can pick up a code reference and begin coding something worthwhile immediately, instead of having to learn an antiquated scheme and syntax. Additionally, since Python is open source, the scripting engine will get frequent updates. I'll most likely find or create a "unified datafile format" so that blocks of text, and interface options can all be edited with a homegrown editor. At the current time, I don't see loading of MBBS/WG modules as a possibility... but with some work it may happen. Basically, all of the functionality, with the exception of the console and networking, will be handled by scripting. That will allow the most flexibility for the system. Now, I know this isn't exactly directly MBBS related, as it is a project not even touching the core of what MBBS is. I do however feel that it is a good way to go. Rather than reimplementing the wheel, so to speak, I've begun to rebuild a wheel with modern technology. That way, instead of fighting the effects of aging, the server can roll with it.

[dspain]

So, I know I'm digging up and old thread... but, I thought an update might be in store.

I've actually begun work on this. Right now it has the inauspicious name of "mbbsclone". Yeah, truly amazing. Here's some of the stuff currently in the works:

* c++ core, designed to handle multi-core/cpu systems.
* ncurses (and possibly pdcurses) "frontend" a la MBBS/WG 1/2
* library of "window" functions for console
* Python 2.5 scripting interface, allowing "module" development without the need for a recompile, or even a restart of the server
* telnet server, for remote connection
* MySQL/sqlite data backend. Even sqlite, being a disk based database is as efficient as BTRIEVE.

Some things I've planned to remove from the "feature list" that MBBS had that I found to be limitations in a current setting:

* 256 max user limit. This is a no-brainer.
* Local sysop emulation. This isn't needed, since emulation will be able to be done through a remote or local (unix socket) connection. On Windows machines, a local network connection can be made as well.
* GSBL. Yes, the GSBL won't be implemented. At least, not in the way it's recognized currently. Much of what the GSBL did has been implemented in the OS now.
* Phar Lap. This is just way too antiquated and useless at this point.
* Btrieve. See above.
* Maintenance. Yes, no more 3AM downtime. Maintenance will be part of the core. A database optimization can be run for MySQL, if need be.



One of the really cool things about Python, and why I chose it over LUA (which is incredible for embedding...) is the ability to drop out to a module, or library (so or dll). That means that a developer, if they wish, can develop code and compile it to native code and use the Python script as a stub. While that doesn't prevent decompilation at all, it does provide some people with more "peace of mind". Additionally, it would allow commercial modules without preventing open source ones. Plus, anyone with Python knowledge can pick up a code reference and begin coding something worthwhile immediately, instead of having to learn an antiquated scheme and syntax. Additionally, since Python is open source, the scripting engine will get frequent updates. I'll most likely find or create a "unified datafile format" so that blocks of text, and interface options can all be edited with a homegrown editor. At the current time, I don't see loading of MBBS/WG modules as a possibility... but with some work it may happen. Basically, all of the functionality, with the exception of the console and networking, will be handled by scripting. That will allow the most flexibility for the system. Now, I know this isn't exactly directly MBBS related, as it is a project not even touching the core of what MBBS is. I do however feel that it is a good way to go. Rather than reimplementing the wheel, so to speak, I've begun to rebuild a wheel with modern technology. That way, instead of fighting the effects of aging, the server can roll with it.

kewl im doing the same thing, i call mine MajorNIX it has the look and feel of how majorbbs looked but thats it, all the code is authentic.

as far as loading the modules why not get permission from Rick and write it in your core to load em? this way you can still utilize older addons.
im currently tinkering with getting WGNT to load older modules from mbbs 6.25/wg1/wg2.
i began a majorbbs look-alike years ago when i thought the product was going nowhere but with Rick bringing it back and bringing it up to speed with modern compilers i moved over to a linux project since microsoft is chasing people in the nix direction anyway with their 'since ya wont buy vista ill break XP with SP3 and stop selling it and force ya to use it' attitude.
since that announcement redhat sales have increased and more than 12,000 downloads of mandriva took place.
so i figured what the hell why not offer something for that market.

i agree with you the whole 256 user limit pointless now, should have been pointless under NT but with majorbbs what a breakthrough of its time eh?

i was actually looking at the gsbl source other day comparing it to another bbs package that supports 256 users and boy is there a difference.

anyhow keep us informed!