Re: [widgets] localStorage vs preferences
On Jul 20, 2009, at 17:32 , Marcos Caceres wrote: Ok, so, widget.preferences MUST NOT equal window.localStorage. The are separate things. Both can be used. Right? Of course! -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] localStorage vs preferences
Agreed. Currently I would summarize the situation as: A UA that conforms to the W3C A+E spec MUST make widget.preferences available. The UA environment MAY also provide access to window.localStorage The UA MAY use window.localStorage to store widget.preferences (and therefore the two collections will have the same content) Recommendation for Widget authors: use widget.preferences An author could use both, but would run the risk of unpredictable behaviour. For example, storing objects with the same key using both widget.preferences and window.localStorage would have different results in different UAs. For Widget authors I really think sticking to widget.preferences is the safest approach to ensure their widget is portable. S On 21 Jul 2009, at 10:32, Robin Berjon wrote: On Jul 20, 2009, at 17:32 , Marcos Caceres wrote: Ok, so, widget.preferences MUST NOT equal window.localStorage. The are separate things. Both can be used. Right? Of course! -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/ smime.p7s Description: S/MIME cryptographic signature
[widgets] removing onmodechange and viewMode from AE
I think we should remove onmodechange and viewMode from the AE spec
and move them to the View modes spec (View Modes defines
ModeChangeEvent already!). Those attributes are currently
underspecified in AE and can't be properly specified till we have a
View Modes spec anyway.
If we move them, we can add them as supplemental to the Widget object:
[Supplemental] interface Widget {
readonly attribute DOMString viewMode;
attribute ModeChangeListener onmodechange;
};
Moving them will allow AE to be finished more quickly.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] removing onmodechange and viewMode from AE
+1
Sounds sensible - I've had a hard time figuring out what to do about
these without the view modes spec being completed.
S
On 21 Jul 2009, at 17:32, Marcos Caceres wrote:
I think we should remove onmodechange and viewMode from the AE spec
and move them to the View modes spec (View Modes defines
ModeChangeEvent already!). Those attributes are currently
underspecified in AE and can't be properly specified till we have a
View Modes spec anyway.
If we move them, we can add them as supplemental to the Widget object:
[Supplemental] interface Widget {
readonly attribute DOMString viewMode;
attribute ModeChangeListener onmodechange;
};
Moving them will allow AE to be finished more quickly.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
smime.p7s
Description: S/MIME cryptographic signature
Re: [widgets] removing onmodechange and viewMode from AE
On Jul 21, 2009, at 7:27 PM, Scott Wilson scott.bradley.wil...@gmail.com
wrote:
+1
Sounds sensible - I've had a hard time figuring out what to do about
these without the view modes spec being completed.
I guess this is also good for UA that don't support view mode
switching. Means that they can conform to AE
S
On 21 Jul 2009, at 17:32, Marcos Caceres wrote:
I think we should remove onmodechange and viewMode from the AE spec
and move them to the View modes spec (View Modes defines
ModeChangeEvent already!). Those attributes are currently
underspecified in AE and can't be properly specified till we have a
View Modes spec anyway.
If we move them, we can add them as supplemental to the Widget
object:
[Supplemental] interface Widget {
readonly attribute DOMString viewMode;
attribute ModeChangeListener onmodechange;
};
Moving them will allow AE to be finished more quickly.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: File API Feedback
Michael Nordman wrote: http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. The motivating usecase for this feature in Gears is to compose the body of a POST in the multipart/form-data format, including binary file parts. The resulting blobs can then be uploaded with HttpRequest. For example, Gmail uses this when sending/saving messages with attachments that had been queued for delivery while offline. Currently, the methods defined on the FileData interface in the FileAPI specification do not provide the ability to generate chunks of binary data within script, which can then be appended to a FileData object. Also, we need more discussion around storing FileData objects (files) between sessions. Right now we have on the table a URL that refers to files that is short lived, and a method that splices a FileData object asynchronously (with offset and length). These haven't been added to the draft that's in circulation, but I hope to add them shortly. I'd like to make sure I understand your use case. If an attachment is queued already, doesn't Blob.slice(offset, length) generate *new* Blobs from that data, which can in turn be used with HttpRequest? It seems that you need: void append(data) (defined on BlobBuilder) to extract data from storage and then append it to any other Blob, and then call getAsBlob() (defined on BlobBuilder) to coin a new Blob, with the new data appended. For now, can a byte-ranged splice method defined on FileData (to asynchronously create ranged FileData objects) satisfy your use case? That way, we can discuss file data persistence a bit more, and work on this in another edition of the specification. I'll report back with a draft. -- A*
RE: DataCache API - editor's draft available
On Monday, July 20, 2009 1:43 PM, Nikunj R. Mehta wrote: On Jul 17, 2009, at 9:31 AM, Adrian Bateman wrote: On Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote: On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote: ... Does the situation change if I am building an application from scratch that wants to deal with network disconnections? In that case, you should be able to take advantage of the presence of interceptors and write your code to move to the client when client- side execution is desirable. If this application is used in environments that do not support interception, then it will work just fine with server-side execution. Of course, the application won't do the right recovery when it is disconnected if interception is not supported. Thanks for this and the preceding answers that I snipped. I'm not sure I find this model more compelling than the imperative equivalent, but okay. We can agree to disagree on which is more natural to web developers. I understand that your DataCache proposal provides different functionality to AppCache. I wasn't suggesting that they were equivalent. I am glad to see that you see a different set of functions offered in DataCache. Several commenters before you have taken the exact opposite position. I didn't interpret the other responses I read in that way but I may have mis-read them. I thought they were making a similar point to my next one. However, the AppCache as specified is getting implemented today (it is in Safari and Firefox with other implementations on the way). The problem I have is that I can't go implement AppCache and then add on some new methods and alternative interception-path to get DataCache- like features - I have to write a completely independent mechanism. If I propose that we build AppCache and then DataCache, someone will say, Hang on, didn't we just build this - why do we need two? OK. I get that. I also consider this to be an important challenge for everyone concerned. I thought I would write a concrete proposal. Oracle could help out with building a reference implementation for multiple browsers and make its source code available. What else can I do to help? I don't think the problem is that we couldn't build yet another cache that is similar but different to the AppCache that others are already shipping so I don't think a reference implementation is the solution. I think the problem is motivation - are there any use cases that adding DataCache enables that couldn't otherwise be implemented with what we already have and are those compelling enough to complicate the platform with another cache mechanism. Further, would we end up with conflicts between the AppCache and the DataCache since they're currently not unified as far as I can tell. While it might not be the perfect solution (we know the web far from ideal and is a lot of compromise), this type of proposal would be a lot more compelling to me if I could say This is what we have to add, this is how, and here are the use cases that make it valuable with a roadmap for extending what people are already building instead of something brand new. Would you mind explaining the last point with a roadmap for extending what people are already building instead of something brand new. for me? I would definitely strive to make the proposal more compelling. What I'm asking for is a more unified proposal that says If you have already implemented AppCache, here's what you add to make the same cache provide the additional functionality needed to enable these additional use cases. This will inevitably be a compromise from what a pure implementation looks like (your current DataCache spec, say) but lots of the web is necessarily a compromise because it builds on prior art that might not have been ideal but has been specified, built and deployed (and not always in that order). This would allow people to form a judgement about whether the additional use cases are worth the additional effort instead of whether the additional use cases are worth yet another cache. I think the ship has already sailed on AppCache and we can't undo that even if we wanted to and I don't think a competing solution is the right approach. Cheers, Adrian.
