Welcome, Guest. Please Login or Register.
Oct 29th, 2020, 11:47am

Home Home Help Help Search Search Members Members Login Login Register Register
Arimaa Forum New website & new client


   Arimaa Forum
   Arimaa
   Site Discussion
(Moderator: supersamu)
   New website & new client
« Previous topic | Next topic »
Pages: 1 2 3  Reply Reply Notify of replies Notify of replies Send Topic Send Topic Print Print
   Author  Topic: New website & new client  (Read 4356 times)
Brendan_M
Forum Full Member
***



Arimaa player #8106

   


Gender: male
Posts: 21
Re: New website & new client
« Reply #15 on: Jan 17th, 2015, 5:15am »
Quote Quote Modify Modify

Hey, thanks Leo, I've sent you an instant message
If anyone is interested the site can be seen at http://arimaa.club
And the code is at https://github.com/brendanator/arimaa
 
Any suggestions or pull requests are welcome
My rate of progress will definitely be slower during the world championships but it should pick up afterward
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #16 on: Jan 26th, 2015, 6:20pm »
Quote Quote Modify Modify

Thanks, Brendan! As I told you by email, your project looks very promising, let's try to gather strengths to complete it.
 
As you know, I am currently doing some fixes to the chatroom (which are starting to look like a complete reworking), and I would like to discuss the technicalities to make the chatroom compatible with your framework - and development frameworks.
 
First off, I am considering a change in the chat log format and chat protocol that would make it possible to keep the log unified while allowing versioning and handling any future updates.
 
The current log format is such:
 
time<TAB>user<TAB>cmd[<TAB>color<TAB>text]<NL>
 
I am considering using the following new format for all future versions:
 
time<SPC>version<TAB>user<TAB>msg<NL>
 
The space after time instead of the tab is there to mark the new format unambiguously and in a faster way (no parsing of the second token required to check for a number instead of a user name).
 
The tabs around the user name remain necessary as some older "Guest NNNNNN" names contained spaces. Alternatively, we could also escape those spaces by processing the log and in all future writes.
 
Merging the command and data makes storing future commands with any number of arguments more consistent. So, what is currently stored as
 
msg<TAB>000000<TAB>hello
 
would become (with the default color):
 
msg hello
 
and with text color and background color (yes, some kind of colored speech balloons are in the work):
 
msgc 000040/F0F0FF hello
 
So, msg is a command with one argument (the text), whereas msgc is a command with two arguments (colors, then text), and the arguments are separated by just spaces, not tabs.
 
I am working on a kick command that woud use spaces the same way:
 
Input: /kick browni3141 Forgot to log out of the chatroom before his WC game.
 
stored as:
 
123467890<SPC>2<TAB>Janzert<TAB>kick browni3141 Forgot to log out of the chatroom before his WC game.
 
Next, I have converted the chatroom to html5 but it is still pure html/css/js, no framework used, so I am wondering how to best integrate it into your project.
 
I am working on separating the code but have not gone full length into encapsulating the whole chatroom. Do you have any recommendations for that?
 
And one last thing (although I have a hundred more to list): I am working on a command to display an Arimaa board position in place of a chat message, using HTML5 canvas. How to best integrate it within your project?
 
I believe the discussions about the functionalities would benefit from the input from the whole community, so anybody reading this please spread the word and bring up feedback! Smiley
 
Thanks!
IP Logged
Janzert
Forum Guru
*****



Arimaa player #247

   


Gender: male
Posts: 1014
Re: New website & new client
« Reply #17 on: Jan 26th, 2015, 8:44pm »
Quote Quote Modify Modify

one chat feature I've wished for more than once is for the archive to allow get requests to act as permalinks to a specific day, (e.g. chat/arch.php?date=[whatever date format you care to support]) maybe even ?date=blah#time to anchor to the specific time?
 
Janzert
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #18 on: Jan 27th, 2015, 6:33pm »
Quote Quote Modify Modify

Hi Janzert,
 
Sure, such a permalink would be useful, and it is easy to implement, I have added it into my endless list of action items Smiley Time zones would need to be taken into account, as not all viewers will agree on when midnight sits.
 
I am also considering adding a command to call the archive from the chatroom input line:
 
/arch yesterday
/arch Jan 15
etc.
 
I also pondered about displaying the archive logs in the chat window itself, but that would make the archive accessible only to logged in users, something that we discussed years ago. Permalinks would still work but would require logging in before viewing the content. I am not sure if this is a good idea.
 
Another improvement to the archive viewer would be the ability to select a time range rather than a 24 hour span YLT.
 
