Redoing Undo?

[Marco Bonardo]

On Thu, Oct 27, 2016 at 6:08 PM, Perry Wagle <wagle at mac.com> wrote:

> 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).
>

If you use the official Places API there's no problem with Sync, we take
care of everything. And if there are deficiencies in the API, we can look
into them. The API is anything exposed "officially" by .jsm and .idl files.
But having something external writing to the Places database is  the
perfect recipe for disasters, and a no-go. 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.

I have a complex vision of what I want rollbacks to do.  Including in a
>> parallel environment.  To solidify that vision, I need to see what I can do
>> with the actual code, and to find out what other people need and want.  One
>> thing is that I want to know what an rollback is going to do before I do it.
>>
>
> It is technically possible to associate a string to each transaction, but
> that introduces localization problems that we never resolved, cause the
> undo/redo label should be localized and it's in a menupopup so it shouldn't
> grow too much and all those small edge problems.
>
>
> Ah.  Localization.  Seems tedious but doable.  How many languages do you
> translate to now?
>

70 or such. But clearly you don't have to provide all those locales, you
must code in support for localizers to do their job (use entities or
properties, properly use PluralForm.jsm and so on, there's a page on MDN
about that).


> 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.
>

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.

3) is https://bugzilla.mozilla.org/show_bug.cgi?id=451310. I'd have nothing
> against fixing this, provided localization can be done properly. The other
> problem is that, as I said, we are in a no-so-nice code situation at the
> moment cause we have 2 parallel codebases and both will have to be updated.
> I hope we can restart work on the async transaction manager and finally
> remove the old one in the near future.
>
>
> Where are the two codebases?  I’m aware of only the one.
>

It's what I said above about synchronous and asynchronous Places
transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161028/67e781b1/attachment.html>