[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)? On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarkshttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/bookmarks-api - Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? - Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? - In BookmarkItem, should fields that don't apply be null or simply not present? - In BookmarksQuery, do the root and bookmarksBar booleans make sense? - How does returning the children recursively work with updates? Can you update all these items at the same time? Downloadshttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/downloads-api - Should getDownloads take a DownloadsQuery object? The current downloads page includes search. - What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? - How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. Historyhttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/history-api - I'm assuming HistoryItems are immutable, so there is no update. - The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? - There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? I would recommend doing as little as possible for history. I worked on a fancy querying system for Firefox history which has not really been used for great effect. We should add features as necessary for things we want to enable. The visits and URLs are split out for space reasons. The URL record has a couple of strings and a bunch of numbers, and the results will contain many copies of the URL (for example, imagine the URL, favicon URL, and title (many common titles are actually quite long) for your homepage being duplicated hundreds of times for a longish history query. If the results are limited to 100, space doesn't matter, but splitting them makes some things easier. Say I want to display only URLs, it keeps me from having to go through every one and uniquing them. So I guess either way is OK with me. I like the idea of limiting the result set to 100. It's too easy to shoot yourself in the foot. I also think you should not be able to do a query over too much time. For full text search results, we've spent a lot of time doing these in chunks. Doing a search for something over all time can easily churn through hundreds of megabytes of data. Our history code does it incrementally by month, so I think this would be a good thing to encourage in the API design that you can't do a query over more than one month. int timeSpent: we don't know the time you spent on the page, so remove this. optional int[] ids: I don't understand what this is. int totalPages: I assume you mean the total number of result sets of 100? This number is not possible for us to compute for queries with full text searches, and is merely very impractical for other ones. optional int page: We can not efficiently do full text queries by count give me the 30-40th results since it must find every match for the text before it can do any such computation. Given my suggestion to keep it simple, I think the query API should more closely reflect the current C++ API, which was carefully designed to be efficient. Instead of asking for individual pages, you do a query over a time range for up to 100 results. If you want more results, you start at the last date and continue to go back in time, getting more results. This requires some more work by extension authors, but not a lot more. If we see there are many applications with certain needs, we should design better APIs for those specific needs. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele t...@chromium.org wrote: Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)? The question applies to every object in the system (every object could disappear or change in an incompatible way while you hold it). My current thinking for this particular case is that the most reasonable thing to do is to drop the update on the floor and write an error to the console. There are two ways a developer can get here: * He received a remove event for an ID, but ignored it, then sent an update. That is his fault, error makes sense. * There was an actual race. The ID was valid when he sent it but got removed while in flight. I think this will be vanishingly rare in real life. Any API we add for it will not get tested. Printing the error to the console in this case is unfortunate because it isn't really an error on the developer's part, but if we have enough people writing extensions that somebody legitimately sees this case, I will be stoked :). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
Very nice, according to bookmarks, it would be nice to have showInShelf(bool) or something like that. Can we have helper classes such as moving the bookmarks around? Since the tree storage algorithm is there, would be nice to just use it instead of implementing it ourselves. On Thu, Apr 9, 2009 at 3:53 AM, Aaron Boodman a...@chromium.org wrote: On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele t...@chromium.org wrote: Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)? The question applies to every object in the system (every object could disappear or change in an incompatible way while you hold it). My current thinking for this particular case is that the most reasonable thing to do is to drop the update on the floor and write an error to the console. There are two ways a developer can get here: * He received a remove event for an ID, but ignored it, then sent an update. That is his fault, error makes sense. * There was an actual race. The ID was valid when he sent it but got removed while in flight. I think this will be vanishingly rare in real life. Any API we add for it will not get tested. Printing the error to the console in this case is unfortunate because it isn't really an error on the developer's part, but if we have enough people writing extensions that somebody legitimately sees this case, I will be stoked :). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
(Resend - ugh) On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman a...@chromium.org wrote: Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? This is a meta question for the entire system. My current thinking is that changes you make should not fire events back at you. That just seems annoying. I think there should also be defined behavior in cases where something you do will obviously affect other nodes, and that those changes shouldn't be fired at you either. Agree in principle. The callback within the CRUD method should handle this. I'd argue that all of the methods should have callbacks for this reason (as well as error handling). For example, moving a bookmark item within the folder obviously affects some of the other nodes. We should have a defined behavior for what happens when you do this, and we shouldn't fire events back at you for any of those changes. This is a bit tricky though since we need to distinguish between the calling extension and other extensions. Let's say you had two extensions that hooked into bookmarks API (one was an alternate UI and one was a backend sync tool). Other stuff * I camel cased the events (in all the APIs) :-) It looks like you missed history. I just updated it. * I added letters to the left of all the properties in each struct of each API. There is 'r', 'w', and 'c', which refer to read, write, and create. This determines whether it is valid to include this property in each of these scenarios. So for example, it doesn't make sense to create a bookmark with a predefined API. There will be other validation we have to do on top of this. Like it doesn't make sense to change a bookmark to a folder, but this handles a good percentage. For createDownload, don't more of the Download fields need create rights (path, url, etc.)? What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? See previous point about events. I'm meh about the need for clearAllDownloads(). Take it or leave it. I think we need it for privacy folks. We generally need the clear APIs for all of our data so that someone can implement the extensions that periodically delete everything. Other stuff: * I added two booleans: showInShelf and showInDownloadUI. What's the distinction between the two? Is the second supposed to be download history? I modified the signature of the getHistory callback to make it more consistent with the other APIs. Instead of returning the number of pages, I think it is more useful to return the total number of items. Also I don't think we need to return the page number since the caller already has that. It looks like this change didn't get committed (or got clobbered by someone). Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
[resending from right email...] On Thu, Apr 9, 2009 at 12:53 AM, Aaron Boodman a...@chromium.org wrote: On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele t...@chromium.org wrote: Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)? The question applies to every object in the system (every object could disappear or change in an incompatible way while you hold it). True. I hadn't looked closely at the other APIs before raising that and was assuming they were mostly immutable :) I see that's not the case. Still, I think realistically updating a bookmark is most common. My current thinking for this particular case is that the most reasonable thing to do is to drop the update on the floor and write an error to the console. There are two ways a developer can get here: * He received a remove event for an ID, but ignored it, then sent an update. That is his fault, error makes sense. * There was an actual race. The ID was valid when he sent it but got removed while in flight. I think this will be vanishingly rare in real life. Any API we add for it will not get tested. Printing the error to the console in this case is unfortunate because it isn't really an error on the developer's part, but if we have enough people writing extensions that somebody legitimately sees this case, I will be stoked :). IAWTP. But I can think of some extensions people will write where this will pop up. If you're trying to send bookmarks over the wire to, say, another instance of the same extension somewhere in the cloud via a service, the window of FAIL opens up. There are recourses the extension can take in most every case, but as I know you already know from past experiences with this wonderful hellpit it'll be really hard / impossible to just _verify_ that two endpoints have the same data let alone keep things in a consistent state. I don't have a simple way to improve this though and I agree we shouldn't overcomplicate things here for the minority. Doesn't solve everything, but maybe provide some programmatical why info to the extension when we fail / drop write operations. It could be as simple as having the callback parameter type having an extra success boolean. That is a slippery slope though given the different ways things can succeed/fail. Anyway, just mentioning! - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Thu, Apr 9, 2009 at 10:28 AM, Erik Kay erik...@google.com wrote: On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman a...@chromium.org wrote: Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? This is a meta question for the entire system. My current thinking is that changes you make should not fire events back at you. That just seems annoying. I think there should also be defined behavior in cases where something you do will obviously affect other nodes, and that those changes shouldn't be fired at you either. Agree in principle. The callback within the CRUD method should handle this. I'd argue that all of the methods should have callbacks for this reason (as well as error handling). All the methods do currently have a callback ... and they all should have an errback too. But I'm arguing that for expected reorganizations of related nodes, we shouldn't send back information about what happened. I'm not really sure how this will work in real life, I need to play with it. It's a first stake in the ground. For example, moving a bookmark item within the folder obviously affects some of the other nodes. We should have a defined behavior for what happens when you do this, and we shouldn't fire events back at you for any of those changes. This is a bit tricky though since we need to distinguish between the calling extension and other extensions. Let's say you had two extensions that hooked into bookmarks API (one was an alternate UI and one was a backend sync tool). We have that state in the current implementation, we can make this distinction. Other stuff * I camel cased the events (in all the APIs) :-) It looks like you missed history. I just updated it. Thanks. * I added letters to the left of all the properties in each struct of each API. There is 'r', 'w', and 'c', which refer to read, write, and create. This determines whether it is valid to include this property in each of these scenarios. So for example, it doesn't make sense to create a bookmark with a predefined API. There will be other validation we have to do on top of this. Like it doesn't make sense to change a bookmark to a folder, but this handles a good percentage. For createDownload, don't more of the Download fields need create rights (path, url, etc.)? Oh yeah, url, duh. I fixed that. I'm not sure about path though. To me, the download system is about getting stuff onto the system. Moving things around in the file system is a different (more complicated) API. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? See previous point about events. I'm meh about the need for clearAllDownloads(). Take it or leave it. I think we need it for privacy folks. We generally need the clear APIs for all of our data so that someone can implement the extensions that periodically delete everything. My point is that you can implement clearAll by fetching all ids and calling remove in a loop. I guess having a clearAll is slightly more convenient, but ... meh :) Other stuff: * I added two booleans: showInShelf and showInDownloadUI. What's the distinction between the two? Is the second supposed to be download history? Yes, download history. Idea is that somebody might want to download something in their extension and open it for the user, but it really isn't a download in the sense of the things that show up in that UI. I modified the signature of the getHistory callback to make it more consistent with the other APIs. Instead of returning the number of pages, I think it is more useful to return the total number of items. Also I don't think we need to return the page number since the caller already has that. It looks like this change didn't get committed (or got clobbered by someone). Whoops, I forgot to press save. I also removed timeSpent per brett's feedback. I didn't do anything about brett's other feedback because I need to get more clarification (it appears that chrome's UI currently does page-based results, even for text queries). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
Moving a bookmark should be as simple as changing it's parentId. -Nick On Thu, Apr 9, 2009 at 5:01 AM, Mohamed Mansour m0.interact...@gmail.comwrote: Very nice, according to bookmarks, it would be nice to have showInShelf(bool) or something like that. Can we have helper classes such as moving the bookmarks around? Since the tree storage algorithm is there, would be nice to just use it instead of implementing it ourselves. On Thu, Apr 9, 2009 at 3:53 AM, Aaron Boodman a...@chromium.org wrote: On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele t...@chromium.org wrote: Nice stuff. I think this question primarily applies to bookmarks, but how does the API deal with keeping states consistent? By the time a getBookmarks callback or an event reaches the listener (in a separate process), the bookmarks referred to may have changed or been removed already; even while the listener is processing the event itself. E.g something like updateBookmark would need to handle this at least minimally; if you update a bookmark that has been deleted, do we recreate it and encode that in a BookmarkInfo somehow, or should the API callback with a null BookmarkInfo (may be tough to do correctly at the right times)? The question applies to every object in the system (every object could disappear or change in an incompatible way while you hold it). My current thinking for this particular case is that the most reasonable thing to do is to drop the update on the floor and write an error to the console. There are two ways a developer can get here: * He received a remove event for an ID, but ignored it, then sent an update. That is his fault, error makes sense. * There was an actual race. The ID was valid when he sent it but got removed while in flight. I think this will be vanishingly rare in real life. Any API we add for it will not get tested. Printing the error to the console in this case is unfortunate because it isn't really an error on the developer's part, but if we have enough people writing extensions that somebody legitimately sees this case, I will be stoked :). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
Does the other bookmarks node need special handling like the Bookmarks Bar? Since the title of this permanent node is an internationalized string, there needs to be another way to identify it. Note that in our existing BookmarkModel, the other bookmarks node is not a child of the bookmark node, but a sibling -- though this does not mean we can't aspire to expose it in some other way. Using a (parentid,index) tuple to communicate position changes in an asynchronous interface leads to funkiness, because an move X to index 0 operation requires sending bookmarkUpdated notifications for every subsequent item in the sibling ordering whose index gets incremented. If single-item moves are going to result in O(#siblings) updates anyway, we might prefer to just communicate positions as a list IDs or items, bound to the parent. In other words, to allow the |children| array to be the one and only way to read and write position, and drop the redundant reflection onto a (parentid, index) tuple. - nick On Thu, Apr 9, 2009 at 12:16 PM, Nick Carter ncar...@google.com wrote: Does the other bookmarks node need special handling like the Bookmarks Bar? Since the title of this permanent node is an internationalized string, there needs to be another way to identify it. Note that in our existing BookmarkModel, the other bookmarks node is not a child of the bookmark node, but a sibling -- though this does not mean we can't aspire to expose it in some other way. Using a (parentid,index) tuple to communicate position changes in an asynchronous interface leads to funkiness, because an move X to index 0 operation requires sending bookmarkUpdated notifications for every subsequent item in the sibling ordering whose index gets incremented. If single-item moves are going to result in O(#siblings) updates anyway, we might prefer to just communicate positions as a list IDs or items, bound to the parent. In other words, to allow the |children| array to be the one and only way to read and write position, and drop the redundant reflection onto a (parentid, index) tuple. - nick On Thu, Apr 9, 2009 at 11:55 AM, Nick Baum nickb...@chromium.org wrote: On Thu, Apr 9, 2009 at 11:22 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 10:28 AM, Erik Kay erik...@google.com wrote: On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman a...@chromium.org wrote: Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? This is a meta question for the entire system. My current thinking is that changes you make should not fire events back at you. That just seems annoying. I think there should also be defined behavior in cases where something you do will obviously affect other nodes, and that those changes shouldn't be fired at you either. Agree in principle. The callback within the CRUD method should handle this. I'd argue that all of the methods should have callbacks for this reason (as well as error handling). All the methods do currently have a callback ... and they all should have an errback too. But I'm arguing that for expected reorganizations of related nodes, we shouldn't send back information about what happened. I'm not really sure how this will work in real life, I need to play with it. It's a first stake in the ground. So if a bookmark gets added to a folder: - we should send an update event for the bookmark - but we should NOT send an update event for that folder Is that right? For example, moving a bookmark item within the folder obviously affects some of the other nodes. We should have a defined behavior for what happens when you do this, and we shouldn't fire events back at you for any of those changes. This is a bit tricky though since we need to distinguish between the calling extension and other extensions. Let's say you had two extensions that hooked into bookmarks API (one was an alternate UI and one was a backend sync tool). We have that state in the current implementation, we can make this distinction. Other stuff * I camel cased the events (in all the APIs) :-) It looks like you missed history. I just updated it. Thanks. * I added letters to the left of all the properties in each struct of each API. There is 'r', 'w', and 'c', which refer to read, write, and create. This determines whether it is valid to include this property in each of these scenarios. So for example, it doesn't make sense to create a bookmark with a predefined API. There will be other validation we have to do on top of this. Like it doesn't make sense to change a bookmark to a folder, but this handles a good percentage. For createDownload, don't more of the Download fields need create rights (path, url, etc.)? Oh yeah, url, duh. I fixed that. I'm not sure about path though. To me, the download system is about getting stuff onto the system. Moving
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
There's one other bookmark notification you don't have, BookmarkNodeMoved. Other interesting bookmark related methods: GetBookmarks(URL) GetMostRecentlyModifiedGroups GetMostRecentlyAddedEntries If you want to enable folks to replace the ntp, then shouldn't you provide a way to get the items displayed by the ntp? If someone is writing their own history sniffer or history page replacement that'll need to know when a new visit is added. -Scott On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
Well that begs the question: if the folder gets updated, what about the folder it's contained in? Is it updates all the way up? I think it'd be simpler to not send updates for the folders when the bookmarks change. -Nick On Thu, Apr 9, 2009 at 11:58 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 11:55 AM, Nick Baum nickb...@chromium.org wrote: So if a bookmark gets added to a folder: we should send an update event for the bookmark but we should NOT send an update event for that folder We would send events about both things to all extensions except the one that caused it. That was the idea anyway. Agree with Erik that it might be tricky to implement. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Thu, Apr 9, 2009 at 12:41 PM, Scott Violet s...@chromium.org wrote: There's one other bookmark notification you don't have, BookmarkNodeMoved. A bookmark update when the parentID changes should cover this. Other interesting bookmark related methods: GetBookmarks(URL) GetMostRecentlyModifiedGroups GetMostRecentlyAddedEntries Hmm, these could be query properties I suppose. This seems like a nice-to-have. If you want to enable folks to replace the ntp, then shouldn't you provide a way to get the items displayed by the ntp? If someone is writing their own history sniffer or history page replacement that'll need to know when a new visit is added. We do have events for that, I believe. event onHistoryItemCreated(HistoryItem new) -Scott On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Thu, Apr 9, 2009 at 1:29 PM, Nick Baum nickb...@chromium.org wrote: Well that begs the question: if the folder gets updated, what about the folder it's contained in? Is it updates all the way up? I think it'd be simpler to not send updates for the folders when the bookmarks change. Why would adding a bookmark to a folder send an update event about the folder's parent? That doesn't make sense to me. I do think Nick Carter has an interesting point about modifying order by resending the entire list. It does seem like it could be simpler. I don't know how to fit that into this API though. It seems like you'd need a separate function for reordering children objects. Maybe that is OK. Hmm. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Thu, Apr 9, 2009 at 12:17 PM, Nick Carter n...@chromium.org wrote: Does the other bookmarks node need special handling like the Bookmarks Bar? Since the title of this permanent node is an internationalized string, there needs to be another way to identify it. Note that in our existing BookmarkModel, the other bookmarks node is not a child of the bookmark node, but a sibling -- though this does not mean we can't aspire to expose it in some other way. the isBookmarksBar boolean should handle this. If it's false, then it must be Other Bookmarks. Using a (parentid,index) tuple to communicate position changes in an asynchronous interface leads to funkiness, because an move X to index 0 operation requires sending bookmarkUpdated notifications for every subsequent item in the sibling ordering whose index gets incremented. If single-item moves are going to result in O(#siblings) updates anyway, we might prefer to just communicate positions as a list IDs or items, bound to the parent. In other words, to allow the |children| array to be the one and only way to read and write position, and drop the redundant reflection onto a (parentid, index) tuple. - nick On Thu, Apr 9, 2009 at 12:16 PM, Nick Carter ncar...@google.com wrote: Does the other bookmarks node need special handling like the Bookmarks Bar? Since the title of this permanent node is an internationalized string, there needs to be another way to identify it. Note that in our existing BookmarkModel, the other bookmarks node is not a child of the bookmark node, but a sibling -- though this does not mean we can't aspire to expose it in some other way. Using a (parentid,index) tuple to communicate position changes in an asynchronous interface leads to funkiness, because an move X to index 0 operation requires sending bookmarkUpdated notifications for every subsequent item in the sibling ordering whose index gets incremented. If single-item moves are going to result in O(#siblings) updates anyway, we might prefer to just communicate positions as a list IDs or items, bound to the parent. In other words, to allow the |children| array to be the one and only way to read and write position, and drop the redundant reflection onto a (parentid, index) tuple. - nick On Thu, Apr 9, 2009 at 11:55 AM, Nick Baum nickb...@chromium.org wrote: On Thu, Apr 9, 2009 at 11:22 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 10:28 AM, Erik Kay erik...@google.com wrote: On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman a...@chromium.org wrote: Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? This is a meta question for the entire system. My current thinking is that changes you make should not fire events back at you. That just seems annoying. I think there should also be defined behavior in cases where something you do will obviously affect other nodes, and that those changes shouldn't be fired at you either. Agree in principle. The callback within the CRUD method should handle this. I'd argue that all of the methods should have callbacks for this reason (as well as error handling). All the methods do currently have a callback ... and they all should have an errback too. But I'm arguing that for expected reorganizations of related nodes, we shouldn't send back information about what happened. I'm not really sure how this will work in real life, I need to play with it. It's a first stake in the ground. So if a bookmark gets added to a folder: - we should send an update event for the bookmark - but we should NOT send an update event for that folder Is that right? For example, moving a bookmark item within the folder obviously affects some of the other nodes. We should have a defined behavior for what happens when you do this, and we shouldn't fire events back at you for any of those changes. This is a bit tricky though since we need to distinguish between the calling extension and other extensions. Let's say you had two extensions that hooked into bookmarks API (one was an alternate UI and one was a backend sync tool). We have that state in the current implementation, we can make this distinction. Other stuff * I camel cased the events (in all the APIs) :-) It looks like you missed history. I just updated it. Thanks. * I added letters to the left of all the properties in each struct of each API. There is 'r', 'w', and 'c', which refer to read, write, and create. This determines whether it is valid to include this property in each of these scenarios. So for example, it doesn't make sense to create a bookmark with a predefined API. There will be other validation we have to do on top of this. Like it doesn't make sense to change a bookmark to a folder, but this handles a good percentage. For createDownload, don't more of the Download
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
If you want to enable folks to replace the ntp, then shouldn't you provide a way to get the items displayed by the ntp? If someone is writing their own history sniffer or history page replacement that'll need to know when a new visit is added. We do have events for that, I believe. event onHistoryItemCreated(HistoryItem new) Will revisiting a URL still invoke this? I get in that case it's not a create, rather an update. But ok, as long as the functionality is there. -Scott -Scott On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
For downloads, do we provide a way for people to download a file without showing a UI? It'd be interesting to do that and give people the ability to register for callbacks. That might be useful for custom download manager extensions... what I mean by that are extensions that fetch every link on the page, every bit of media etc. They sometimes provide their own UI better suited to mass file downloading than our shelf. -Ben On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
