indexeddb and object store events
Asking my previous question again. There has been some discussions in www-tag list about IndexedDB API as an addition to discussion happening here. At www-tag, I was instructed to return back to this list with my question. There seems to be worry over IDB that it is too low level API and too complicated or verbose to use by someone not having degree in computer science. I do understand this worry, but at the same time I haven't seen any proper suggestions for better API than what we have and to be honest I'm quite happy with the current API. I don't feel it is too verbose especially when I see that the verbosity improves readability in this case. Only part that I feel could possibly be simplified is the use of transactions. Though I don't see any other solution for this than auto transactions and that kind of mechanism would probably have its own issues and would complicate implementation of IDB and I definitely don't want to see transactions going away. Other than that, I don't really think that the API requires much more simplifications and if it does, I don't really know how to do that. I think slightly harder lower level API at this point is much better than over simplified higher level API that limits use of too much. On top of lower level API you can write generic abstraction layers in Javascript, but not other way around. In the future version of the API we can then go back and see what kind of issues different abstractions are trying to solve and then add needed parts in the standard. But to the actual topic. As I raised earlier, main true problem with IDB is that I cannot listen changes in a object store. This does not feel that important when coming from SQL world, but after using other NoSQL databases and especially when thinking about rest of the web APIs, it doesn't make much sense not to have these events. WebStorage API defines this kind of mechanism and I feel it is quite odd that IDB does not. I have three quite clear use cases for this one that could be much simplified with these events: 1) I want to create synchronization library that is generic component providing IDB client to server sync. For example I have REST API for data in my service and I want to keep my clients in sync with the sevice over web sockets. To create this I need to wrap local modification requests to notify my library about the changes. In other words, I need to make my other components to know about this sync components, instead just including the component and telling which object stores to keep in sync and then this component could listen for new objects, modifications and deleted objects and notify service about these changes or it could just modify database when service notifies of change and my application component would see modification through object store events. 2) I want to create search component for so that I can index all words found in my objects. For example I create notes app where I want to index all words found in all notes and map those to my note objects. Then I want to use key range search for searching all notes that have words starting with my search term. This is a bit naïve example and it can be implemented by adding the code into my modification places, but again I would like to have generic component that does the indexing by listening these changes and then just include this library in my app. 3) I want to keep multiple windows in sync with changes in my objects. There are lots of approaches to have this, by using local storage as communication channel or create postMessage channel, but this is all just additional code that should not be needed in the first place and I need to hook my code that makes modifications to make these notifications instead just listening changes in my object store and hooking my HTML updates to these change events. To simplify implementation of these example cases, I would like to listen change events through object store so that I know when object is added, modified or deleted. I think these events should be launched right after transaction is completed. This raises some questions that how about order of these events or should we provide some kind of change chunk mechanism like for example CouchDB has when listening change notifications. At the first version, I wouldn't solve these issues. It should not matter in which order these events come as long as mid transaction changes are not notified. Add + put should be notiified as add, put + delete should be notified as delete, and multiple puts should be notified as single put showing the last state. Should we have multiple objects in one change, is a good question. So far I haven't got other feedback than this is fairly good idea and probably should be included in the official API, but is it stillpossible to get this kind of changes included in the API or am I too late with this request? If it is possible to have this change, is there anything I can do to help it getting forward? I'm working on reference
Re: indexeddb and object store events
I have read this complains to the API before and I have to admit that it doesn't seems difficult to me too, but the fact is that I'm studying a computers degree and also have worked before with AppEngine storage... :-P But I must to admit that the IndexedDB primitives are too primitives and would be nice to have more syntactic sugar and more high level functionality, like full-text search or object references or specially CRUD events. A query language like GQL would be also nice, and I think that the most of the complainst against IndexedDB are related to this topic, too much people is used to SQL and not so much to NoSQL and key-value object stores... 2013/2/17 Miko Nieminen miko.niemi...@iki.fi: Asking my previous question again. There has been some discussions in www-tag list about IndexedDB API as an addition to discussion happening here. At www-tag, I was instructed to return back to this list with my question. There seems to be worry over IDB that it is too low level API and too complicated or verbose to use by someone not having degree in computer science. I do understand this worry, but at the same time I haven't seen any proper suggestions for better API than what we have and to be honest I'm quite happy with the current API. I don't feel it is too verbose especially when I see that the verbosity improves readability in this case. Only part that I feel could possibly be simplified is the use of transactions. Though I don't see any other solution for this than auto transactions and that kind of mechanism would probably have its own issues and would complicate implementation of IDB and I definitely don't want to see transactions going away. Other than that, I don't really think that the API requires much more simplifications and if it does, I don't really know how to do that. I think slightly harder lower level API at this point is much better than over simplified higher level API that limits use of too much. On top of lower level API you can write generic abstraction layers in Javascript, but not other way around. In the future version of the API we can then go back and see what kind of issues different abstractions are trying to solve and then add needed parts in the standard. But to the actual topic. As I raised earlier, main true problem with IDB is that I cannot listen changes in a object store. This does not feel that important when coming from SQL world, but after using other NoSQL databases and especially when thinking about rest of the web APIs, it doesn't make much sense not to have these events. WebStorage API defines this kind of mechanism and I feel it is quite odd that IDB does not. I have three quite clear use cases for this one that could be much simplified with these events: 1) I want to create synchronization library that is generic component providing IDB client to server sync. For example I have REST API for data in my service and I want to keep my clients in sync with the sevice over web sockets. To create this I need to wrap local modification requests to notify my library about the changes. In other words, I need to make my other components to know about this sync components, instead just including the component and telling which object stores to keep in sync and then this component could listen for new objects, modifications and deleted objects and notify service about these changes or it could just modify database when service notifies of change and my application component would see modification through object store events. 2) I want to create search component for so that I can index all words found in my objects. For example I create notes app where I want to index all words found in all notes and map those to my note objects. Then I want to use key range search for searching all notes that have words starting with my search term. This is a bit naïve example and it can be implemented by adding the code into my modification places, but again I would like to have generic component that does the indexing by listening these changes and then just include this library in my app. 3) I want to keep multiple windows in sync with changes in my objects. There are lots of approaches to have this, by using local storage as communication channel or create postMessage channel, but this is all just additional code that should not be needed in the first place and I need to hook my code that makes modifications to make these notifications instead just listening changes in my object store and hooking my HTML updates to these change events. To simplify implementation of these example cases, I would like to listen change events through object store so that I know when object is added, modified or deleted. I think these events should be launched right after transaction is completed. This raises some questions that how about order of these events or should we provide some kind of change chunk mechanism like for example CouchDB
Re: Beacon API
On 16 February 2013 05:25, Maciej Stachowiak m...@apple.com wrote: BTW as far as I know the best current nonblocking technique to phone home on unload is to create an img in your unload handler pointing to the ping URL, this will result in reliable delivery without blocking at least in IE and WebKit-based browsers. I've found it hard to convince even knowledgable web developers to use this technique or a ping over synchronous XHR, even sites that are otherwise willing to do Safari-specific optimizations. I am not sure why sync XHR in unload is so tantalizing. I asked Phillip Tellis (creater of Boomerang) about this and his experience is: (copied because he can't post to the list) A beacon may be sent using a GET request via an Image object in a listener for either the onunload,the onbeforeunload or the onpagehide events. No browser blocks if this is sent via the onbeforeunload event, however Opera does not support this event. Firefox is the only browser that blocks for Image requests in the onunload event. Additionally, attaching a listener to the onunload event affects Page Cache in most browsers, so one should avoid that in any event. The solution we've come up with for boomerang (a general purpose beaconing solution primarily used for web performance beacons) is to attach a listener to the beforeunload event and either the pagehide or unload, depending on which is available (pagehide is checked first). The first of these events to fire sends the beacon out and removes the listener from the other. This has allowed us to fire beacons on every page unload without affecting unload time and without beacon loss. Andy
