subscribe-hcard: Difference between revisions
(drafted) |
(→regular updates: meta tag - expires) |
||
| Line 8: | Line 8: | ||
Once a day seems like a reasonable frequency. Perhaps poll adaptively, that is, when an update finds new information, perhaps check more frequently until no new information is found, and then lengthen the time between checks until reaching a once per day (per week?) frequency. | Once a day seems like a reasonable frequency. Perhaps poll adaptively, that is, when an update finds new information, perhaps check more frequently until no new information is found, and then lengthen the time between checks until reaching a once per day (per week?) frequency. | ||
==== meta tag - expires ==== | |||
Another option would be to honor the [http://www.i18nguy.com/markup/metatags.html#expires expires meta tag]. | |||
The date and time after which the document should be considered expired. An illegal EXPIRES date, | |||
e.g. "0", is interpreted as "now". Setting EXPIRES to 0 may thus be used to force a modification | |||
check at each visit. Web robots may delete expired documents from a search engine, or schedule a revisit. | |||
=== event based updates === | === event based updates === | ||
Latest revision as of 16:05, 29 May 2008
Subscribe to hCard
One of several aspects of social-network-portability implementation details regarding hcard-supporting-user-profiles.
update frequency
regular updates
How often should a subscription to an hCard regularly poll that hCard for updates (similar to the question of how often should a feed reader subscription to an RSS/Atom feed pool that feed for updates) ?
Once a day seems like a reasonable frequency. Perhaps poll adaptively, that is, when an update finds new information, perhaps check more frequently until no new information is found, and then lengthen the time between checks until reaching a once per day (per week?) frequency.
meta tag - expires
Another option would be to honor the expires meta tag.
The date and time after which the document should be considered expired. An illegal EXPIRES date, e.g. "0", is interpreted as "now". Setting EXPIRES to 0 may thus be used to force a modification check at each visit. Web robots may delete expired documents from a search engine, or schedule a revisit.
event based updates
It may be useful to trigger additional updates of hCards based on a number of external events, e.g.:
- whenever DST changes occur, anywhere world-wide, re-retrieve someone's hCard (as their "tz" timezone information will have likely changed).
- when a location presence service (e.g. Plazes, Dopplr, Dodgeball) indicates that the person is changing location, re-retrieve their hCard(s), as their "geo" and "tz" properties may have changed / updated.
- when a professional status service (e.g. LinkedIn) indicates that a person's job has changed, re-retrieve their hCard(s), as their "org" and "title" properties may have changed / updated.