2005Offiste/RSS Integration: Difference between revisions
Jump to navigation
Jump to search
m (notes update) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
= Notes from the session = | = Notes from the session = | ||
== Ben's architectural diagram == | |||
.---. .----------------. | .---. .----------------. | ||
| Line 5: | Line 6: | ||
'---' '----------------' | '---' '----------------' | ||
.---------. | |||
.--------. |Protocol | .----------. | |||
| feed : | ---------> | | | feed : | ---------> |Handling | | Internal | pretty printing? | ||
'--------' | '--------' '---------' /| Handlers | ---> web services? | ||
| / | | preview? | |||
.---------------. | .---------------. V / '----------' | ||
| Content Types | | | Content Types | .---------. / .----. | ||
| app/rss+xml | --> | | | app/rss+xml | --> | UCT |-- | | | ||
| app/atom+xml | | | | app/atom+xml | | System | \--| OS | ---> system registered reader | ||
'---------------' | | | | | '---------------' | | | | | ||
'---------' '----' | '---------' '----' | ||
| Line 21: | Line 22: | ||
* beltzner: two primary use cases: 1) mail-like, where each post should be tracked, marked read/unread, archived, searchable, and 2) headline-scanning like where recency is key and posts can be missed; usually for feeds with higher volume of updates. | * beltzner: two primary use cases: 1) mail-like, where each post should be tracked, marked read/unread, archived, searchable, and 2) headline-scanning like where recency is key and posts can be missed; usually for feeds with higher volume of updates. | ||
* beltzner: "Live Bookmark" can be extended to | * beltzner: "Live Bookmark" can be extended to ''any'' webpage which has been changed; could mean "watch this page for updates" | ||
* beng: part of this requires us to have a better UCT system UI which provides a better user experience for dealing with a file of unknown content type | |||
** uses OS hooks and a WSDL service to detect and suggest handlers | |||
* | * beng: better integration with [[Places|the places work]] might solve some of these problems, too, as it will allow for easier searching, archiving, marking read/unread, etc. | ||
Revision as of 21:38, 6 December 2005
Notes from the session
Ben's architectural diagram
.---. .----------------. |.))| -------> | Live Bookmarks | '---' '----------------'
.---------.
.--------. |Protocol | .----------.
| feed : | ---------> |Handling | | Internal | pretty printing?
'--------' '---------' /| Handlers | ---> web services?
| / | | preview?
.---------------. V / '----------'
| Content Types | .---------. / .----.
| app/rss+xml | --> | UCT |-- | |
| app/atom+xml | | System | \--| OS | ---> system registered reader
'---------------' | | | |
'---------' '----'
- beng, chofmann: RSS is just another type of web content, and we should try to provide a transient experience where we display that content in the most appropriate fashion
- beltzner: two primary use cases: 1) mail-like, where each post should be tracked, marked read/unread, archived, searchable, and 2) headline-scanning like where recency is key and posts can be missed; usually for feeds with higher volume of updates.
- beltzner: "Live Bookmark" can be extended to any webpage which has been changed; could mean "watch this page for updates"
- beng: part of this requires us to have a better UCT system UI which provides a better user experience for dealing with a file of unknown content type
- uses OS hooks and a WSDL service to detect and suggest handlers
- beng: better integration with the places work might solve some of these problems, too, as it will allow for easier searching, archiving, marking read/unread, etc.