Ticket #224 (new story)

Opened 13 years ago

Last modified 13 years ago

User views a resource from a remote toolbox

Reported by: tarmo Owned by: anonymous
Priority: major Milestone:
Component: generic Version:
Keywords: Cc:
Time planned: Time remaining:
Time spent:

Description

Current situation: Search is performed and some stuff is found from another toolbox. User now clicks on a link to see an item found from remote toolbox. When viewing a remote resource, all functions work without difference to the user - the user can create new versions, translate, or use the resource as usual.

Change History

comment:1 Changed 13 years ago by tarmo

(comments copied from previous discussions)

We should keep track of where the user is going. At some point, user surely wants to return to his toolbox. Or he sees great content and wants to translate it but he is on another server.

Should we create some kind of proxy to show stuff from a distant location. Or use cookies?

how should we solve this problem?

We need some way of knowing where the "home toolbox" of the user is.

Cookies are a bit problematic, since they're sent on a domain name basis, so we can't really do that, since the toolboxes are in very different domains, and some users block cookies that are cross-domain (since they're usually related to ads).

So some kind of proxy solution would sound most promising. Possibly so that the URL of the resource is of the form "(content|activities|tools)/remote/TOOLBOX_ID/RESOURCE_ID" and our "remote" object fetches the information and shows it, possibly caching it into the local toolbox as well.

Or the object is at this point copied to the local toolbox, and future links are local (we'll also store some kind of "is_copy_of" attribute pointing to the original location). The latter option has the problem of generating a lot of copies of resources, which might get difficult to handle.

comment:2 Changed 13 years ago by vahur

I think proxy with a good caching is the best solution here. Now we need to think about these TOOLBOX_ID and RESOURCE_ID.

comment:3 Changed 13 years ago by tarmo

I suggest the TOOLBOX_ID be the full server name, port, and path of the toolbox instance, excluding the protocol. And the RESOURCE_ID could just be the ID of the object.

So if we have an object at our test server at http://goedel.uiah.fi:80/toolbox/activities/demo_activity, then we could refer to it like so: http://LOCALTOOLBOX/PATH/activities/remote/goedel.uiah.fi:80/toolbox/demo_activity (of course, port 80 is optional, but if the system is in a non-standard port, then it's good to have).

This will give us the correct section layouts (since we're inside /activities/) and the remote object can deduce from its own location the correct path to call the remote Toolbox for the resource.

Comments?

comment:4 Changed 13 years ago by tarmo

Now I'm thinking that if we continue with the proxy approach, the user should stay in his own toolbox all the time. This will make things easier - no need to track home instance. What this requires is the following:

  • All searches and queries to remote toolboxes are shown among local results
  • Links to remote objects will use the URL format specified above. The remote tool will fetch a copy of the target and store it in the local toolbox (adding a suitable attribute to tell that "this is a cached copy of X"), and then redirect the user to the locally copied object.

There's still two variations here: Either we just get the metadata (allowing us to display the *_view template), and point the *_play template (that shows the actual contents) to the original location, or copy the entire object.

Note: See TracTickets for help on using tickets.