Re: [webcomponents]: Naming the Baby
Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro wrote: > 'Component Include' > > 'Component Include' describes what the markup is doing, and I like that a > lot. The syntax is similar to including a stylesheet or a script and so > this name should be evocative enough for even a novice to understand what > is implied by it. > > - Angelina > > > On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles wrote: > >> Fwiw, my main concern is that for my team and for lots of other people I >> communicate with, 'component' is basically synonymous with 'custom >> element'. In that context, 'component' referring to >> chunk-of-web-resources-loaded-via-link is problematic, even if it's not >> wrong, per se. >> >> We never complained about this before because Dimitri always wrote the >> examples as (note the plural). When it was >> changed to was when the rain began. >> >> Scott >> >> >> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon wrote: >> >>> I like the idea of "package" seems all encompassing which captures the >>> requirements nicely. That or perhaps "resource", but then resource seems >>> singular. >>> >>> Or perhaps "component-package" so it is obvious that it's tied to web >>> components? >>> >>> -Ryan >>> >>> >>> On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov wrote: >>> Hello folks! It seems that we've had a bit of informal feedback on the "Web Components" as the name for the spec (cc'd some of the "feedbackers"). So... these malcontents are suggesting that "Web Components" is more a of a general name for all the cool things we're inventing, and >>> rel=component> should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG< >>> >>> >> >
Re: [webcomponents]: Naming the Baby
'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles wrote: > Fwiw, my main concern is that for my team and for lots of other people I > communicate with, 'component' is basically synonymous with 'custom > element'. In that context, 'component' referring to > chunk-of-web-resources-loaded-via-link is problematic, even if it's not > wrong, per se. > > We never complained about this before because Dimitri always wrote the > examples as (note the plural). When it was > changed to was when the rain began. > > Scott > > > On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon wrote: > >> I like the idea of "package" seems all encompassing which captures the >> requirements nicely. That or perhaps "resource", but then resource seems >> singular. >> >> Or perhaps "component-package" so it is obvious that it's tied to web >> components? >> >> -Ryan >> >> >> On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov wrote: >> >>> Hello folks! >>> >>> It seems that we've had a bit of informal feedback on the "Web >>> Components" as the name for the spec (cc'd some >>> of the "feedbackers"). >>> >>> So... these malcontents are suggesting that "Web Components" is more a >>> of a general name for all the cool things we're inventing, and >> rel=component> should be called something more specific, having to do >>> with enabling modularity and facilitating component dependency >>> management that it actually does. >>> >>> I recognize the problem, but I don't have a good name. And I want to >>> keep moving forward. So let's come up with a good one soon? As >>> outlined in >>> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html >>> >>> Rules: >>> >>> 1) must reflect the intent and convey the meaning. >>> 2) link type and name of the spec must match. >>> 3) no biting. >>> >>> :DG< >>> >> >> >
Re: Fixing appcache: a proposal to get us started
> This is a tricky problem indeed. > > The current appcache actually has the behavior that you're advocating, > but that's something that a lot of developers has complained about. In > fact, that's the second biggest complaint that I've heard only > trailing the confusing "master entries" behavior. > > I personally think the problem with this particular aspect of the existing appcache is that its so incredibly hard to clear the cache and go online during development - i.e. once you're offline you have to jump through hoops to get back online. A secondary issue was that once you as a developer got used to dealing with that, If your users somehow get stuck in an offline state because of a bug, there is/was no real way to "repair" them other than telling them to clear their cache. > > On the other hand, it creates the "load twice to get latest version" > behavior that a lot of developers dislike. I.e. when a user opens a > website they end up getting the previous version of the website and > have to reload to get the new version. > > I think that if there is a programmatic API that is available early-on, then at least starting in offline gives the developer the option of going online if they so choose - and it could be done even before the onload handler if they want to avoid flashing the old/deprecated page in the browser. If you require hitting the network first, then I can't think of how you'd write programmatic hooks to bypass that. I personally think that no matter how expressive the declarative syntax is, developers are always going to need to work around it - "expiration" or "staleness" is simply too complex to just give an absolute or relative date or time - caching policy in apps can simply depend on things that extend beyond your caching syntax - I mean imagine a caching policy that depends on it being before or after sunset in your locale. > > If you have other ideas for how we can solve this then I'd love to > hear it. If we need to add more knobs to allow authors to choose which > policies they want to use then I have no problem with that. It would > be particularly interesting to hear what policies people are planning > on implementing using NavigationController to see if we can enable > those. > > A more complex, real example: at my last company had a "systemwide horizon" expiration policy that we implemented with a caching proxy. Imagine this: a very large interconnected data set where individuals spent their time editing data in small regions of the corpus. The goal was if you made an edit, then everything YOU saw would be consistent with that edit. It was perfectly reasonable to have other users see "stale" versions of any page - a poor man's (i.e. startup with only a few application server's) eventually-consistent solution. The way this worked, if any individual user made changes to a particular dataset that affected a page, they would get a cookie set on their client saying "you have made changes through time T" and all future pages that they visited had to be newer than time T. When the browser would hit the proxy with an If-Modified-Since, the proxy would look at the cookie and say "Hmm.. I have a stale version of this page at time T-6, I'd better regenerate it" or "I have a version of the page at time T+2, so I can give this to you" - To make this work we had to set max-age=0, essentially bypassing the entire user's browser cache for every page, even if the server mostly responded with a 304. (so the proxy server sitting in our colo in Santa Clara functioned as your browser's cache because that was the place we could programatically write a policy) That really sucked for performance though, so we increased max-age to maybe 30 seconds, and put a generated in the head that included the time the page was generated, and then compared the cookie to the embedded time. If the cookie was higher, then we know the page was served stale (by our definition of stale) from the browser cache so we forced a refresh. Since this was all in the , the page didn't even flicker. Something like