this logic is for a sorta neocities style site.

for those who don't know, I tried and almost succeeded in making a simple text chat message box on neocities. problem? they forbid scripts from saving to a text file on the server. without a middle point of reference other users cannot see whats been typed.

a simple fix is to use a script to write a simple textfile to the user's PC thus saving the contents of the chat locally. this can then be loaded and modified each time that user loads the page.

problem; other users still can't see eachother's messages so it's kinda moot point. but it's progress.

the best way to solve this dilema is to create a chat relay server off the website on the site dev's computer. set it to listen and have the website check for the server at a given IP address. the server could realistically save and relay messages even if users are offline. But changing the server IP would have to be done manually. so every time the site dev's machine changes it's IP address the site dev will have to log-in and update the script.

sadly there is no way around this. but it's good enough.

thats basic chat relay logic in a nutshell.

to include images you'd have to create a form which updates a scroll-barred frame rather than a standard text box. and messages would have to have markers in front and behind for the code to distinguish starts and stops of data segments and type. for text it'd just update a .txt file. but for any other document the server would have to make a new file and append the recieved message as binary and save then leave a log in the chat .txt document stating the file name and location with a detectable wrapper..

when a user views the message the server will then send the file's binary data with wrappers to the client, and the client will create a local copy of the file and link it locally into their own chat .

for flash, the only difference for a flash file is the client would have to do an extra operation of adding a javascript SWFObject wrapper around the file for display.

for non-displayable/visible files, a difference is the client would not be sent the file on message view. instead a simple hyperlink would be placed where when clicked it runs a script to request the file to be copied from the server. then saves what it gets back locally.

this is the full logic for one channel.

to make multiple channels the server will likely need a folder named per channel for ease of use.

managing chat storage is a different thing entirely. that would be done with another script which will check a file's creation date and time and delete anything over a certain set limit. or a log by user name that created a file limiting each user to so much storage. or a time record limiting a user so many messages/bytes per minute.

any questions about this logic? ask. who knows I may have messed something up somewhere.

_________________

Neocities being anti-geocities? Anti-freedom? What the hell? Now, even the open source and/or digital freedom goods/services are turning their backs for the nameless and faceless corporations? Tis a sad tale, indeed!

But yeah, why not we test it?

Other than the chat, I recall that there were terminal like irc clients, like unix-like. Maybe that would be the best in progress? I'm going to look into terminal like irc clients. I don't care how old it is. The fact that it might hold relevancy is what counts.

Well, geocities back in the day didn't let scripts either. It was during the yahoo era that it became a thing.


[/quote]
I look forward to your success.

_________________