On Thu, Dec 23, 2010 at 1:53 AM, rob levy <r.p.l...@gmail.com> wrote: > Hi Anders, thanks. If I understand what you are asking, in fact the server > in my case does not care if anyone is listening, however you can set how > long the messages live in the queue. The client holds the responsibility of > keeping track of what messages it has already seen based on the date in the > response header. If you want to make sure your client doesn't miss messages > you set a very long time to live and let the client catch up to what it > hasn't seen yet in the spew of messages when it signs back on. For my > application this was not necessary, as I treat push messages as ephemeral > short lived things. When the client comes back on the direct request to the > server to log in gives its next waiting event as a plain old response to the > request to the application maintaining this state. Does this answer your > question?
Yes it does thanks. Always interesting to hear about architectural aspects :-) I'm more and more thinking that for my application where clients listening is low and the cost of creating a message is high, that I would want something like websockets. Because it would easier allow me to know when a client has disconnected. > On Dec 21, 2010 5:50 PM, "Anders Rune Jensen" <anders.rune.jen...@gmail.com> > wrote: >> On Mon, Dec 20, 2010 at 6:06 PM, rob levy <r.p.l...@gmail.com> wrote: >>> I have posted a repository containing the code for a web application I >>> made >>> using a server push (AKA Comet, long polling) architecture. The front >>> end >>> is in Javascript, and the back end is in Clojure. The clojure code is >>> able >>> to send notifications to clients' browsers effectively through use of >>> nginx's push module, which the clients subscribe to. With websockets >>> presently out of reach this can be a good way of doing this sort of >>> thing, >>> and at least on my small-scale testing it is a super responsive way of >>> simulating a socket. >> >> Hi Rob >> >> Interesting project. I havn't looked at the machine learning part of >> it, although that also sounds interesting, but at first I was more >> interested in the long polling aspect of your application. I was >> looking at something similar but in the end I decided that given my >> use case (mostly a single client polling) it didn't make much sense to >> use nginx. I'm guessing that in your architecture, nginx makes more >> sense because you have a lot of clients polling the same interface? >> That way you know that it is much more likely that there will be at >> least one subscriber left for a message when the server actually has >> something to send. And I guess the way the back-end knows that there >> is still someone that wants to know about a message is that nginx says >> that there is still clients waiting when it delivers the message. >> Could you maybe elaborate a bit more on this? >> >>> https://github.com/rplevy/sayoperation >>> >>> The application itself is online (for now) at: >>> >>> http://www.robertplevy.net/sayoperation/ >>> >>> A little bit of context is necessary here. This is a game I made as part >>> of >>> my final project for a course I am in (I am taking courses part time as >>> part >>> of an MA program I will eventually complete) on the topic of Machine >>> Learning and Natural Language Processing. The purpose of the game is to >>> collect game move data. I'm in the process of figuring out how to train >>> a >>> classifier to learn to make the same sorts of game moves (though the text >>> generation piece is out of scope), to have 1/2 of an AI game player. >>> >>> If you want to play the game and help me collect training data, here are >>> some things to know: >>> >>> 1. You will be asked to give an instruction to your team mate, given >>> the >>> information on the screen. The red is the target, and the green is what >>> your teammate will move to the target. Notice that the target is always >>> an >>> empty space. For example "put the crab above the butterfly" would make >>> sense if the crab had a green border, and there were a red bordered >>> target >>> above the butterfly. >>> >>> 2. Use clear and natural language when entering data., try to explain >>> in >>> the way you would explain to a person. Punctuation and capitalization is >>> stripped out/lowercased. >>> >>> 3. The rounds work like this. Player 1 instruct -> Player 2 move --> >>> Player 2 instruct --> Player 1 move. The game automatically presents >>> your >>> next available move just like in RIAs such as gchat or facebook (no need >>> to >>> refresh). >>> >>> 4. Multiple concurrent games are encouraged. The game should be >>> responsive and will immediately tell you if you have a move to play in >>> any >>> of your games. >>> >>> 5. Caveat: The application has been tested thoroughly in Firefox and >>> Chrome. While there is no inherent reason why it shouldn't be possible >>> to >>> make it work in Opera or Internet Explorer, I have not tested it in IE >>> (so >>> it probably doesn't work in that browser), and I am aware that it doesn't >>> work in Opera. This is just a matter of time and effort, that I need to >>> spend on the NLP side of this project at the moment. >>> >>> 6. The high scoring team as of 2am tonight will win something (I >>> haven't >>> decide what, give me ideas please). >>> >>> Thanks, >>> Rob >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your >>> first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> >> >> -- >> Anders Rune Jensen >> >> http://www.iola.dk >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Anders Rune Jensen http://www.iola.dk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
