> [Excerpts from original message] >>>> I wanted to suggest an approach to implement a similar API like >>>> "Twitter's streaming API": >>>> One could utilize SQLSpaces (available under >>>> http://sqlspaces.collide.info/) as a base and mediator for message >>>> based communication.. > > [Excerpts from ~Craig's message] >> PubSubHubBub requires that the server and client each be able to connect >> to each other. It's obvious that the client (browser) can connect to the >> server (StatusNet), but in many (if not most) cases, the server cannot >> connect to the client because the client is behind NAT, a firewall, or >> something else. In an all IPv6 world (or the Internet of 15 years ago) >> this would be a good idea, but I don't know how to get around this >> problem >> with the current Internet. Do you have any thoughts? >> >> Good luck, >> ~Craig >> > > I have indeed! I considered following solutions: > > i) A streaming UDP connection which is open as long as the client > demands. This is of course not a good idea, since you have get into > deeper network layer and that means "complication" > ii) you could use long-pollin (as mentioned earlier) in which the user > sends a request and waits as long as the server finally replies and > afterwards sends another one. This also has the disadvantage that you > keep the socket open for a long time but on the other hand it is a > good replacement for simple polling
Web browsers don't let you use UDP, only HTTP (not even raw TCP). Some support web sockets now, which may be a good approach, in which case you could create some kind of PuSH over websockets or PuSH over long poll (aka comet) implementation. > > In either of cases, one should develop a client-side framework which > takes care of communication and message transmission. Indeed - just make sure browsers can do what you're thinking of :-) > > Regards > Pouyan > _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
