Why bother with view-feed://? Why not just have the feed be styled more nicely, similar to the way that XML is styled more nicely by default in most browsers?
- a On Wed, May 6, 2009 at 6:13 PM, Evan Martin <[email protected]> wrote: > > On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson <[email protected]> > wrote: >> I have already added an API for PageActions and have a working RSS >> PageAction extension, which does feed auto-detection on the page. Now it is >> time to look into Feed previews. >> I have spoken briefly to AdamB and EvanM about feed previews and both >> suggested modelling this after the view-source implementation. It was also >> suggested to add a scheme for this (like we do with view-source), such as >> view-feed: or feed: >> I know there has been some work on this front before, although the status of >> that is not clear to me -- except that it was disabled at some point (or >> removed from the codebase?). I would love to see what was done back then, if >> anyone knows more. A cursory look through the code indicated that mime type >> sniffing for feed is done. I've heard there is also some remaining work >> required for sanitizing the feeds before showing, but besides the above >> there is not much more I know at this point in time. > > Feed previews only ever got to the state of "we know this page is a > feed, so right <here> is where we'd stick in the template". Actually, > the old file has somehow evaded deletion: > webkit/glue/resources/feed.html . > > Here are some things to consider: > - Parsing feeds is an absolute nightmare. See e.g. > http://diveintomark.org/archives/2004/02/04/incompatible-rss . You > definitely want to at least do it in the renderer process. Ideally > it'd be from JavaScript -- you might then be able to borrow the > parsing code from Mozilla(?) -- but I guess that may reject invalid > XML, which there is (or at least used to be) a ton of. Maybe we don't > care and XSL is sufficient. Definitely look at the Mozilla > implementation. > > - You should be careful about HTML content. Say site A publishes a > feed, and site B publishes a feed that mixes posts from A in among > others. If A puts <script> tags in their feed, you don't want to run > those scripts on B's origin when you attempt to preview the feed on B. > (Normally, this kind of untrusted input handling is B's problem, but > that's not how the feed world works.) Ideally, you could work around > this by somehow not having an origin *at all* when displaying a feed > -- abarth would know more about this than I would. > > - Some existing practice on the web is to use > "feed://hostname/etc.xml", which drops the protocol (and should be > interpreted as HTTP). Ideally you should redirect these into > view-feed:http://hostname/etc.xml so our view-feed works with https, > ftp, etc. URLs. > > - The feed-sniffing code we have is probably not very good and may > currently be disabled. Eye it with suspicion. This page (sorry for > the non-public URL) summarizes the behaviors of various browsers in > various circumstances: > http://www/~evanm/projects/chrome/feeds/ > http://www/~evanm/projects/chrome/xml/ > > I'd suggest starting with getting view-feed: to do the right thing > when it's handed something correct, and then worry about fleshing out > all the sniffing/redirecting/etc. second. I'd be happy to review any > changes you make in this area. > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
