Re: [whatwg] Installable web apps
On 2010-05-26 19:10, Aaron Boodman wrote: On Wed, May 26, 2010 at 4:30 AM, Henri Sivonenhsivo...@iki.fi wrote: There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app (Building a serverless app). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON. This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. There are, however, a lot of similarities between your proposal and widgets. I compared the manifests of both crx and widgets, and I believe the metadata included in crx maps to that in widgets as follows: *Chrome Manifest* | *Widgets Manifest* (implied) | widget viewmodes=windowed name | name version | widget version=... icons | icon src= - 24 | ... height=24 width=24 - 128 | ... height=128 width=128 permissions | feature web_content | access - enabled | (implied) - origin | ... origin=... - paths | N/A - what's the purpose of this, why is it needed? launch: | Default start file, e.g. index.html, or - web_url | N/A - local_path | content src=... Digital signatures are also supported in widgets. Are there any limitations that you are aware of with widgets-digsig compared with crx signatures that might make them unsuitable? http://www.w3.org/TR/widgets-digsig/ I completely agree that app cache is a more webby way of making apps available offline than packaging. In particular, app cache preserves the ability to deep-link into an application, which is an important characteristic of the web. The source of our support for packaged applications is that we have gotten a lot of feedback from developers that find packages a very convenient way to develop applications that work offline. I think the reason is that packages are conceptually much simpler than app caches. That said, I think this is mainly a lack of good tool support for app cache and good documentation, and I think it can eventually be overcome. For now, I would like to focus on live web apps, not packaged local apps. Fair enough. I think widgets already cover the packaged local app cases anyway. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That was the user experience offered by Safari 4 beta's experimental Save as Web Application feature and Mozilla Prism. I can understand why that is perceived as suboptimal for many users. But they had the advantage of allowing the user to turn any website they wanted into an application, whereas your proposed model depends on the site explicitly providing an application to install. There are benefits to both models. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. Indeed. If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, uselink rel=something to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names. We have a growing set of metadata you're trying tolink to: - Icons link rel=icon sizes=24x24 href=icon.png - Application name (you didn't mention this, but I think it is nice to have distinct from thetitle, which is often overloaded with status information) meta name=application-name content=... - Any permissions Not yet available. To me, this all leads to the following proposal: html head !-- for UAs that want a button in the browser chrome to appify -- link rel=application-description href=myapp.json /head body !-- for UAs that want a button in the [content area] to appify -- button onclick=navigator.installApplication()install/button This is reminiscent of the old bb element proposal that used to be in
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, 13 May 2010 16:47:34 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 12 May 2010 20:01:11 +0200, Ojan Vafai o...@chromium.org wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote: establishing a WebSocket connection: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] Still, it seems likely that user agents will want to have limits on the number of established WebSocket connections, whether to a single remote host or multiple remote hosts, in a single tab or overall. Why? Is the concern that we'd run out of memory? Overload the user's network connection? If nothing else, the underlying OS might have a limit on the number of open connections. From our testing it seems that Vista has a limit of 1398 open sockets. Apparently Ubuntu has a limit of 1024 file descriptors per process. On low-end devices and low-end networks, it seems likely that there's a relatively low limit on the number of connections. -- Simon Pieters Opera Software
[whatwg] Problem with http://www.webmproject.org/
Off topic (but I couldn't find any contact info on the site) Could someone please fix http://www.webmproject.org/? The left side of the page is inaccessible at 1024 x 768 (800 x 600 for example), which makes the site unusable. (It has to be some common css that Google uses on their sites as the same problem happens on Vemo-branded pages on youtube) Thanks -- Michael
Re: [whatwg] Problem with http://www.webmproject.org/
On Thu, 2010-05-27 at 11:12 -0400, Michael A. Puls II wrote: Off topic (but I couldn't find any contact info on the site) Could someone please fix http://www.webmproject.org/? The left side of the page is inaccessible at 1024 x 768 (800 x 600 for example), which makes the site unusable. (It has to be some common css that Google uses on their sites as the same problem happens on Vemo-branded pages on youtube) Thanks It looks like it's using the old (and pretty buggy) hack of using negative margins and absolute positioning of 50% to align the site in the middle, and like you've seen, it breaks very easily. Can be fixed by removing the positioning and margin and replacing it with margin: auto; Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Problem with http://www.webmproject.org/
On Thu, May 27, 2010 at 17:12, Michael A. Puls II shadow2...@gmail.com wrote: Off topic (but I couldn't find any contact info on the site) Could someone please fix http://www.webmproject.org/? The left side of the page is inaccessible at 1024 x 768 (800 x 600 for example), which makes the site unusable. (It has to be some common css that Google uses on their sites as the same problem happens on Vemo-branded pages on youtube) Thanks -- Michael Hello Michael, You should write a message to the WebM discussion groups as it's listed on the Tools page, and in the latest blog entry. http://groups.google.com/a/webmproject.org/group/webm-discuss/topics Thank you, Peter
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 27, 2010 at 10:28 AM, Simon Pieters sim...@opera.com wrote: From our testing it seems that Vista has a limit of 1398 open sockets. Apparently Ubuntu has a limit of 1024 file descriptors per process. On Linux, that is just the default (which may vary between distros) and can be configured by the administrator -- see ulimit -n, sysctl -w fs.file-max, and fs.file-max in /etc/sysctl.conf (location may var between Linux distros). -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 27, 2010 at 11:45 AM, John Tamplin j...@google.com wrote: On Thu, May 27, 2010 at 10:28 AM, Simon Pieters sim...@opera.com wrote: From our testing it seems that Vista has a limit of 1398 open sockets. Apparently Ubuntu has a limit of 1024 file descriptors per process. On Linux, that is just the default (which may vary between distros) and can be configured by the administrator -- see ulimit -n, sysctl -w fs.file-max, and fs.file-max in /etc/sysctl.conf (location may var between Linux distros). I think it is reasonable to assume that the browser must be able to operate effectively within those default limits, though: mostly the browser can't adjust those, or usefully instruct the user to do so. Mike
Re: [whatwg] Problem with http://www.webmproject.org/
On Thu, 27 May 2010 11:25:56 -0400, Peter Beverloo pe...@lvp-media.com wrote: On Thu, May 27, 2010 at 17:12, Michael A. Puls II shadow2...@gmail.com wrote: Off topic (but I couldn't find any contact info on the site) Could someone please fix http://www.webmproject.org/? The left side of the page is inaccessible at 1024 x 768 (800 x 600 for example), which makes the site unusable. (It has to be some common css that Google uses on their sites as the same problem happens on Vemo-branded pages on youtube) Thanks -- Michael Hello Michael, You should write a message to the WebM discussion groups as it's listed on the Tools page, and in the latest blog entry. http://groups.google.com/a/webmproject.org/group/webm-discuss/topics Thanks. I can't see a tools menu and didn't read the blog as I was looking for a Contact section. I was able to find that page by searching google, but when trying to join the group, it was asking me for a @webmproject address that I didn't have, so I just closed the page. I now notice there's a use another email address link. Wasn't sure if my gmail address would work, but tried it and it did. -- Michael
Re: [whatwg] Installable web apps
On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-05-26 19:10, Aaron Boodman wrote: On Wed, May 26, 2010 at 4:30 AM, Henri Sivonenhsivo...@iki.fi wrote: There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app (Building a serverless app). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON. This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. There are, however, a lot of similarities between your proposal and widgets. I compared the manifests of both crx and widgets, and I believe the metadata included in crx maps to that in widgets as follows: *Chrome Manifest* | *Widgets Manifest* (implied) | widget viewmodes=windowed name | name version | widget version=... icons | icon src= - 24 | ... height=24 width=24 - 128 | ... height=128 width=128 permissions | feature web_content | access - enabled | (implied) - origin | ... origin=... - paths | N/A - what's the purpose of this, why is it needed? launch: | Default start file, e.g. index.html, or - web_url | N/A - local_path | content src=... Digital signatures are also supported in widgets. Are there any limitations that you are aware of with widgets-digsig compared with crx signatures that might make them unsuitable? Maybe, but I think that debate should be separate from this thread. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That was the user experience offered by Safari 4 beta's experimental Save as Web Application feature and Mozilla Prism. I can understand why that is perceived as suboptimal for many users. But they had the advantage of allowing the user to turn any website they wanted into an application, whereas your proposed model depends on the site explicitly providing an application to install. There are benefits to both models. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. Indeed. If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, uselink rel=something to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names. We have a growing set of metadata you're trying tolink to: - Icons link rel=icon sizes=24x24 href=icon.png My concern with reusing favicons is that some browsers support changing them at runtime, so they can be overloaded to show status information. We were actually planning on doing this in Chrome too, even for the larger sizes. Also, it seems weird to repeat the application information on every webpage in an app, so I prefer linking off to a separate resource anyway. I wonder if it would be too much of a hack to only use the icon listed in the HTML for use in the launch/bookmark UI, and only display runtime changes to it in the tab/window titlebar. - Application name (you didn't mention this, but I think it is nice to have distinct from thetitle, which is often overloaded with status information) meta name=application-name content=... You're right -- that one does exist already within the page. And it is a shame to waste these existing features. The more I think about it, the more I start to agree that just using the meta and link tags we already have (with perhaps one addition for permissions), could work. Let me think about it some more. - Any permissions Not yet available. To me, this all leads to the following proposal: html head !-- for UAs that want a button in the browser chrome to appify -- link rel=application-description href=myapp.json
Re: [whatwg] Image resize API proposal
On Tue, May 25, 2010 at 3:58 AM, Kornel Lesinski kor...@geekhood.netwrote: JPEG can be efficiently decoded at fraction of its size — without full decode and scale process. This process also needs only fraction of memory required for full scaling, which might matter on low-end mobile devices. Letting UA utilize this feature may give huge performance gains. Agreed. I could see this being done. Scaling isn't the only operation desirable — in some cases users might also want to crop the image (e.g., to upload only their face as an avatar), and cropping interface needs to be platform-specific — on touchscreen devices I'd rather use gestures than select-by-click'n'drag interface typical for desktop. ok. I think scaling of images before upload might be left completely up to UA. From site's perspective it could look like user simply selected scaled-down file. It could even be done declaratively — site could define desired size and whether user should be asked to crop the image: input type=file accept=image/* max-image-size=1000x1000 crop=allowed This appears to be so limited that it doesn't allow for the web page to display a preview of what is being uploaded. Take the gmail example from that I gave in this thread, where the image is dragged into an email and then the image is resized before uploading. Ideally, the image shown in the email would be the image that is being sent. Actually, I wish UAs offered scaling even for plain input type=file, because I don't expect every site with image upload to add extra code for resizing. I agree that having it be totally declarative would be simpler to write in a web page. dave
Re: [whatwg] Image resize API proposal
Summarizing We've found that a synchronous solution will likely lead to a bad user experience. As an alternative, we've presented an async apihttp://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026292.htmlwhich solves this frequent use casehttp://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026435.htmlfor web pages (which may involve many images at once) and allows the UA to optimize the operation (by using the GPU and/or multiple threads): image. getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent /* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio /* op */, rotateExif /* op */); dave
Re: [whatwg] device element, streams and peer-to-peer connections
On Fri, May 21, 2010 at 1:29 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren nicklas.sandg...@ericsson.com wrote: As mentioned in the draft, the peer-to-peer API must rely on underlying protocols/mechanisms to establish the connections and to transport the streams. What are the thoughts regarding these protocols, and has there been any discussion around this topic? Last I checked the hope is that the protocol problem will go away. So far it seems that is unlikely. :-) There has been some limited discussion about the peer-to-peer section as it relates to real-time peer to peer gaming applications: http://old.nabble.com/Real-time-networking-in-web-applications-and-games-td27994693.html And references a proposed lower level (UDP-based) WebSocket-like protocol: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt The approach here was to punt as much of the flow control/retransmission policy to the application level, whether you're streaming video streams, game data or whatever. You could also debate how often peer-to-peer media streams will actually work. Aren't FWs and NATs going to give problems in many cases? Maybe it would be better to design for a situation where the media always go via a server. Additional benefits are that WS could be used for media transport, and that the media could be transcoded if the codec capabilities of the clients do not match. I'm not really sure how this is an alternative approach. It would just be leaving peer-to-messaging out... Streaming video via WebSocket is something we definitely want to enable in due course, irrespective of whether peer-to-peer messaging comes to fruition. To answer the question of problem in p2p regarding FWs and NATs, the libjingle folks report that 92% of participants are able to connect directly: http://code.google.com/apis/talk/libjingle/important_concepts.html#connections with the remainder using simple message relay servers. In practice this represents a hugely significant bandwidth reduction for application hosts. Given the level of possible application sophistication promise in the next gen web, leaving out such a huge efficiency win would be a shame. An approach that allows data output from devices to be adjusted to a target bit rate and collected in meaningful chunks, but not directly connected to the transport mechanism could be a viable path. A device stream could be transported either via WebSocket or a p2p networking layer with equal ease, leaving the message marshaling up to the web app. Any feedback on the specific p2p packet layer protocol is always welcome. Regards, Mark
Re: [whatwg] device element, streams and peer-to-peer connections
On Thu, May 27, 2010 at 3:34 PM, Mark Frohnmayer mark.frohnma...@gmail.com wrote: There has been some limited discussion about the peer-to-peer section as it relates to real-time peer to peer gaming applications: http://old.nabble.com/Real-time-networking-in-web-applications-and-games-td27994693.html And references a proposed lower level (UDP-based) WebSocket-like protocol: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt The approach here was to punt as much of the flow control/retransmission policy to the application level, whether you're streaming video streams, game data or whatever. Why is relying on TCP for reliable delivery inferior to asking applications to re-implement reliable transmission?
Re: [whatwg] device element, streams and peer-to-peer connections
On Thu, May 27, 2010 at 6:22 PM, James Salsman jsals...@gmail.com wrote: Why is relying on TCP for reliable delivery inferior to asking applications to re-implement reliable transmission? In real-time networked applications the retransmission delay imposed by TCP can cause unnecessary and noticeable hitches in the experience; hence many real-time games use custom network stacks built atop UDP -- for a more in-depth read you can check out (somewhat dated at this point but largely relevant) : http://www710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2008/tribes_networking_model.pdf . This is not to suggest TCP is somehow inferior, just that for certain applications it's not the right tool. The next gen web has all the pieces in at least prototype form to support full, high-performance apps, but without low-level networking support (real-time, p2p) whole classes of applications will be excluded.
Re: [whatwg] device element, streams and peer-to-peer connections
On Thu, May 27, 2010 at 7:59 PM, Mark Frohnmayer mark.frohnma...@gmail.com wrote: On Thu, May 27, 2010 at 6:22 PM, James Salsman jsals...@gmail.com wrote: Why is relying on TCP for reliable delivery inferior to asking applications to re-implement reliable transmission? In real-time networked applications the retransmission delay imposed by TCP can cause unnecessary and noticeable hitches in the experience; hence many real-time games use custom network stacks built atop UDP Would it be appropriate to allow selection between reliable delivery involving delay and unreliable delivery with the shorter delay characteristics of UDP by allowing the user to select between the TCP-based asynchronous HTTP/HTTPS multipart/form-encoded POST of input type=file accept=audio as per http://www.w3.org/TR/device-upload and use UDP for synchronous or asynchronous device element I/O? Best regards, James Salsman
