Home
The Toolkit for Online Communities
17481 Community Members, 0 members online, 2035 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Sub-package site nodes API thought

Forum OpenACS Development: Sub-package site nodes API thought

Icon of envelope Request notifications

Collapse
Posted by Lars Pind on
After doing the permissions UI fix, I gave a little thought to
generalizing this. And I came up with a few ideas.

How about if a package could define the nodes that exist within that
package, called the intra-package nodes. For example, the bug tracker
would have the index page named "List"; the "One bug" node
corresponding to bug.tcl; the "New bug" node; the "Admin" node; the
"Admin : Versions" node; etc.

This sub-package site map would be specified somewhere in a .tcl file
that gets loaded at startup. Then instead of manually building the
context bar, the way pages do today, this could happen automatically
based on the site node (as ad_context_bar does today) and the
intra-package-node. Sometimes which intra-package node you're in
could
be inferred from the URL, sometimes you'd have to specify it manually
(say if the same page represents different intra-package nodes).

The advantage, of course, is that when you want to redirect to
permissions, and want to let permissions know where you came from,
you
just have to pass it the site_node and the ID of the intra-package
node where you came from, and the context bar will happen
automatically.

The even cooler benefit is that this would allow you to build
navigation bars, whether your global one (Company, Products,
Solutions, Training, Support, yadda, yadda, yadda), your out-of-band
one (How to Buy, Download, Search), and your local one (your list of
products in the product section). Each entry points to a site_node
and
an intra-package node, possibly with some parameter values. It can
automatically do the "show which section you're in" thing, based on
the values that the current site node page sets.

There are a few complications:

First, each node can take parameters (query args), which you want to
preserve in your context bar. For exmample, the bug-tracker index
page
takes parameters such as the status, component_id, assignee_id, etc.,
from the filter. The site map page takes parameters saying which is
the root node, and which nodes are expanded. Other parameters to the
site map page are irrelevant to keep in the context bar, such as if
you have an edit form active somewhere ... you don't want to keep
that
if you navigate away from the page.

Second, the (pretty) name of a site node sometimes need to be
parameterized, too. What if you want the name of your bug to appear
in
the context bar, instead of "One Bug". This could certainly be
achieve
by providing some code to set it from the parameters taken by the
site
node, and caching the result.

Third, some pages, such as the permissions UI stuff, wants to
make-believe that you're really inside, say, inside the bug-tracker
or
the bboard package, even though in the file system, you're in the
acs-subsite package. Perhaps we need some "symlink" nodes, and what
you do is you tell the permissions page "look, you're really at this
node now, regardless of what you think." Or perhaps
there are better ways of doing this, dunno.

Fourth, we get long and nasty URLs. I don't see any way around this,
since we can't use any other known means of doing this. We can't use
cookies, because we want you to be able to have two windows surfing
the same site. We can't use a URL-based session_id, because we want
you to be able to clone a window and surf different paths from there.
The only thing I can think of to shorten the URLs somewhat is to
encode the site_node/intra-package-node info into one short
(integer?)
ID, and to encode the names of the parameters being passed in some
similar way. We definitely need some kind of encoding here, since
many pages can use the same parameter names.

Finally: What if the sub-package site map itself, i.e., the number
and
location of nodes, is dynamic? Don't know, but I'm sure we'll run
into
this at some point, say, in a knowledge library, so we need to think
about this in advance.

Anyway, this was a rather long rant. The bottom line is that I have a
feeling that something like this is in order, but we need to build it
out slowly, and make sure it's flexible/hookable enough that we can
circumvent it when we need to. And we need to come up with something
simple.

Any thoughts? Don, I'd love to hear more about what you did for
birdnotes.

Collapse
Posted by Peter Marklund on
I think it is excellent that you are attacking the context bar problem Lars! I have been frustrated myself that the ACS doesn't provide an elegant solution to the problem, but as your post indicates, the problem is much harder than it may seem at first. When I wrote the categorization service in Munich I implemented a little navigation package that used a URL-based session id to keep track of the urls and context bar names of the pages the user had visited. That way the user could click on the "Administer Categories" link in a Bboard forum and be taken to the categories package without the bboard pages disappearing from the context bar. I guess being able to clone the browser window and browse in different directions is useful sometimes. I am not convinced a lot of users take advantage of this feature though.
Collapse
Posted by Andrew Piskorski on
Whatever you do, please don't break the ability to use multiple browser windows at once on the site! Sites that do that, like shutterfly.com, drive me nuts. Lars, I don't have any useful suggestions for you, but I say you're right to insist on not breaking the user's ability to use two browser windows at once.
Collapse
Posted by Peter Marklund on