Since you are there, I have a question about improving things around the progressive polling frequency, as I am not entirely clear about the logic of it. It seems to me that currently, when the frequency is low, sending a message will have to wait a long time for the update timer to allow the next request.
 
Thanks!
« Last Edit: Jan 27th, 2015, 6:34pm by leo » IP Logged
Janzert
Forum Guru
*****



Arimaa player #247

   


Gender: male
Posts: 1014
Re: New website & new client
« Reply #19 on: Jan 28th, 2015, 10:42am »
Quote Quote Modify Modify

I have a small preference that the archive remains openly available. But I also wouldn't bother adjusting the archive display to local time.  Tongue
 
I've lost my copy of the chat source years ago and haven't looked at it in even longer. From what I recall though, any sent message should go out immediately and also reset the polling frequency to its quickest interval.  
 
I did just recall another thing I would like to see change, even more than the archive link. Wink The auth code should be moved out of the url. So that copy and pasting the url somewhere public doesn't reveal sensitive information.
 
Janzert
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #20 on: Jan 28th, 2015, 7:04pm »
Quote Quote Modify Modify

Thanks, Janzert!
 
I am not sure I get you, but the archive viewer is already in the local time of the browser just like the chatroom. The problem I was seeing is that a permalink should contain either a gmt time or a time zone to ensure that the span and anchor work around the world for any viewer.
 
The message sending function sends it right away indeed, then turns off stand by if on (stand by is more or less independent from the progressive slowdown), then calls the polling function, but that latter function first checks the status of the polling activity and aborts if any request is scheduled, even in a long time. I would add a frequency reset in the message sending function but I am wary of touching the many variables that you used for the progressive polling, it would also require cancelling the timer for the next scheduled request I guess.
 
I am totally with you to remove the authentication from the url, and Harvestsnow will even more. That will require changes to the gameroom code though, as that url is generated by the gameroom to open the chatroom. Maybe the chatroom could simply share the session with the gameroom - I don't quite remember why we didn't implemented it so in the beginning, I know it was considered. If the archive remains public, and even more if the chatroom gets integrated into the gameroom as in Brendan's project, then the need for a separate authentication and a list of logged in users would belong to the past.
 
A note about user options in the chatroom: The development version uses web storage instead of cookies, to save bandwidth (as cookies are sent along with all the polling requests). I am devising the local storage keys with "chat." prepended in order to prevent conflicts with any future local storage used by the rest of the site, gameroom and other sections. I am not sure if this is enough, advices are welcome.
 
One drawback of local storage is that it is browser specific, which means that if you use several browsers, you will have to set your options in each. A solution could be to store the options on the server, in some kind of user profile table, and a user's options would come up on any browser and any computer. This might turn out too much development though.
« Last Edit: Jan 28th, 2015, 7:08pm by leo » IP Logged
Janzert
Forum Guru
*****



Arimaa player #247

   


Gender: male
Posts: 1014
Re: New website & new client
« Reply #21 on: Jan 30th, 2015, 3:49pm »
Quote Quote Modify Modify

on Jan 28th, 2015, 7:04pm, leo wrote:
Thanks, Janzert!
 
I am not sure I get you, but the archive viewer is already in the local time of the browser just like the chatroom. The problem I was seeing is that a permalink should contain either a gmt time or a time zone to ensure that the span and anchor work around the world for any viewer.

 
Sorry, I was just trying to say that the time localization is not that important to me. In some ways I think it actually hurts since people have to refer to past discussion via relative time stamps.
 
Quote:
The message sending function sends it right away indeed, then turns off stand by if on (stand by is more or less independent from the progressive slowdown), then calls the polling function, but that latter function first checks the status of the polling activity and aborts if any request is scheduled, even in a long time. I would add a frequency reset in the message sending function but I am wary of touching the many variables that you used for the progressive polling, it would also require cancelling the timer for the next scheduled request I guess.

 
If you like I don't mind looking at it again, but point me to a location to find the current code.
 
I probably wouldn't worry a whole lot about an extra request getting sent, i.e. cancelling an already scheduled one doesn't gain much.
 
Quote:
I am totally with you to remove the authentication from the url, and Harvestsnow will even more. That will require changes to the gameroom code though, as that url is generated by the gameroom to open the chatroom. Maybe the chatroom could simply share the session with the gameroom - I don't quite remember why we didn't implemented it so in the beginning, I know it was considered. If the archive remains public, and even more if the chatroom gets integrated into the gameroom as in Brendan's project, then the need for a separate authentication and a list of logged in users would belong to the past.

 
I wasn't really involved with this part, so not sure why the decisions went the way they did.
 
