SteveIvy: /* regular updates */ meta tag - expires

2008-05-29T16:05:34Z

regular updates: meta tag - expires

← Older revision		Revision as of 16:05, 29 May 2008
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 ===

Tantek: drafted

2008-01-23T03:25:23Z

drafted

New page

<h1> Subscribe to hCard</h1>
{{TOC-right}}
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.

=== 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.

== see also ==
* [[social-network-portability]]
* [[hcard-supporting-user-profiles]]
* [[hCard]]

subscribe-hcard - Revision history

SteveIvy: /* regular updates */ meta tag - expires

Tantek: drafted