Re: Server-Side Events encoded in JSON
All of this functionality can be built upon the current spec, but constraining the spec to support this convenience precludes other uses. On Wed, Apr 27, 2011 at 11:42 PM, Brett Zamir wrote: > user to parse the response text, why not simply allow each event to be a > JSON-encoded object of some kind (boolean, number, string, array, object). > Then the event.data could be an object which was already conveniently > accessible to JavaScript consumers. Presumably server-side libraries would > handle the work of doing the encoding, but the average client-side consumer > should, in my opinion, not need to be concerned with implementation details, > except to become familiar with the specific JSON response types being sent > by the server-side code/library. > > Although this would add encoding responsibilities to the server and > decoding responsibilities to the browser, I think it ought to avoid the need > for the client code to be concerned with ugly implementation details such as > the need to parse strings. > > A convention might also be used in the stream (e.g., "error: " followed by > a JSON object) to trigger errors, allowing the normal responses to be simple > strings or the like, while offering a means to distinguish them from error > messages sent by the server (e.g., to indicate that a data source was no > longer available). The event object could add an "error" property which > could be checked (or, if types were allowed as per my previous post, it > could set the event type to the reserved string "error"). > > Brett > > > > -- Benjamin Goering Hacker, Goofy Guy Livefyre Inc. +1(785)224-0136
Re: Model-driven Views
On 04/29/2011 04:11 AM, Garrett Smith wrote: On 4/28/11, Olli Pettay wrote: On 04/28/2011 04:46 AM, Rafael Weinstein wrote: Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term "use case" correctly =-). Our primary motivator is the needs of web applications, And what are those needs? It is hard to judge the proposal if it is not known what kinds of problems it is trying to solve ;) Create HTML content that gets refreshed, using JSON? That doesn't explain the feature set MDV supports. Why, for example, JSON/Model data can't affect to what kinds of elements the template creates. Or attributes. Why certain functionality is in and other functionality is out. So basically I'd like to see either some requirements document or at least public discussion about the design of the API. -Olli Load chunks of samely structured content on-demand. Sample app I made for bittorrent when applying for a job: http://dhtmlkitchen.com/tmp/bittorrent/ (waste of time, that was). For example of content that gets refreshed, a table refresh widget would update the data in the HTML TABLE by fetchng JSON. Content that is loaded on-demand but reused in a template could be a product-info panel or a tooltip. Each panel is tied to an actuator and is shown with unique data, but it is created from a template that has essentially the same structure.
[IndexedDB] Closing on bug 9903 (collations)
We've had quite a bit of debate on this but I don't think we've reached closure. At this point I would be fine with either one of a) postpone to v2 and agree that for now we'll just do binary collation everywhere or b) the last form of the proposal sent around: extra "collation" argument (following BCP47 plus whatever the UA wants to allow) in createObjectStore/createIndex, plus a collation property to interrogate it; no way to change the collation of a store/index once created. Given that this turned out to be a more elaborate topic than I had originally expected and that it doesn't seem to have a lot of traction right now, my preference would be to postpone to v2. Thoughts? Once we make a call I'll make sure the spec reflects it. Thanks -pablo
Re: [widgets] Dig Sig spec
Marcos I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc this would take less time for you and be much clearer to all. thanks regards, Frederick Frederick Hirsch Nokia On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote: > On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote: >> Well, you started with a relatively ambiguous characterization of a need >> to eliminate "redundancies and inconsistencies" and now I see you think >> the spec as written has resulted in "willful violations of the spec" and >> of course those are quite different. > Correct. But one really led to the other. The reality is that very few people > who implemented the spec really read the spec in detail. Most people seemed > to have been working from the examples. This is normal and to be expected. > Cleaning it up a bit should make it easier to follow. >> >> Since this spec is in the Candidate state (and as such, perhaps already >> deployed), I think it would be helpful if you would please flesh out all >> the changes and bug(s) you propose must be fixed ^1. Then we should be >> able to have a more informed discussion re "if it's OK to have a go at >> rewriting". > I'm ok with that, but would prefer to do it like this: > > 1. make a mirror copy of the spec. > > 2. make all the edits I think need to be made. It's not many, as the spec is > relatively small (~14 pages). > > 3. make a diff of the two documents to build the list of changes. > > 4. propose the complete list of changes to the group. > > 5. let the group decide which changes they accept or reject or need further > discussion. If the new spec is take wholesale, then great. Otherwise, it's > easy to backtrack on proposed changes. > > This is how I've done this kinds of changes in the past and it's always > worked out ok. > > > >
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, Apr 29, 2011 at 11:16 AM, Pablo Castro wrote: > We've had quite a bit of debate on this but I don't think we've reached > closure. At this point I would be fine with either one of a) postpone to v2 > and agree that for now we'll just do binary collation everywhere or b) the > last form of the proposal sent around: extra "collation" argument (following > BCP47 plus whatever the UA wants to allow) in createObjectStore/createIndex, > plus a collation property to interrogate it; no way to change the collation > of a store/index once created. > > Given that this turned out to be a more elaborate topic than I had originally > expected and that it doesn't seem to have a lot of traction right now, my > preference would be to postpone to v2. Thoughts? Once we make a call I'll > make sure the spec reflects it. I'd be fine with postponing it. However I don't think that the counter proposals that we've received will work, so I don't think that there is a reason to postpone. / Jonas
Re: [IndexedDB] Closing on bug 9903 (collations)
On Friday, 29 April 2011, Jonas Sicking wrote: > On Fri, Apr 29, 2011 at 11:16 AM, Pablo Castro > wrote: >> We've had quite a bit of debate on this but I don't think we've reached >> closure. At this point I would be fine with either one of a) postpone to v2 >> and agree that for now we'll just do binary collation everywhere or b) the >> last form of the proposal sent around: extra "collation" argument (following >> BCP47 plus whatever the UA wants to allow) in createObjectStore/createIndex, >> plus a collation property to interrogate it; no way to change the collation >> of a store/index once created. >> >> Given that this turned out to be a more elaborate topic than I had >> originally expected and that it doesn't seem to have a lot of traction right >> now, my preference would be to postpone to v2. Thoughts? Once we make a call >> I'll make sure the spec reflects it. > > I'd be fine with postponing it. However I don't think that the counter > proposals that we've received will work, so I don't think that there > is a reason to postpone. > > / Jonas > > As long as we have a binary mode I am happy. If it is to support other collations, then all browsers must support the same set of options. The question then becomes what set of collation modes to standardise on? Allowing non standard collations will result in apps that will only run correctly on one browser, and that does not seem a good idea to me. Cheers, Keean.
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, Apr 29, 2011 at 12:19 PM, Keean Schupke wrote: > On Friday, 29 April 2011, Jonas Sicking wrote: >> On Fri, Apr 29, 2011 at 11:16 AM, Pablo Castro >> wrote: >>> We've had quite a bit of debate on this but I don't think we've reached >>> closure. At this point I would be fine with either one of a) postpone to v2 >>> and agree that for now we'll just do binary collation everywhere or b) the >>> last form of the proposal sent around: extra "collation" argument >>> (following BCP47 plus whatever the UA wants to allow) in >>> createObjectStore/createIndex, plus a collation property to interrogate it; >>> no way to change the collation of a store/index once created. >>> >>> Given that this turned out to be a more elaborate topic than I had >>> originally expected and that it doesn't seem to have a lot of traction >>> right now, my preference would be to postpone to v2. Thoughts? Once we make >>> a call I'll make sure the spec reflects it. >> >> I'd be fine with postponing it. However I don't think that the counter >> proposals that we've received will work, so I don't think that there >> is a reason to postpone. >> >> / Jonas >> >> > > As long as we have a binary mode I am happy. If it is to support other > collations, then all browsers must support the same set of options. > The question then becomes what set of collation modes to standardise > on? Allowing non standard collations will result in apps that will > only run correctly on one browser, and that does not seem a good idea > to me. I agree that we will eventually want to standardize the set of allowed collations. Similarly to how we'll want to standardize on one set of charset encodings supported. However I don't think we, in this spec community, have enough experience to come up with a good such set. So it's something that I think we should postpone for now. As I understand it there is work going on in this area in other groups, so hopefully we can lean on that work eventually. Of course, we still do need to have a standardized vocabulary for the collations though. / Jonas
[Bug 12574] New: AbstractWorker and WorkerGlobalScope should inherit EventTarget
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574 Summary: AbstractWorker and WorkerGlobalScope should inherit EventTarget Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org This was discussed on the webapps list I believe. We should try to include EventTarget in the prototype chain on all objects that are event targets. This way people can modify the EventTarget prototype object to add API to all event targets. A similar modification was done in the DOM Core spec where Node now inherits EventTarget and in the XHR spec where XHR now inherits EventTarget. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
On Sun, 26 Dec 2010, Glenn Maynard wrote: > > This made me wonder about this: > > > When support for a feature is disabled (e.g. as an emergency measure > > to mitigate a security problem, or to aid in development, or for > > performance reasons), user agents must act as if they had no support > > for the feature whatsoever, and as if the feature was not mentioned in > > this specification. For example, if a particular feature is accessed > > via an attribute in a Web IDL interface, the attribute itself would be > > omitted from the objects that implement that interface — leaving the > > attribute on the object but making it return null or throw an > > exception is insufficient. > > vs. this: > > > The user agent may throw a SECURITY_ERR exception instead of returning > > a Storage object if the request violates a policy decision (e.g. if > > the user agent is configured to not allow the page to persist data). > > If localStorage is disabled due to user configuration, which rule > applies? The former (remove the feature entirely) is much better for me > as a developer. I've already had to write code to test putting data in > localStorage and see if it throws an exception, on top of simply saying > "'localStorage' in window". These are not mutually exclusive. If localStorage is disabled, then it must act as if it's not there. However, if it's enabled but configured to not allow a particular page to access data, or if it is disabled after a particular page has obtained the Window object on which the localStorage attribute is found, then the second clause applies. This is more detail than we normally put into this kind of thing but in this particular case IIRC the detail was added in response to some questions from implementors about some relevant edge cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [IndexedDB] Closing on bug 9903 (collations)
There is always something like UCA: http://www.unicode.org/reports/tr10/ which looks interesting. Cheers, Keean. On 29 April 2011 20:32, Jonas Sicking wrote: > On Fri, Apr 29, 2011 at 12:19 PM, Keean Schupke wrote: > > On Friday, 29 April 2011, Jonas Sicking wrote: > >> On Fri, Apr 29, 2011 at 11:16 AM, Pablo Castro > >> wrote: > >>> We've had quite a bit of debate on this but I don't think we've reached > closure. At this point I would be fine with either one of a) postpone to v2 > and agree that for now we'll just do binary collation everywhere or b) the > last form of the proposal sent around: extra "collation" argument (following > BCP47 plus whatever the UA wants to allow) in createObjectStore/createIndex, > plus a collation property to interrogate it; no way to change the collation > of a store/index once created. > >>> > >>> Given that this turned out to be a more elaborate topic than I had > originally expected and that it doesn't seem to have a lot of traction right > now, my preference would be to postpone to v2. Thoughts? Once we make a call > I'll make sure the spec reflects it. > >> > >> I'd be fine with postponing it. However I don't think that the counter > >> proposals that we've received will work, so I don't think that there > >> is a reason to postpone. > >> > >> / Jonas > >> > >> > > > > As long as we have a binary mode I am happy. If it is to support other > > collations, then all browsers must support the same set of options. > > The question then becomes what set of collation modes to standardise > > on? Allowing non standard collations will result in apps that will > > only run correctly on one browser, and that does not seem a good idea > > to me. > > I agree that we will eventually want to standardize the set of allowed > collations. Similarly to how we'll want to standardize on one set of > charset encodings supported. However I don't think we, in this spec > community, have enough experience to come up with a good such set. So > it's something that I think we should postpone for now. As I > understand it there is work going on in this area in other groups, so > hopefully we can lean on that work eventually. > > Of course, we still do need to have a standardized vocabulary for the > collations though. > > / Jonas >
Re: Model-driven Views
On Apr 28, 2011, at 5:46 AM, Alex Russell wrote: > On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak wrote: >> >> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: >> >>> >>> I agree with much of this. However it's hard to judge without a bit >>> more meat on it. Do you have any ideas for what such primitives would >>> look like? >> >> That's best discussed in the context of Rafael explaining what limitations >> prevent his proposal from working as well as it could purely as a JS library. > > The goal for this work is explicitly *not* to leave things to > libraries -- I'd like for that not to creep into the discussion as an > assumption or a pre-req. I introduce this not as a pre-req or assumption but rather as my view of the best approach to addressing templating use cases, at least as a first step.I would also like it not to be a pre-req that templating must be addressed by a monolithic solution. But I am willing to hear out arguments for how it is better. > Libraries are expensive, slow, and lead to a tower-of-babel problem. That is all potentially true. But the tower-of-babel problem already exists in this area. Adding a new solution won't make the existing solutions disappear. The best way to mitigate the costs you describe is to provide primitives that enable the existing solutions to improve their quality of implementation. > On the other hand, good layering and the > ability to explain current behavior in terms of fewer, smaller > primitives is desirable, if only to allow libraries to play whatever > role they need to when the high-level MDV system doesn't meet some > particular need. That is a reasonable line of thinking. But in addition to modularity, I would also suggest a particular ordering - first add the right primitives to enable efficient, convenient DOM-based templating, then look for libraries to adopt it and/or promulgate new libraries, and only then standardize the high-level bits if they turn out to be high-value at that point. I had many particular supporting arguments for this approach, which your comments do not address. > >> The one specific thing I recall from a previous discussion of this proposal >> is that a way is needed to have a section of the DOM that is inactive - >> doesn't execute scripts, load anything, play media, etc - so that your >> template pattern can form a DOM but does not have side effects until the >> template is instantiated. > > Right. The contents of the element are in that inactive state. > >> This specific concept has already been discussed on the list, and it seems >> like it would be very much reusable for other DOM-based templating systems, >> if it wasn't tied to a specific model of template instantiation and updates. > > Having it be a separately addressable primitive sounds like a good > thing...perhaps as some new Element type? I'm glad we agree on this aspect. I'm not sure what you mean by new Element type, but nothing prevents us from simply defining a new ordinary element (HTML element or otherwise) that has this semantic. Note that HTML elements generally already have the desired inactive behavior in viewless documents (as created by createDocuemtn or XMLHttpRequest) so an element that introduces such behavior should be quite modest in terms of spec and implementation burden. Regards, Maciej
