[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: release builders now run webkit tests in parallel
Thanks to Ojan for this, the release testers are considerably faster now. As for debug, while we wait for this change to take effect there too, I added some more hardware. Windows, Mac and Linux are now running the webkit dbg layout tests in parallel on 3 machines each. Nicolas On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Lots of IPC errors this morning
I sync'd my tree this morning and all i have to do is click a page off NTP to get a stream of: [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found errors. Things aren't really happy. Anyone touching stuff that might be IPC related yesterday? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
fyi -Some failures will happen on the Macs because test_shell sets/restores user settings on startup/shutdown, so having more then one running can cause things to fail as one exits changing state on another that's running. It's on my list to move into a helper app so it can be done around the whole setup instead, it just hasn't bubble up in the priority list yet. TVL On Thu, Apr 9, 2009 at 12:06 PM, Pam Greene p...@chromium.org wrote: On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
This would only affect pixel tests, which are still off by default on mac, right? On Thu, Apr 9, 2009 at 9:11 AM, Thomas Van Lenten thoma...@chromium.orgwrote: fyi -Some failures will happen on the Macs because test_shell sets/restores user settings on startup/shutdown, so having more then one running can cause things to fail as one exits changing state on another that's running. It's on my list to move into a helper app so it can be done around the whole setup instead, it just hasn't bubble up in the priority list yet. TVL On Thu, Apr 9, 2009 at 12:06 PM, Pam Greene p...@chromium.org wrote: On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: [linux] packagers for distros? (Debian, Fedora, Gentoo, etc.)
On Mon, Apr 6, 2009 at 1:45 PM, Evan Martin e...@chromium.org wrote: Is anyone working on official distro packages (rpms, ebuilds, etc.) for Chromium? It'd be nice to hear from you -- occasionally there are issues of interest to packagers and so far we've only been talking with Ubuntu, since they're all we've heard from. Well, for future reference here's what I do know: - Ubuntu: https://launchpad.net/chromium-project - Debian: there was an ITP three weeks ago, and one of the Ubuntu guys reached out to them: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520324 - I was unable to find anything related to RPM (RedHat, SuSe, CentOS etc.) - Arch: http://aur.archlinux.org/packages.php?ID=24266 (just unpacks the Ubuntu builds) - Gentoo: PuffTheMagic on IRC was talking about working on it - And there was at least a thread of people trying on Slackware. :P https://www.linuxquestions.org/questions/slackware-14/build-chrome-on-slackware-current-fail-no-package-nss-found-667546/ --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
On Thu, Apr 9, 2009 at 9:06 AM, Pam Greene p...@chromium.org wrote: On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. I've filed http://crbug.com/9910 for this. It would be great if someone took this on, even if you just worked out a few flaky tests and then passed it off to someone else. Also, another bug that someone could take on that doesn't require significant programming knowledge is to make the webkit tests runnable on Vista. It's a lot easier to get a quad-core Vista machine than an XP one here, so we can run the tests a ton faster on Vista. This is http://crbug.com/6131. This also would help all the people who currently build on Vista and need to run the tests on XP. Ojan --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
On Thu, Apr 9, 2009 at 12:37 PM, Ojan Vafai o...@google.com wrote: This would only affect pixel tests, which are still off by default on mac, right? It also includes prefs about font sizes, smoothing, etc, which has shown in the past to change the layout and hence the text dumps. TVL On Thu, Apr 9, 2009 at 9:11 AM, Thomas Van Lenten thoma...@chromium.orgwrote: fyi -Some failures will happen on the Macs because test_shell sets/restores user settings on startup/shutdown, so having more then one running can cause things to fail as one exits changing state on another that's running. It's on my list to move into a helper app so it can be done around the whole setup instead, it just hasn't bubble up in the priority list yet. TVL On Thu, Apr 9, 2009 at 12:06 PM, Pam Greene p...@chromium.org wrote: On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: Open discussions on the api-pattern
On Wed, Apr 8, 2009 at 7:11 PM, Aaron Boodman a...@chromium.org wrote: Argh, resending from right adress this time. On Wed, Apr 8, 2009 at 7:10 PM, Aaron Boodman a...@chromium.org wrote: Thanks for forking this. I had started a reply, then forgot to send it. On Wed, Apr 8, 2009 at 4:57 PM, Nick Baum nickb...@chromium.org wrote: [forking the Basic how-to steps thread] I was rereading this, and it seems this wasn't completely resolved. I've summarized the various topics: Syntax It feels like Erik has a somewhat different syntax in mind (still service based, but a little more OO). I think the most useful thing at this point would be for Erik to give an example of what he proposes so we can compare the two. Yes, agree counterproposals would be easier to digest. From what I understand of the save() proposal, it doesn't seem to provide much value. You get to say foo.save() instead of chromium.foos.updateFoo(foo). I guess it's less typing, but if all the other functions to get, delete, and create foo objects are on chromium.foos, I don't see why it's valuable to have the update function not be there. There are other advantages to chorium.foos.updateFoo(). It can easily be modified to accept multiple foo instances. This could be useful if we need to make sure that a bunch of updates happen without repaints between. Updates I like Erik's suggestion of keeping change bits, it's clever and transparent to the developer. For update events, do we only send the ID and the fields that have changed? I can see it being useful to have the whole object, but that makes figuring out the changes tricky. Maybe we send all fields in the new object, but only the changed fields in the old object. That makes it easy to find out which ones have changed, while still giving you the whole object. The change bit idea is interesting. I'm not sure exactly what Erik had in mind for how it would work, but I can imagine a few ways: a) Use javascript prototypes. When you call getThing(), you get back an empty object whose __proto__ is the actual object with its fields filled in. But when you mutate your thing instance, your writes get saved on the empty object. That way if you try to save it again, we can tell the difference. b) __defineSetter__. We'd intercept writes to fields and save a modified bit somewhere. I think a) is better. If we find that this is a common problem, we could try it out. I'd rather get more APIs built out in the dead-simple JSON style though before going deeper on the API infrastructure. Camel-case I've seen arguments both ways. I like camelcase better because it's more legible, but don't feel strongly about. I'm convinced we should change it back to camel case. And I also agree we should avoid DOM event names if possible. Tabs windows Another difference between tabs and windows is that tabs have prev/next history that we should let developers navigate. To me they seem separate enough to be worth separating to not get three dozen functions in one package, but I don't feel strongly about this. I might sketch out what they'd look like if separate. Sure, let's try them separated for awhile. Ok, I'll take a stab at spec'ing this up. -Nick Self vs extension Is this just a naming issue? Have we decided? I'll rename the property in content scripts called 'self' to 'parentExtension'. - 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: Lots of IPC errors this morning
FYI: This was resolved earlier this morning. I guess I got unlucky and sync'd at a bad time. It was an issue with the devtools_agent_filter. On Thu, Apr 9, 2009 at 11:24 AM, Mike Pinkerton pinker...@chromium.org wrote: I sync'd my tree this morning and all i have to do is click a page off NTP to get a stream of: [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found errors. Things aren't really happy. Anyone touching stuff that might be IPC related yesterday? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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] Area-DevTools Deprecated
Given that we have developer tools like the debugger that are intended for web developers there is some confusion over the Area-DevTools label. We have replaced that with Area-Infrastructure. This area is for things related to the internal systems like buildbots, tests, etc. There is a new label for external developer tools. It is not an Area. The proper Area for the debugger and other tools for web developers is Area-WebKit. The new label is... DevTools. Jon --~--~-~--~~~---~--~~ 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] gclient now supports safesync URLs
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
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: Microsoft symbol proxy can't retrieve debug symbols
After a bit of digging and coding I have a working workaround for the problem. Read about it here: http://blog.insanegenius.com/2009/04/broken-symbol-proxy.html --~--~-~--~~~---~--~~ 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: gclient now supports safesync URLs
Does this use the latest version that works on windows, linux and mac? ...
or, only windows?
-Darin
On Thu, Apr 9, 2009 at 4:45 PM, Alex Russell slightly...@google.com wrote:
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
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: gclient now supports safesync URLs
Not sure what our build-bots report. M-A?
Regards
On Thu, Apr 9, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote:
Does this use the latest version that works on windows, linux and mac? ...
or, only windows?
-Darin
On Thu, Apr 9, 2009 at 4:45 PM, Alex Russell slightly...@google.com wrote:
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
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: gclient now supports safesync URLs
Would http://build.chromium.org/buildbot/continuous/LATEST/REVISION work
here as well?
On Thu, Apr 9, 2009 at 5:29 PM, Alex Russell slightly...@google.com wrote:
Not sure what our build-bots report. M-A?
Regards
On Thu, Apr 9, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote:
Does this use the latest version that works on windows, linux and mac?
...
or, only windows?
-Darin
On Thu, Apr 9, 2009 at 4:45 PM, Alex Russell slightly...@google.com
wrote:
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
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: gclient now supports safesync URLs
I think it contains the last revision that compiles on mac, linux and
windows and also that passed the unit_tests on these 3 platforms.
Nicolas
On Thu, Apr 9, 2009 at 5:29 PM, Alex Russell slightly...@google.com wrote:
Not sure what our build-bots report. M-A?
Regards
On Thu, Apr 9, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote:
Does this use the latest version that works on windows, linux and mac?
...
or, only windows?
-Darin
On Thu, Apr 9, 2009 at 4:45 PM, Alex Russell slightly...@google.com
wrote:
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