To enable browser cloning we could follow Lars's suggestion and issue an id on every request. It was my understanding that this id would simply map to a list of url/context bar name pairs (this is the information needed to create the context bar). However, Lars writes:

"The only thing I can think of to shorten the URLs somewhat is to encode the site_node/intra-package-node info into one short (integer?) ID, and to encode the names of the parameters being passed in some similar way. We definitely need some kind of encoding here, since many pages can use the same parameter names."

What is meant by "encoding parameter names" here? I'm probably missing something, maybe Lars could elaborate a bit further on this...?

Collapse
Posted by Lars Pind on
Explanation of "encoding parameter names":

Say you have this partial set of nodes inside the acs-subsite package: (parentheses contain parameters)

* ss_ermissions (object_id, party_id)
And this is from bug-tracker:
* bt_index (status, priority, severity, party_id, component)
  * bt_admin ()
Say the path taken is: Go to bug-tracker index page, do some filtering, then go to the admin page and click on the permissions link.

Now, first, we need a unique ID for each of these nodes. We can use something like the path of the file in the file system serving this node, with the caveat, that there may not always be a one-to-one relationship between nodes and files.

(Not sure about this. There'll definitely be files that aren't nodes (such as pages that just do something and then redirect), but will there also be the case of two files serving the same node? Perhaps.)

In order to shorten that site node ID, we could make it an integer, assigned automatically by the system at server startup (with the caveat, that these should stay the same across server restarts, so we better store them in the DB, actually).

The next part is the parameters. In the example, both Site Map and Permissions share the parameter "expand", hence if we want to pass that info as a URL parameter, we'll need to change its name.

