Can my map talk to my other map?
April 14, 2006 7:20 PM Subscribe
I need help on learning fancy new web coding techniques
I know what I want to do, and I think its possible, but I'm not sure. I want to know if its possible to have two web browsers look at a map (ala Google Maps) and have one person control the map in real time and have the other person see those updates in real time. Difficulty: The users are not accessing the same web page/application. So Browser A accesses Mapping App A, and Browser B accesses Mapping App B, but both browsers have the same (or very similar) map view. App A and App B can (have to) share information, and that's where I'm getting stuck. I'm pretty sure I can do this with client side refreshes, but I really don't want to do it that way. I am stuck on figuring out how to get the Apps to share information (ideally using XML as the formatting, but not critical). I do have both mapping apps up and running. I would like to this to run on my hosted webserver (php, mysql, probably some other stuff that I'm even less familiar with). The mapping app is basically just the Google Mapping API. So, how about it? Is there a straightforward way to pass the Lat, Long from App A to App B in real time?
Pointers to tutorials on passing data between Webserver Apps would be fine as well. Also, is there a name I can use to improve future googling on the concept?
Thanks for any help.
PS - Please note, the problem is not how to get users to share a map view. I don't care about that. What I care about is App A updating App B and vice versa and passing those updates on to users using those apps. And one last request ... please be nice to the Web2.0 newbie
I know what I want to do, and I think its possible, but I'm not sure. I want to know if its possible to have two web browsers look at a map (ala Google Maps) and have one person control the map in real time and have the other person see those updates in real time. Difficulty: The users are not accessing the same web page/application. So Browser A accesses Mapping App A, and Browser B accesses Mapping App B, but both browsers have the same (or very similar) map view. App A and App B can (have to) share information, and that's where I'm getting stuck. I'm pretty sure I can do this with client side refreshes, but I really don't want to do it that way. I am stuck on figuring out how to get the Apps to share information (ideally using XML as the formatting, but not critical). I do have both mapping apps up and running. I would like to this to run on my hosted webserver (php, mysql, probably some other stuff that I'm even less familiar with). The mapping app is basically just the Google Mapping API. So, how about it? Is there a straightforward way to pass the Lat, Long from App A to App B in real time?
Pointers to tutorials on passing data between Webserver Apps would be fine as well. Also, is there a name I can use to improve future googling on the concept?
Thanks for any help.
PS - Please note, the problem is not how to get users to share a map view. I don't care about that. What I care about is App A updating App B and vice versa and passing those updates on to users using those apps. And one last request ... please be nice to the Web2.0 newbie
Response by poster: That does seem to simplify some of the XMLHttpRequest stuff i was trying to decipher, but I've got the part that delivers data to the client Asynchronously. What I don't understand is how to do this server to server. In other words, I see how to do something on the client that generates a request to the server, and then that server can respond back to the server asynchronously. But how do I do something at the client that causes the server to send data to another server (which then updates an entirely different client)? Can I still use XMLHttpRequest for that? If so, how? I can't run Javascript at the server can I? There seems like there should be an easy way to do this, but I'm not experienced enough to see it.
Thanks for the link though, more stuff to explore.
posted by forforf at 8:56 PM on April 14, 2006
Thanks for the link though, more stuff to explore.
posted by forforf at 8:56 PM on April 14, 2006
Response by poster: Maybe I need to have some type of proxy at the server?
posted by forforf at 8:59 PM on April 14, 2006
posted by forforf at 8:59 PM on April 14, 2006
Best answer: I see how to do something on the client that generates a request to the server, and then that server can respond back to the server asynchronously. But how do I do something at the client that causes the server to send data to another server (which then updates an entirely different client)?
You send something from the client that starts a script on the server. The script can do whatever you want it to. Sending data back to the client is just one possibility.
And making an http hit on another server is trivial.
Say your request looks like this:
http://yourserver.com/script.php?x=100&y=200
your script can just do something like (pseudocode):
posted by AmbroseChapel at 9:19 PM on April 14, 2006
You send something from the client that starts a script on the server. The script can do whatever you want it to. Sending data back to the client is just one possibility.
And making an http hit on another server is trivial.
Say your request looks like this:
http://yourserver.com/script.php?x=100&y=200
your script can just do something like (pseudocode):
get('http://otherserver.com/otherscript.php?x=100&y=200');
echo("coordinates received")
i.e. it can do whatever it likes with the coordinates received, either before or after sending back a response to the original script.posted by AmbroseChapel at 9:19 PM on April 14, 2006
Response by poster: thanks ... I suspected I was overcomplicating it.
posted by forforf at 9:38 PM on April 14, 2006
posted by forforf at 9:38 PM on April 14, 2006
Also... javascript has a setTimeout() function which lets you execute actions every so often... You can have your script execute every so often, looking for updates or whatever, then perform the appropriate actions.
posted by ph00dz at 9:53 PM on April 14, 2006
posted by ph00dz at 9:53 PM on April 14, 2006
You don't need 2 servers for this. What you need is some way to associate two clients together. You then just store the db coordinates in the db based on the key for that association. When each client looks up the coordinates using setTimeout + AJAX, they'll both read the same key.
posted by mkultra at 10:03 PM on April 14, 2006
posted by mkultra at 10:03 PM on April 14, 2006
I think mkultra is on the right track. The problem with AmbroseChapel's method is that it doesn't push anything from one client to another, it merely pulls from one client to two servers. You still need a way for client B to actually get that data.
Look at it from the client side: you open up a browser. You navigate to a website over port 80. You change select a longitude/latitude, which sends a request (let's say XMLHTTP for kicks) to the server for SCRIPT.PHP? + PARAMETERS. The server takes those parameters, runs the script, and returns data (or not). Meanwhile somewhere else, someone is waiting to have their instance of the webpage "updated" magically.
See, unless there's some common source pool for BOTH clients to "dip their feet into", your clients will not be able to share information. You either need to save these requests into a database object (easiest method, but most taxing on the server), or if you were more sophisticated, a shared session object (and you would share the same server session with two clients is an exercise I leave up to the reader, but I can tell you right now you won't be able to do it with generic "19.95/mo." webhosts). The third method would be to simply open up a direct connection between the two systems. Really, this is the best method, but then, you're not going to do this over HTTP, that's for darned sure.
posted by Civil_Disobedient at 7:01 AM on April 15, 2006
Look at it from the client side: you open up a browser. You navigate to a website over port 80. You change select a longitude/latitude, which sends a request (let's say XMLHTTP for kicks) to the server for SCRIPT.PHP? + PARAMETERS. The server takes those parameters, runs the script, and returns data (or not). Meanwhile somewhere else, someone is waiting to have their instance of the webpage "updated" magically.
See, unless there's some common source pool for BOTH clients to "dip their feet into", your clients will not be able to share information. You either need to save these requests into a database object (easiest method, but most taxing on the server), or if you were more sophisticated, a shared session object (and you would share the same server session with two clients is an exercise I leave up to the reader, but I can tell you right now you won't be able to do it with generic "19.95/mo." webhosts). The third method would be to simply open up a direct connection between the two systems. Really, this is the best method, but then, you're not going to do this over HTTP, that's for darned sure.
posted by Civil_Disobedient at 7:01 AM on April 15, 2006
I quite agree that my solution doesn't solve the whole problem. You definitely need some auto-refresh solution with browser B.
But I did resolve the particular mental block he was having in the quoted section -- "client hits on server, server replies, I know how do that part, but I want to do that and hit on another server as well".
posted by AmbroseChapel at 5:13 PM on April 15, 2006
But I did resolve the particular mental block he was having in the quoted section -- "client hits on server, server replies, I know how do that part, but I want to do that and hit on another server as well".
posted by AmbroseChapel at 5:13 PM on April 15, 2006
Best answer: You definitely need some auto-refresh solution with browser B.
That's not the problem, Ambrose. You can set up a page to refresh every couple of seconds. The problem is that two separate clients need to be tied together somehow. Two clients both calling the same script, even if it's on the same server, even if they're both being constantly refreshed, does not address this issue. They need a pooled resource. Either a database, a textfile, a shared session, a direct link over a specific port... something.
posted by Civil_Disobedient at 3:24 AM on April 16, 2006
That's not the problem, Ambrose. You can set up a page to refresh every couple of seconds. The problem is that two separate clients need to be tied together somehow. Two clients both calling the same script, even if it's on the same server, even if they're both being constantly refreshed, does not address this issue. They need a pooled resource. Either a database, a textfile, a shared session, a direct link over a specific port... something.
posted by Civil_Disobedient at 3:24 AM on April 16, 2006
Response by poster: My problem was two-fold.
First, as you rightly point out CD, I needed a place to pool information. I struggled with this for a while (and still am a bit). What complicates it a bit is that I don't want client B accessing the same resource as Client A, I want a layer of abstraction. I want to simulate a situation where Client A and Client B are incompatible. I want a situation where the shared resource can be altered completely independent of Client A and Client B. So accessing the shared access directly by both Clients is out of the question.
Second, I needed a mechanism to keep the clients synchronized in real-time (or pretty close). Ambrose gave me some ideas on that. So assuming a static shared resource (file, db, etc), Client A could tell Server A to update the resource, Server A would then update the resource and notify Server B that the information was up to date. Client B on the next refresh would then gather the up to date information.
I wanted to do it this way because now I can change the resource without having to notify any clients. The servers would point to the new shared resource.
Issues I still don't like about the design: I would prefer the shared resource to "push" updated data to the clients, rather than relying on a polling refresh mechanism. Also, for simplicity I put the shared information in a static file, however I'd rather have used a shared object, but that level of coding is a bit beyond me at the moment.
Thank for the help all, CD, I'm marking you best answer as well for helping me to sort out ideas on ways to share data.
posted by forforf at 10:17 AM on April 16, 2006
First, as you rightly point out CD, I needed a place to pool information. I struggled with this for a while (and still am a bit). What complicates it a bit is that I don't want client B accessing the same resource as Client A, I want a layer of abstraction. I want to simulate a situation where Client A and Client B are incompatible. I want a situation where the shared resource can be altered completely independent of Client A and Client B. So accessing the shared access directly by both Clients is out of the question.
Second, I needed a mechanism to keep the clients synchronized in real-time (or pretty close). Ambrose gave me some ideas on that. So assuming a static shared resource (file, db, etc), Client A could tell Server A to update the resource, Server A would then update the resource and notify Server B that the information was up to date. Client B on the next refresh would then gather the up to date information.
I wanted to do it this way because now I can change the resource without having to notify any clients. The servers would point to the new shared resource.
Issues I still don't like about the design: I would prefer the shared resource to "push" updated data to the clients, rather than relying on a polling refresh mechanism. Also, for simplicity I put the shared information in a static file, however I'd rather have used a shared object, but that level of coding is a bit beyond me at the moment.
Thank for the help all, CD, I'm marking you best answer as well for helping me to sort out ideas on ways to share data.
posted by forforf at 10:17 AM on April 16, 2006
Glad to help. Hope this helps more:
Probably the best way to do this (if you want to do this through a web browser) is to use Java and a Java web app server like Tomcat in conjunction with EJB's (Enterprise Java Beans). The reason is that session management in traditional web servers is very restrictive: you wouldn't want someone to hijack your Amazon shopping cart, for example, so the general rule is: one client, one session.
With EJB's, you can save the session information in a pooled resource like a static hashtable.
It would go something like this:
1. Web app server starts up. App server creates an object in memory to hold data.
2. User A logs in. Web server creates a unique session for User A. Later, User B logs in. Web server creates a unique session for User B.
3. User A and User B click on a link that takes them to a map page. When they click on the link, a request is sent to the server that says, "associate this user with this shared resource".
4. User A clicks on a map (or whatever) which sends a request to the server. The variables are saved into the pooled resource.
5. User B's webpage is set up to auto-refresh every 2 seconds. On each refresh, the page requests whatever data is in the pool.
Finis.
There's an excellent description of this process here. Mind you, this requires running your own appserver, but on the bright side, Tomcat and Java are free! :)
posted by Civil_Disobedient at 5:32 PM on April 16, 2006
Probably the best way to do this (if you want to do this through a web browser) is to use Java and a Java web app server like Tomcat in conjunction with EJB's (Enterprise Java Beans). The reason is that session management in traditional web servers is very restrictive: you wouldn't want someone to hijack your Amazon shopping cart, for example, so the general rule is: one client, one session.
With EJB's, you can save the session information in a pooled resource like a static hashtable.
It would go something like this:
1. Web app server starts up. App server creates an object in memory to hold data.
POOLED RESOURCE
---------------
| id = 123 |
---------------
2. User A logs in. Web server creates a unique session for User A. Later, User B logs in. Web server creates a unique session for User B.
USER A USER B
-------------- --------------
| session id | | session id |
| = 12345 | | = 98765 |
-------------- --------------
3. User A and User B click on a link that takes them to a map page. When they click on the link, a request is sent to the server that says, "associate this user with this shared resource".
USER A USER B
-------------- --------------
| session id | | session id |
| = 12345 | | = 98765 |
| resourceId | | resourceId |
| = 123 | | = 123 |
-------------- --------------
4. User A clicks on a map (or whatever) which sends a request to the server. The variables are saved into the pooled resource.
5. User B's webpage is set up to auto-refresh every 2 seconds. On each refresh, the page requests whatever data is in the pool.
Finis.
There's an excellent description of this process here. Mind you, this requires running your own appserver, but on the bright side, Tomcat and Java are free! :)
posted by Civil_Disobedient at 5:32 PM on April 16, 2006
For clarification, the pooled resource in this case is a variable held in the server's memory. So data access is very fast! I can't even imagine how ludicrously slow this process would be if you were using a database to act as the middle layer.
posted by Civil_Disobedient at 5:35 PM on April 16, 2006
posted by Civil_Disobedient at 5:35 PM on April 16, 2006
This thread is closed to new comments.
I am not a web developer, I am not your web developer, your in-page http requests may vary.
posted by onalark at 8:24 PM on April 14, 2006