<div class="gmail_quote">On Sat, Aug 21, 2010 at 5:48 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div>Reviving ancient thread...<br></div>
</blockquote><div> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
To get a feel for the different approaches and tradeoffs, I've<br>
implemented a prototype of this using the two of the approaches that<br>
were discussed in this thread:<br>
<br>
1. Embed metadata in the page, building off the existing support for,<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. Link to a separate metadata document:<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">As I see it, here are the advantages of the two approaches:<br>
<br>
1:<br>
- a bit simpler<br>
- builds off the existing features in the platform<br></blockquote><div><br>- blends with other concepts too. Like the favicon sizes could be used for other, non-webapp uses.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
2:<br>
- DRY-er (doesn't repeat the same information on multiple pages of the<br>
application)<br>
- Easier for third-party agents (eg search engines) to consume<br>
(doesn't require an HTML parser)<br>
- The browser doesn't have to load a page to consume<br>
<br>
Based on this, I'm liking #2 better as a path forward and am going to<br>
push to get an implementation of this working in Chromium.<br>
<br>
Are there any other vendors interested in doing something similar? If<br>
so, I'd like to hash out the details so we end up with<br>
interoperability.<br></blockquote></div><br>We are planning a similar feature for the next release of Mozilla's
mobile Firefox. See:<br>
<a href="https://wiki.mozilla.org/Mobile/Projects/WebApp_Support">https://wiki.mozilla.org/Mobile/Projects/WebApp_Support</a><br>
<br>Some of our current implementation leans more toward #1, but we could look at #2 for a lightweight, installed webapp design.<br>