The information we need to pass for the path that we traversed to get here is:

  • node_id of the site_node on which the bug-tracker was mounted.
  • intra-package node ID of the bt_admin node.
  • parameters for bt_admin node and all parent nodes.
  • For example:
    path_0_node_id=node-id-of-bug-tracker
    path_0_intra_node_id=bt_admin
    path_0_param_bt_index.status=open
    path_0_param_bt_index.party_id=3
    
    If your path has more entries (I'm thinking one entry per "jump" you make outside the hierarchy defined by the site map and the intra-package site nodes), we'd have path_0_... path_1_..., etc.

    So, specifically, the encoding of parameter names I'm talking about is the encoding of "status" as "path_0_param_bt_index.status", in order to avoid name clashes with the "status" parameter of hte bt_index page, and any other status parameters that any other page, including the current one, may take.

    Another thing I just thought of is that if all page have some sort of ID, and you use those instead of a full url in the cases where we use return_url today, you also avoid the problem that Branimir mentioned in his post about cross-site-scripting, that you can redirect to http://youserver.com/bboard/delete-all?return_url=http://mysite.com/, thus disguising your action.

    As far as issuing a new ID on every single request goes, how would you do that? You'd have to issue a redirect on each request, in order to get the browser to use a new ID, if it's in the URL. If it's in the cookie, you're defeating the purpose of letting people browse using two windows. I'm afraid that only viable option is to have long nasty URLs.

    This thought, while it seemed simple when I first cooked it up, is looking like it's growing in complexity. Whatever we do, we should try to find some minimal useful subset and implement that and avoid the temptation of going for the cure-all from the start.

Collapse
Posted by Stephen . on
There is already a scheme used for encoding parameters that does not require a unique integer id into a lookup table.  return_url works like this, urlencoding the host/path etc. PLUS any query params.  A page which is passed a return_url can itself urlencode that and any other params as the new return_url and pass it on.  The stack unwinds as the pages return.

The need for any of this depends on what you think the context bar is.  Does it show Where You Are, or does it show Where You've Been?

Where You've Been is a dynamic property and has little to do with the structure of the site.  The back button shows where you've been and how to get back there.

Where You Are is why we're confused as we try to re-use chunks of code by bouncing people through pages using redirects.  Setting Permissions is a general concept that we have, it's re-used a number of places in the toolkit; why can't it stand alone as a concept in the navigation?

Perhaps more functionality should be available as includes, to be wrapped up within minimal pages as packages require.  This would at least give us more templating flexibility.  But the proposal above sounds like waay too much work.

Collapse
Posted by Lars Pind on
Stephen, I'm well aware of return_url, and I'm aware of the difference between where you are and where you've been.

What I'm doing here is merely thinking out loud. I too am aware that this is way too much work, as I mentioned above.

Think of the problem I'm trying to solve as the subroutine problem for web navigation. You're calling the permissions interface as a subroutine, and you want to maintain the call stack, i.e., you want to show the user how they got there (which implies, among other things, what they're setting permissions for), and how to get back. Permissions is not the only instance of this problem, I recall having the same thing in workflow, where I wanted to provide multiple interfaces for modifying the workflow net, but they'd all share the same "edit this transition", "edit this place" pages.

And while I was at it, I figured it'd be nice if the current context bar could be augmented with some state, so that when you navigate to a certain node in the site map, and then to a node below site map, when you click back to site map through the context bar, it'd remember where you'd surfed to.

So that's how it came about, and I'm merely trying to see if some simple, clean, easily implementable design idea comes out of it. None has so far.

/Lars

Collapse
Posted by Dave Bauer on
I have an idea that seems like it would work, but I am sure requires more thought.

How aobut encoding the where you have been information directly in the URL. I have to look at the request processor again to see if this could actually work.

The steps of the path you had taken would be listed in the URL as directories. The page you are on and package it is in would be the last entries in that list, and some "magic" would have to  decode the rest of the URL.

This still might get too long. You could possibly also encode parameters in this way. It would at least produce less ugly URLs and I think it would work in the 2 browser window situation.

Collapse
Posted by Don Baccus on
<blockquote><i>
There is already a scheme used for encoding parameters that does not require a unique integer id into a lookup table. return_url works like this, urlencoding the host/path etc. PLUS any query params. A page which is passed a return_url can itself urlencode that and any other params as the new return_url and pass it on. The stack unwinds as the pages return.</i></blockquote>
This is in essence what I've done at birdnotes.net.  I treat the context bar information as a stack, pushing down when I enter a new page and popping off the correct number of elements when I go up.  This is computed whenever links are computed and put on the page, and the information is passed as part of the query string.  This is overly simplistic because navigation isn't always quite this clean but for the sake of discussion we can pretend this works, keeping in mind the fact that there will be exceptions to the nice clean picture in real systems.

<p>The problem is that the URLs get huge and very ugly very fast.  None of my users have complained and they like the navigation, but it's not a clean solution.
<p>Lars is trying to come up with a solution that holds the necessary information but without doing something as obvious or ugly as encoding the information in the query string.
<p>At least I think that's what he's trying to do, I've been too busy to read this thread closely :)
<blockquote><i> How aobut encoding the where you have been information directly in the URL. I have to look at the request processor again to see if this could actually work</i></blockquote>
It could be done but would suffer from the same problem as when passing it in the query string.

Collapse
Posted by Stephen . on
I know you are thinking out loud, and thank you for it!  It's an interesting read.  I also know you're aware of the return_url mechanism, which is why I was confused when you ignored it, the same as site nodes.  As the other posts were all pretty possitive I thought I should mention this seems to be going in the wrong direction.

Anyway, implementation issues asside, I'm wondering whether the problem you're trying to solve is actually a problem at all.  Is it such an easy mapping between program subroutines and navigation subroutines?

A user who navigates to permissions from bboard looks at the context bar and sees a logical heirarchy of pages.  What do we want them to get from this?

Is it just "here's a convenient thing to click on to go back to where you were."?  I can think of two reasons they might go back: they complete the interaction, in which case they'll be redirected automatically; they decide to bail out without completing the interaction, in which case they can press any 'cancel' button or hit the back button.  I suggest hitting the back button is pretty logical and equates to 'bailing out' to web users.

If on the other hand the context bar is to teach the user about the structure of our site then inserting Where You've Been information--which changes constantly--into that structure is very confusing.  Neilson does not say that Where You've Been information should be in the context bar, and it's not how Yahoo! works.

The Permissions UI does not only allow you to work with one object, it can present a list of objects to assign permissions to.  What happens when a user who's setting the permission for a bboard forum clicks on the 'Permissions' node of the context bar?  In the case where permissions appear as a logical entity of bboard we have an inconsistency, as the user may now set permissions for news postings in the context of the bboard.  In the case where permissions appears in a more logical heirarchy we've now illustrated a new section or concept of our site to the user.

I've enjoyed your articles at pinds.com, so one of the other things I also know is that you've spent much more time thinking about web UI issues than me!  Hopefully you can help me out here...

Collapse
Posted by Lars Pind on
Stephen,

I appreciate your challenge, that's what makes good ideas great (or kills bad ideas, whichever the current case represents ;-).

Re "The Permissions UI does not only allow you to work with one object, it can present a list of objects to assign permissions to": This isn't the way I implemented it with my site map/permissions UI fix, and it isn't the way I wanted to implement it. When you want to manage permissions for a site node, a bug-tracker, or a bboard, I want the permissions UI to appear as if it belonged to the site node, bug-tracker, or bboard instance. Not as part of a generic "permissoins" UI.

The latter is a verb-object type of thinking (I want to set permissions, now let me pick the object), whereas the Macintosh idea is object-verb (here's my bug-tracker, now I want to set permissions for it). I think object-verb is superior.

So, to be concrete, my context bar wouldn't include the "pick an object to set permissions for" page, it would go straight from bboard to the page setting permissions for bboard.

Why do I think this is important? Because the alternatives are even worse. You can either have the permissions page not have any context bar at all, which I think sucks, because you're leaving the user without his/her most familiar navigation tool (the context bar is still the only fixed piece of navigation in a default OpenACS installation). And having the context bar jump around in the case of permissions is confusing and doesn't portray any useful site map, especially given the totally useless nature of the permissions index page.

After having explored my initial design idea fully, I'm now convinced that it's an instance of overengineering. Let's put it to rest. But let's search for a decent alternative.

I like Dave's thought. How about the idea that, whenver you have such a "navigational subroutine", it must live in a subdirectory of its own. Then you can create the equivalent of a symlink from somewhere inside your own package to that directory. And then that, possibly along with some metadata, takes care of the navigation. (Forget about the paramters that go along with a node, they're not terribly important.)

Enough for now. Off to bed.

/Lars

Collapse
Posted by Don Baccus on
<blockquote><i>
Re "The Permissions UI does not only allow you to work with one object, it can present a list of objects to assign permissions to": This isn't the way I implemented it with my site map/permissions UI fix, and it isn't the way I wanted to implement it. When you want to manage permissions for a site node, a bug-tracker, or a bboard, I want the permissions UI to appear as if it belonged to the site node, bug-tracker, or bboard instance. Not as part of a generic "permissoins" UI.
<p>
The latter is a verb-object type of thinking (I want to set permissions, now let me pick the object), whereas the Macintosh idea is object-verb (here's my bug-tracker, now I want to set permissions for it). I think object-verb is superior.
<p>
So, to be concrete, my context bar wouldn't include the "pick an object to set permissions for" page, it would go straight from bboard to the page setting permissions for bboard.
</i></blockquote>
Exactly. Lars.  This was exactly the thinking hat led me to implement my ugly-but-smart context bars at birdnotes.net.  What the hell use is a context bar without context???
<p>If a user goes the the "site guide" section, pokes around National Wildlife Refuges, finds "Malheur NWR", clicks on "enter data" ...
<p>they want a context bar that sez <code>"Site Guides: National Wildlife Refuges: Malheur NWR: Enter Data"</code>
<p>not a generic context bar that nests back to wherever "enter data" happens to live in the site map.  Birdnotes has more than one place that leads to data entry and editing and my goal was to make those data management pages appear with sensible navbars that reflect where they are in the context of how they got there.
<p>Navigation in the ACS has been a major whipping boy of mine for a long time (birdnotes has been around two-three years now) and if we can come up with a less obscene solution than the ugly-URL solution which should most definitely implement it.
Collapse
Posted by Andrei Popov on
Pardon my jumping into this discussion, but [despite of all possible benefits] would it not make all the URLs an unreadable gibberish like http://openacs.org/?9cade10b81d6034fdd2176bef32bdbf99cade10b81d6034fdd2176bef32bdbf99cade10b81d6034fdd2176bef32bdbf9
Collapse
Posted by Stephen . on
I don't know much about object-verb interaction, for example why it might be better than verb-object, so I asked Google:

http://www.uidesign.net/1999/papers/UIA3.html#DN3

Interestingly, this paper suggests that verb-object is easier to use--for simple systems (define simple...)--and gives an example of a menu driven system like an ATM machine (When I heard 'menu' I immediately looked to the top of my screen and saw Actions -> Go To -> Next Message (Evolution email client); clearly verb-object).

Anyway, in the situation we're talking about a user has decided to apply some permission by clicking a link within a specific package such as bboard (object-verb!).  The question is what does the context bar show on the following page, not whether we should support verb-object, object-verb or both to get there.  But perhaps when you mention the totally useless nature of the permissions index page you don't mean the UI, which can be fixed; or the capabilities, which can be expanded upon; but the concept of verb-object, modal interaction, which should be dropped?

Assuming we make it somehow to the permission setting page, here's a couple of possible context bars:

Main Site : Subsite : Farm Forums : Pigs Forum : Permissions

Main Site : Subsite : Permissions : Pigs Forum

The first context bar is the proposed scheme, the second as it exists.  This is what Nielsen has to say about the breadcrumb trail http://www.useit.com/alertbox/20000109.html :

Breadcrumb trails serve two purposes:

1) The context of the current page (how it is nested) allows users to interpret the page better (you don't just know that you are looking at product 354, you also know that it belongs to the widget product family).

2) The links allow users to go directly to a higher level of the site in case the current page is not what they wanted, but they do want something similar.

I would argue that the proposed new context bar does not allow the user to interpret the page (permissions) better.  It shows only that the permissions page is logically higher in the hierarchy than the forum page, the forum page which the user just came from not more than a moment earlier.  Useless!

The Nielsen article also says that user's ruthlessly click the back button.  i.e. not only is the purpose of the context bar to illuminate a higher level of the site (quite different than Where You've Been) but if the context bar did show Where You've Been, users wouldn't click on it anyway because they instinctually reach for the back button and they don't look at navigation.

(Not that users don't look at navigation at all--or this discussion would be pointles--but backing out, cancelling, realising you've made a mistake, reasons for possibly clicking a link that takes you back to where you were, are much more instinctual and likely to induce a rapid response from the user than more explorative browsing where users are more likely to look at navigation to figure out site structure).

The second context bar--the way it's currently used--does offer some new information regarding context and discovery of new features.  Specifically, it shows that not only can we set permissions for the Pigs Forum that we're interested in, but there's a whole class of permission setting which presumably can be applied to other objects;  as Permissions are nested under Subsite it suggests that we'll be given one easy interface to manage permissions for a specific subset of objects;  if we want to set the permissions of some other object in another subsite or within the Main Site we have a pretty good idea that we can either navigate to the object in question (as we did in this case) and apply permissions, or we can click down to the site of interest, then look for the newly discovered Permissions section.

(Navigation could be improved; if the Permissions section appeared under Admin or Utilities perhaps, users would discover even more of the tools available).

So, the new scheme provides no information we didn't already know; the exisiting scheme exposes new features and site structure.  But is this 'jumping around' confusing?  Moving from one part of a site to another (jumping around) is perfectly normal.  I browsed the Google directory: Recreation, Autos, Makes and Models, Chevrolet, Corvette,  where I'm presented with Parts And Accessories.  These are parts and accessories for corvettes, but this title is not tacked on to the end of the current bredcrumb trail; clicking on Parts And Acessories I'm transported to Shopping, Vehicles, Parts and Accessories, Makes and Models, American, General Motors, Chevrolet, Corvette.

Is this not a simillar (jumping around) behaviour to the exisiting context bar?  The 'rule' here seems to be that a page which could appear logically in two or more locations should instead appear in one, strong location, and should be linked to.

My remaining concern would be is there something special about Permissions?  I can see that it's a little different than a simple textual page of information, but the fact that it's a specific type of interaction that's part of a more general class of interactions, along  with the benefits of discovering those interactions, makes me think that it deserves a place in the navigation hierarchy.  Anyway, we're not exclusivly concerned with Permissions, what about General Comments, a re-usable package with an even stronger claim to a place in the navigation hierarchy?

Collapse
Posted by Bart Teeuwisse on

Stephen, you bring some interesting points to the table. I agree with you that the current context bar has its uses. Your example of Permissions shows that clearly. But I do think that there is something special about Permissions: it is an administration task.

Take General Comments on the other hand. This package is used by all users to comment on published material in the site. Currently if one comments on say a news item the context bar changes from:

Main Site : News : News Item
to
Main Site : Comments

While the user does have access to other comments, these comments are all their own comments and it would make more sense for the context bar to read:

Main Site : My Account: My Comments

Only for a user with admin rights does the context bar

Main Site : Comments

make sense as the admin has access to all comments from all users.

I have noticed that users expect to see all the comments when they follow the Comments link from the context bar, even when they don't have admin permission. The proposed context bar might work better when adding a comment while a modified context bar of the current scheme seems appropriate when a users clicks on 'My Comments' from their workspace/account.

In my opinion both schemas have their place and should co-exist. Developers/designers can then choose which one is more appropriate for the job.

Collapse
Posted by Peter Marklund on
Stephen,
I am very impressed by your thorough analysis of the context bar issue. However, I am still in favor of using the context bar to display where the user has been in the instance where the user navigates from some application to a service that that application uses (i.e. Bboard forum to permissions or to category administration). I think that logically the case can be made that the permissions and the category administrations are in the context of the Bboard forum. However, regardless of whether this case can be made or not, the killer argument for me is that in the use-case I am envisioning it is simply more useful for the Bboard forum admin to be able to navigate back to his forum than to be able to navigate back to the site-wide permission or category service. Of course the back button can be used but I think the user will turn to the context bar if it is present and find it more convenient to use.
Collapse
Posted by Peter Marklund on
Stephen,
I am very impressed by your thorough analysis of the context bar issue. However, I am still in favor of using the context bar to display where the user has been in the instance where the user navigates from some application to a service that that application uses (i.e. Bboard forum to permissions or to category administration). I think that logically the case can be made that the permissions and the category administrations are in the context of the Bboard forum. However, regardless of whether this case can be made or not, the killer argument for me is that in the use-case I am envisioning it is simply more useful for the Bboard forum admin to be able to navigate back to his forum than to be able to navigate back to the site-wide permission or category service. Of course the back button can be used but I think the user will turn to the context bar if it is present and find it more convenient to use.
Collapse
Posted by Lars Pind on
Exactly, Peter. I haven't taken the time to counter Stephen's arguments myself. However, there is no doubt in my mind, that regardless of the theories we can think up for this, the context bar should say Bboard : Permissions.
Collapse
Posted by Jerry Asher on
We don't want completely ugly URLs.  We don't want cookie based context management.  I don't understand the window cloning URL problem, though I do agree it is vital to be able to surf with two windows, and to take the URL from one window and paste it into another window and go from there.

If I understand this thread, I appreciate the context bar as push-down-list argument and the need to be able to capture as much information as required in the pdl (and possibly to  operate it on the way up.)

There is also the question of emailing URLs.  What happens when one of the URLs is emailed out and later returned to?  It's the URL session capturing problem again.

Can we handle this on the server side?  Do a tinyurl.com trick and create a server side database mapping the URL PDL + new URL + new params to a tinyurl?  Then just pass each new tinyurl key around as a URL appendage?

Say we provide an API that assigns a tinyurl to any URL, and we do that just by numbering the request for each tinyURL in say base-62 {[0-9][A-Z][a-z]}, 62^6 is 56 billion hits, or 7 years of AOL demand circa WTR publishing date. So such a tinyURL key would look something like: 2X78be, um but at certain points it would also contain ufark so beware.

This database doesn't get terribly large as we can throw out all entries that are older than a session lifetime (or maybe a max-lifetime-current-sessions, or older than 24 hours....)

[tinyurl.com actually provides a repeatability function that we don't want tinyurl.com('http://a') will always return the same result.  I don't think we want that, we want to be able to detect and toss out old requests.]

The request processor can detect the URL appendage (maybe it has some ACS unique location, or a uniqifier (I hate that word, but I love the way it sounds and its function).  The request processor can detect mailed URLs in that they come in and do not have a session cookie.  And if they don't it removes the URL appendage.

This doesn't need to be stored in the database, NSVs should be sufficient -- worse case a server crashes and the visitors context is lost.  (Hell when the server comes back up we're probably going to make her relogin anyway).  In a clustered environment, the usual cluster solutions come into play -- store it in the db for programmer ease, or pass it around the cluster on our own for performance.

And then we provide an API for any page to register the new URLs, or lookup the old ones.

f(URL, query params, tinyURLold) => tinyURLnew
g(tinyURLnew) => URL, query params, tinyURLold

It may be a bad idea to store every query param in there.  Do we want the user_id stored in there as well?  Maybe not.  As a recommendation, keep user_id and similar privacy concerned (which?) parameters out of that db.

It's 1:14PM, do I need more coffee?

Collapse
Posted by Jerry Asher on
I don't particularly like the "back" button, because depending on the browser, it may not provide a good visual indication of just where I am going back to, or what happens with intermediate POSTs.  (Yay for Mozilla which seems to keep the contents of my textareas infinitely better than IE)

I would prefer a server supported backup mechanism.  If the browser is stateless, it's not clear to me it knows how to backup in any way much better than a cat with a paper cup over its face does.