<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 28, 2016, at 1:44 AM, Marco Bonardo <<a href="mailto:mbonardo@mozilla.com" class="">mbonardo@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 27, 2016 at 6:08 PM, Perry Wagle <span dir="ltr" class=""><<a href="mailto:wagle@mac.com" target="_blank" class="">wagle@mac.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><div class=""></div></span>What bugs/documentation should I look at? Interacting well with sync seems the main problem (after conversation with Richard). I eventually want a third process (a tightly coupled personal wiki) reading/writing to the places database, so that all needs to get solved (by me, presumably, since I’m the one with the itch).</div></div></blockquote><div class=""><br class=""></div><div class="">If you use the official Places API there's no problem with Sync, we take care of everything.</div></div></div></div></div></blockquote><div><br class=""></div>According to a sync person, sync just transacts really fast to the places database and hopes for the best.</div><div><br class=""></div><div>I want to do better than that. I think the problem is really hard, possibly unsolved (?). I will have the tools to pull it off in 2 years, but I have only 5 months before my capability to <i class="">produce</i> that programming environment goes away unless I get something going by then.</div><div><br class=""></div><div>And, it must be solved in this future of parallelism.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> And if there are deficiencies in the API, we can look into them. The API is anything exposed "officially" by .jsm and .idl files.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div>I’m currently building a list of program-and-documentation readings and constraints. Which .jsm and .idl files? (or should I figure that out?)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">But having something external writing to the Places database is the perfect recipe for disasters, and a no-go.</div></div></div></div></div></blockquote><div><br class=""></div>It shouldn’t be this way. I’m trying to modify the implementation of places to make it easier to modify the implementation of places, so that progress can be made.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> The only thing writing to Places should be Places, cause it's the only one knowing how to handle Sync needs, triggers, expiration and such things. It's far more complex than it looks just by opening the db, cause we have requirements regarding privacy and Sync. I'd say there's 90% probability an external writer would do the wrong thing.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div>I think I want to break the places subsystem into pieces, and, in particular, to have a places database API (and protocol?). The current places subsystem would use it. My “tightly coupled wiki” would use it. I would do all that myself, unless someone wants to help. When I’m done with where-ever this leads, you will get something much easier to modify.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""></span></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I figured the UX team considered themselves “done”, and it was my itch to scratch to get the underlying support for my itches to work first, then approach them with a solution looking for a UX. But I can’t talk to them intelligently before I know what I can do.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm not surw what you mean by "done", but UX isn't done at all in the bookmarks & history world, and things are very likely to change in the coming months. <br class=""></div></div></div></div></div></blockquote><div><br class=""></div>A UX guy told me that they were done for the moment, and that I should watch bugzilla for changes to that. Unfortunately, given the brevity with how people communicate in there, its like looking for invisible needles in a very large haystack. I would like to know what’s happening insofar as to avoid getting stomped on, and to avoid stomping on others.</div><div><br class=""></div><div><br class=""></div><div>PS. My goal is to produce the programming environment that would permit me to make making changes to large codebases much easier in general. A key part of that environment is the organizer/planner that I have cobbled up in ESR45. It needs to be greatly improved. ESR45 goes away in March 2017. I can’t program at all without externalizing my memory in this fashion so I must have a solution by then. Other people do the same — I’m not alone in this need. See the “Get Things Done” book for an example of this.</div></body></html>