inter-session communication

[melvin2001]

I have been tinkering with the idea of some kind of multi-user environments... such as multi player games or collaborative writing space. the main issue i have come across is there is no model in place for communicating between running instances of the same program (or different programs for that matter). I propose adding functionality something like this:

open (Port(#) or some ID #) for sessioncomm as #ses

print #sescom, "onconnect [sesconnect]"
print #sescom, "ondatareceive [sesdatarec]
wait


etc. etc....

then what would happen is while the program is "waiting" it is looking for incoming connections from other running programs, or data received into a buffer. when such an event occurs the associated block is run. kind of like user generated events in the GUI for liberty basic. then of course you would have to have some kind of command to return lines from the buffer or the whole buffer or whatever... similar to the commands i have seen with SQL. there is obviously a lot more that would have to go into making this something thats actually worth implementing.


also something that would make my day, and is very loosely related to the above feature request is the ability to add functionality to the "wait" command. meaning we can then have the program doing something while it is waiting, without having to make the program get stuck in a while loop. for instance, if we wanted to periodically have the program check for changes in a text file, but still let the user interact with the program. not really sure how the syntax for that would be structured, but maybe you could print a command to a #wait handle with a [] that would be run, also there would have to be some kind of timer event involved to keep it from eating all the CPU.


these are just ideas i had in-between doing nothing at work the past few days, they are by no means intended to be implimented without some serious discussion by someone that actually knows what the heck they are talking about (unlike myself). and who knows, this stuff may just add complexity to runbasic and make it harder to learn, which is pretty much the opposite of carl's vision i believe...so please, comment away!

[carlgundel]

melvin2001 said:

I have been tinkering with the idea of some kind of multi-user environments... such as multi player games or collaborative writing space. the main issue i have come across is there is no model in place for communicating between running instances of the same program (or different programs for that matter). I propose adding functionality something like this:

open (Port(#) or some ID #) for sessioncomm as #ses

print #sescom, "onconnect [sesconnect]"
print #sescom, "ondatareceive [sesdatarec]
wait


etc. etc....

then what would happen is while the program is "waiting" it is looking for incoming connections from other running programs, or data received into a buffer. when such an event occurs the associated block is run. kind of like user generated events in the GUI for liberty basic. then of course you would have to have some kind of command to return lines from the buffer or the whole buffer or whatever... similar to the commands i have seen with SQL. there is obviously a lot more that would have to go into making this something thats actually worth implementing.


also something that would make my day, and is very loosely related to the above feature request is the ability to add functionality to the "wait" command. meaning we can then have the program doing something while it is waiting, without having to make the program get stuck in a while loop. for instance, if we wanted to periodically have the program check for changes in a text file, but still let the user interact with the program. not really sure how the syntax for that would be structured, but maybe you could print a command to a #wait handle with a [] that would be run, also there would have to be some kind of timer event involved to keep it from eating all the CPU.


these are just ideas i had in-between doing nothing at work the past few days, they are by no means intended to be implimented without some serious discussion by someone that actually knows what the heck they are talking about (unlike myself). and who knows, this stuff may just add complexity to runbasic and make it harder to learn, which is pretty much the opposite of carl's vision i believe...so please, comment away!

Consider using a database to hold shared data.

-Carl

[melvin2001]

carlgundel said:

Consider using a database to hold shared data.

-Carl

a database would work to store data, but how would you detect a data change in a timely manner without putting the program in a loop (which ultimately will cause the program to timeout after 30 seconds or so). if there was some kind of "received data" event that called a SUB then you wouldn't have to loop.

[Brent]

The root of the problem is that the HTTP protocol, by design, is stateless. It is unable to maintain an interactive socket connection. To do so requires a second (possibly custom-made) server. And if it absolutely must be done in a web browser, your options are Java and Flash.

[carlgundel]

melvin2001 said:

carlgundel said:

Consider using a database to hold shared data.

-Carl

a database would work to store data, but how would you detect a data change in a timely manner without putting the program in a loop (which ultimately will cause the program to timeout after 30 seconds or so). if there was some kind of "received data" event that called a SUB then you wouldn't have to loop.

You might be able to use Javascript to poll the server. AFAIK there isn't any other way to do it. Maybe some sort of browser plugin would do the trick, but that's outside the scope of RB.

-Carl

[wurlde]

I've been using a RAMDisk, control files and JS timing for what you're requiring, also to store global vars used in more than one RB application and "daemons" simultaneously (I'm doing an OGame-like site, now I'm trying to test a new option... but that's another history)