One caution on chat integrated in the gameroom itself is the effect of game commentary when any logged in player also receives chat. I think this is probably fine though if every game also gains its own kibitzing chat. Except that other potential kibitzers won't even know there is a discussion in progress unless they have the game open. What I think would be ideal is if the kibitz chat stayed with a game permanently and replaced the current game comment system.
 
Quote:
A note about user options in the chatroom: The development version uses web storage instead of cookies, to save bandwidth (as cookies are sent along with all the polling requests). I am devising the local storage keys with "chat." prepended in order to prevent conflicts with any future local storage used by the rest of the site, gameroom and other sections. I am not sure if this is enough, advices are welcome.
 
One drawback of local storage is that it is browser specific, which means that if you use several browsers, you will have to set your options in each. A solution could be to store the options on the server, in some kind of user profile table, and a user's options would come up on any browser and any computer. This might turn out too much development though.

 
Given that the chat options shouldn't be that terrible for the user to reproduce I wouldn't worry too much about their permanency. Also having different settings on different devices may very well be a desired thing fairly frequently.
 
Janzert
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #22 on: Jan 30th, 2015, 6:59pm »
Quote Quote Modify Modify

on Jan 30th, 2015, 3:49pm, Janzert wrote:
Sorry, I was just trying to say that the time localization is not that important to me. In some ways I think it actually hurts since people have to refer to past discussion via relative time stamps.

I will add an option to display the time stamps in UTC so that people can more easily refer to a point in the archive.
 
Quote:
If you like I don't mind looking at it again, but point me to a location to find the current code.

The send function is at line 82 of chat.js (another function was added at 110), fetch is at 299 -- that's where we get requests cancelled depending on the timers. The function that toggles stand by is at 148.
 
Quote:
What I think would be ideal is if the kibitz chat stayed with a game permanently and replaced the current game comment system.

Sounds like a good idea. In the dev version I am encapsulating the chat code for it to allow several instances so we can have several chat elements in the DOM associated with different server handlers.
 
Quote:
Given that the chat options shouldn't be that terrible for the user to reproduce I wouldn't worry too much about their permanency. Also having different settings on different devices may very well be a desired thing fairly frequently.

I am currently feature creeping, adding options to customize the interface, display, command interpretation... Maybe having the locally saved options override the account saved options would make it perfect.
 
I would do server stored options only on a database though, and am considering converting the chat log to a database as well, to improve speed - especially that of the archive viewer. Also, when testing a conversion of the current log I bumped into one corrupted line and it is worrying, a database would be cleaner.
« Last Edit: Jan 30th, 2015, 7:02pm by leo » IP Logged
harvestsnow
Forum Guru
*****





   


Gender: male
Posts: 88
Re: New website & new client
« Reply #23 on: Feb 2nd, 2015, 2:57pm »
Quote Quote Modify Modify

Quote:
The development version uses web storage instead of cookies, to save bandwidth (as cookies are sent along with all the polling requests).

 
I think the option cookies are only sent to the authentication page. But cutting all the HTTP overhead would be nice anyway. Have you looked into websockets?
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #24 on: Feb 2nd, 2015, 5:16pm »
Quote Quote Modify Modify

Hi Harvestsnow, I just checked that and you are correct, only the root arimaa.com cookies are sent along with the polling requests. I can't recall if the chat cookies were restricted to just chat.php since the beginning or if that was tweaked afterwards.
 
Yes, websockets were considered at different moments in the past and the time should be mature now to use them across browsers. I am unsure of how to make the system compatible with all the gameroom flavors existing and upcoming. Any ideas?
« Last Edit: Feb 2nd, 2015, 5:17pm by leo » IP Logged
harvestsnow
Forum Guru
*****





   


Gender: male
Posts: 88
Re: New website & new client
« Reply #25 on: Feb 2nd, 2015, 7:30pm »
Quote Quote Modify Modify

on Feb 2nd, 2015, 5:16pm, leo wrote:
I am unsure of how to make the system compatible with all the gameroom flavors existing and upcoming. Any ideas?

*scratches head*
Nope.
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #26 on: Feb 5th, 2015, 5:51am »
Quote Quote Modify Modify

*scratches head too* Tongue
 
I have back pedaled about the changes to the syntax of the commands and events, giving up adding a version number to the log lines and keeping the command word as a tab-separated token to make analysis and search easier if we ever need that. There are some changes though:
 
OLD EVENT: time<TAB>user<TAB>cmd[<TAB>color<TAB>data]<NL>
NEW EVENT: time<TAB>user<TAB>cmd[<TAB>data]<NL>
 
Here is the detail of the events:
 
OLD
 
in
out
timeout
msg<TAB><text color><TAB><message>
 
