Assume you are creating a hypothetical channel—findagoodwine.com.—and you want to return form submissions through a personal channel. This Web site contains the ever-so-useful Help me pick out a wine. form. A user enters the price range, preferred category, region, and food being served (if any), and your handy Web site prints out a list of recommended wines.
You are going to create a personalized channel, but instead of keeping track of your user's preferences, you will keep track of his last three requests. The general flow of the channel would work something like this:
You set up a unique findagoodwine.com cookie for each user. This cookie in turn matches a user up with a unique ID stored on a local database where you would keep track of the three most recent wine searches they have requested along with their corresponding results.
When a user requests a search, the winesearch.pl script does not actually conduct a search. Instead, it updates the user's search history in its database.
When you generate the user's front page, you include links on the front page to his three most recent searches, as indicated in the database. The user can follow those links, and the link will take him to a page that displays the actual results of those wine searches.
If no such cookie exists (or there is no history of any previous searches stored on the database), we simply generate our usual front page without the list.
When the user synchronizes the channel, the M-Business Sync Server will follow the links it finds on the front page, including any and all searches you may have specified.
Before you publish your channel to users, you set up caching.
It could really load your Web server if you have to regenerate a user's last three searches every time he synchronizes. Is there anything you can do? Yes. Once again, this can be fixed through the magic of caching.
First, make sure your form responses include a line such as Cache-Control: private,max-age=604800, since these are old search results and they probably will not change.
Second, make sure your form submissions use METHOD=GET instead of METHOD=POST—the M-Business Sync Server looks at the URL to determine if a page should be cached or not.
If you use METHOD=GET, the URL will uniquely identify the search and we will not have to go out and retrieve it all over again. When the M-Business
Sync Server notices it is retrieving a URL that already exists in the client cache, it will not bother getting an entirely
new (but exactly the same) search on your server.
Note that if you do have a search that you want to update every time the user synchronizes (maybe the user is searching for available items on
your auction site), just do not include the max-age part of the Cache-Control header.
An alternate way is to store the results of past searches as local files on your server and have links on your front page point to these files. This is useful if you want more direct control of the resulting files, or you do not feel like generating URLs that exactly duplicate the long search strings, or you just do not trust our caching mechanism.
| Send feedback about this page using email. | Copyright © 2008, iAnywhere Solutions, Inc. |
