Forum OpenACS Development: stable urls for all objects

In the categorization package I solved that problem the following way: I added an index.vuh file in /www/o that accepts an object_id, queries the acs_objects and acs_named_objects (see my other posting) tables to figure out the object_type and package_id. It will then get the package-instance url to the package_id from the cache and invoke a service-contract to figure out the local url to display that object.

What is this service-contract about? I called it AcsObject.PageUrl and there should be an implementation for every displayable object type called $object_type _idhandler so that the appropriate implementation responsible for an object of a particular object type can be found easily. The implementations should accept an object_id and return a string directing to the page that can show that object i.e. "view?posting_id=$object_id".

The result of using this index.vuh page and the service contract is that we don't need to resolve the urls to some objects when displaying them, but do that work when the user actually clicks on an object to see it. This actually provides a stable url for every object in the system since (as i assume) object_ids will never change, the name of an object and the package-url certainly can.

Are there any thoughts about this? Can we go with my proposal?

The legal mappings are all nsv-cached at start-up and kept consistent by the admin UI that manages the mappings, so there's no database hit.  We also use cookies to remember preferences for the user between sessions, if they have cookies enabled in their browser.

If you guys want to look at the code you're more than welcome to, of course, the GP code is GPL'd.

Since no real objection has been voiced, I consider my proposal of having stable urls for all objects as accepted...

Maybe implement it as an optional package, for those who might not want to use it? I don't think anyone can object until more is known.

It really makes sense for packages to have a tcl proc that generates a URL for user-visible objects. We already have a URL service contract for search, and for notifications. Do we need another for categorization, or should be choose a standard service contract that can return the URL of an object?

I have another idea for the index.vuh. It should live at the root of the site, and accept just an interger as the last part of the URL http://example.com/foo/12345.

This would allow creating a URL that contrains an object_id as the last part with an arbitrary path before it. This would allow pretty URLs for packages with less work. Just implement the URL service contract.

Display of objects is application specific. Permission procedures need to run for every object, which includes permissions on a specific subsite. This means that the url must point into the package itself, or it will require someone to design new pages for display of individual objects. For a lot of objects it doesn't make sense to display them out of context.

In some cases, I would even venture to say that the existance of an object_id should not be visable, the returned url could give away information all by itself.

Maybe if this functionality was only mounted in an admin area would I consider this a good feature.

In short this sounds like a new requirement without a purpose. If it is optional, I don't care. Otherwise I care: I don't want my package's objects to be displayed out of context, or at least I want the choice to not display them.

If there is a function that returns the url, the function must do the same security checks as required by the package to see a link to the object. This means the function may actually need to check permissions on a parent object.

I don't think adding these new requirements to packages is useful. Why can't you create an add-on package, not in the core, which packages can use if the developer wishes?

One nice feature of using acs_objects is that the developer gets a lot out of that: permissions, global object_id. This 'feature' isn't for the developer: s/he has already decided on the interface best suited to display. This sounds very much like another feature which will just slow down a server from performing meaningful work.

I would venture to guess that the vast majority of acs_object types were never intended to be displayed on a page by themselves, out of context. Why should developers be forced to do this? The one instance I know of where an object is displayed by itself is the forums package. The message content can be displayed by itself. I can't express how useless this page is. Why is it even there?

If this is mainly an idea that will be used with the content repository, then make it a part of that package. Make the service contract requirement, if any, apply to packages that use the content repository.

This functionality is not about showing random objects, but it'll provide for *extremely cheap* creation of links to OpenACS-internal objects. The current approach is *very expensive*.

About your security concerns: the permissioning will still be done by the target page, nothing is shown out of context. The *tricky* thing is that the redirect must not take place if the user doesn't have appropriate permissions on the target page, because the URL may already contain sensitive information. So the redirecting page should contain the same permissioning code like the "view" page.

Tom, the /o/$object_id is merely a replacement for the site_node.get_url function if you want to create lists of links. It defers the expensive process of calculating the URL. The assumption here is that there fairly many pages in a web system that show fairly many links. Take portal: a regular portal page may show 5 portlets with 10 links each. Your site calculates 50 URLs although the user can click at most only one at a time.

On an Oracle-backed OpenACS system with 329 site nodes this is the price:

SQL> -- gee, no bind vars
select site_node.url(node_id)
          from site_nodes where object_id= 93013;

Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
         12  consistent gets

site_node.url is a recursive function that gets more expensive the more nodes you add.

In short /o (or LC_$ISOCODE/o) would supersede most calls of site_node.url thus saving overall load on the system and will not compromise security.

I thought one of the principals of a dynamic website was to never display links that a user cannot follow. Another related principal would be to give a little more information on what the link might show, like the number of new posts in a link to a forum.

For a portlet, only links the user has privileges to view should be displayed, otherwise the user presented with 50 links, with a number of bad ones, might hesitate to click, fearing rejection. In other words, the links are pre-qualified.

The service contract idea for providing a url to linkable objects sounds great. I really do like it. Besides a tcl function, a wrapper in the form of a url is very handy.

My concern is with displaying information about an object in an unqualified way: just digging through the database, going around an application and showing information before security checks can be performed. This gets back to your main point: it is expensive to do security checks on a huge list of objects, and calculating the url is maybe worse or of the same magnitude. This is where application logic is important: providing a useful, secure and cheap navigation scheme for displaying objects. A portlet would presumably do the same thing, taking a user_id and providing qualified links, or object_ids and an object name or summary.

In the case of a forum portlet, probably only one permission check would be performed on the forum, and not on every thread or message.

I'm just wondering out loud here: what if the package developer could provide views? Instead of individual objects, for which a permission is checked, any whole chunk of useable data which could be tied to an object_id and permission checked with a user_id could be queried. For instance, in a forum package, besides the links to new messages or threads, you could provide a list of who posted the last few messages, kind of a whose on line. In this case the forum_id and the view name would be provide. Maybe that is what a portlet does, but my point here is that a single link to an object may end up being a little limiting. If you could specify a view, a series of urls that contain the object could be used. None of the urls would need to be specified ahead of time, just a link to the redirection url including the object_id and view. So the forum portlet, view as a whose on line, would return a series of user names and user_ids, and the view you should use to look a the user object. Maybe in this case the view would be of the number or list of posts to this forum_id by the user.

Now would a view need to be provided by the developer? Would a view need to be a part of the package that created the data? Not necessarily, maybe it would be better if views were separate packages: unmounted services. So anyone could create a view and distribute it. When you mount a package instance, you could establish which views you want to apply to that instance.

Tom - *nothing* in the user interface but the links target text will change. I repeat: *nothing* but the links target text.

The fact that you can follow only one link per click is a constraint by a web browser - how would you follow three links with one click?

The fundamental assumption is: If url creation is expensive - which it is a fair bit in OpenACS - then defer it till you actually really need it.

How do you come to think that a /o/ link would be be shown without description?

/o/ will supersede the PL/SQL function site_node.url(node_id). Your new query will look like this: select '/o/' || object, ... from ... where...;

instead of select site_node.url(node_id) || '/view-object?object_id=' || object_id from ... where...;

It's a light-weight change. Nothing fancy and straight-forward!

We could abstract the folders further to allow them to contain any object.

By assigning one folder to each site_node and naming objects that should have URLs (and falling back to object_id as the name if its not named) any URL can be calculated efficiently on a display page.

The URL of each site_node is cached in an NSV array, so appending the name or object_id to the site_node would be efficient.

I think this is a good area to explore for future versions of OpenACS (post 5.0).