NEW
 
in
out[<TAB><goodbye message>]
tmo
md<TAB><message>
mc<TAB><text and background colors><SPC><message>
me<TAB><emote message>
sp<TAB><spoiler message>
pre<TAB><table or code with preserved format>
bp<TAB><board position>
kick<TAB><kickee>[<SPC><reason>]
 
There would be no format conversion of the existing chat log on the server, an archive viewer would have to process the old "msg" event differently, checking for emote messages with initial "/me" or ":" that is not part of a smiley.
 
The server commands now include a "version" command that a client should send prior to any processing in order to be able to notify the user if they are using an outdated client.
 
The current chatroom client has no mechanism to warn the user of an update, so I expect some problems with the users who keep their chat window open during the upcoming update.
IP Logged
Janzert
Forum Guru
*****



Arimaa player #247

   


Gender: male
Posts: 1014
Re: New website & new client
« Reply #27 on: Feb 5th, 2015, 11:38am »
Quote Quote Modify Modify

on Jan 28th, 2015, 7:04pm, leo wrote:
The message sending function sends it right away indeed, then turns off stand by if on (stand by is more or less independent from the progressive slowdown), then calls the polling function, but that latter function first checks the status of the polling activity and aborts if any request is scheduled, even in a long time. I would add a frequency reset in the message sending function but I am wary of touching the many variables that you used for the progressive polling, it would also require cancelling the timer for the next scheduled request I guess.

 
So I finally stopped being lazy and figured out that http://arimaa.com/arimaa/chat/chat.js was the url I needed to hit to check this.
 
So here's my reading of the code. Notice I say reading not actual testing. Wink
 
As you said, after sending a message the send function calls fetch to get the latest updates (including the message we just sent). The first thing fetch does is check if another update request is in progress and aborts if there is (lastrequest exists, is not complete and hasn't been going for > 30 seconds). It doesn't pay any attention to the update timer frequency before sending the update request. After sending the update request, it then immediately schedules the next one.
 
So there is a race condition (all network requests are asynchronous) but in most cases it will send an update request right away after sending a message and will get the new message. The problem arises that currently for any update received the current code is already waiting one pre-update interval to send the next request, i.e. it always waits one extra long interval after sending a request that contains an update before speeding back up.
 
The best way to fix this is probably to move the
Code:
if (lastupdatetime && currentupdateinterval < 10000)
 out into its own function, say 'schedulenextupdate()' . Then call that function from the fetch function where it currently runs and the gotupdate function, calling it right after lastupdatetime is changed.
 
To mostly fix the race problem between the message send and update from the server. The send functions should also set lastupdatetime just before calling fetch. But this will less often have an effect.
 
One side effect of rescheduling each time an update is received though is that update requests will slow down by the server round trip time when active chatting is in progress. The shortest interval could be decreased some to compensate but it's probably not necessary.
 
Janzert
IP Logged
leo
Forum Guru
*****





   


Gender: male
Posts: 277
Re: New website & new client
« Reply #28 on: Feb 8th, 2015, 8:36am »
Quote Quote Modify Modify

Thank you so much, Janzert! And sorry for misunderstanding your question about the location of the code as inquiring about the line numbers instead of the file url.
 
I still have some doubts about the current code that turns off the stand by mode (line 148 ) after sending a message. I wonder if it does the right thing in the middle of the polling system.
 
Brendan, I had a closer look at your cljs, it looks like a fantastic language. Unfortunately I have very little time these weeks to study yet another language, so instead I am turning the chatroom into a javascript object that supports several instances in one DOM. The user, authentication, server, and other parameters, can be set on the prototype or each instance depending on which are shared. Will this be ok?
 
As a replacement to the current chatroom, it will be a single instance in one wrapper window.
« Last Edit: Feb 8th, 2015, 8:37am by leo » IP Logged
Janzert
Forum Guru
*****



Arimaa player #247

   


Gender: male
Posts: 1014
Re: New website & new client
« Reply #29 on: Feb 8th, 2015, 4:15pm »
Quote Quote Modify Modify

on Feb 8th, 2015, 8:36am, leo wrote:
I still have some doubts about the current code that turns off the stand by mode (line 148 ) after sending a message. I wonder if it does the right thing in the middle of the polling system.

 
On a quick review I don't see any problems. Do you have something specific you think could go wrong?
 
Janzert
IP Logged
Pages: 1 2 3  Reply Reply Notify of replies Notify of replies Send Topic Send Topic Print Print

« Previous topic | Next topic »

Arimaa Forum » Powered by YaBB 1 Gold - SP 1.3.1!
YaBB 2000-2003. All Rights Reserved.