Advice request on how to handle change in how Konqueror stores login information

[Stefano Crocco]

On domenica 22 settembre 2024 23:53:33 CEST Steven Robbins wrote:
> On Sunday, September 22, 2024 2:32:31 P.M. CDT Stefano Crocco wrote:
> > Thanks for your answer. If I understand correctly what you mean, I think I
> > was aiming for a solution with slightly different results than yours:
> > - what I wanted was I migration from old to new entries which would solve
> > all ambiguities. Referring to the example above, from the http://xyz.com#
> > entry, I wanted to determine whether it referred to the form f1 or to the
> > form f2 and to create either the http://xzy.com#f1 or the
> > http://xyz.com#f2
> > entry but not both
> 
> Oh -- so you are looking for a one-time migration of all entries?  If that's
> the case, I didn't understand it that way.

No, that's not what I meant. It would be nice if it could be done but it can't 
because we need access to each web page to migrate the corresponding entries. 
What can be done is migrating all entries corresponding to forms in a single 
web page. Since the ambiguity only concerns forms in the same page, I wanted 
to remove it.

> 
> > - what you are suggesting instead, is to keep the ambiguity  by creating
> > two entries with the new names, one for each form, having the same
> > contents. In the example, this would mean creating both the
> > http://xzy.com#f1 and the http://xzy.com#f2 entries. Is this correct?
> 
> I was building on the previous suggestion "Keep the old load code as a
> fallback to the new load code. You can drop the old save code, but the old
> load code probably has to be kept forever."
> 
> The way I understood that suggestion is that there is NOT a one-time
> migration.  Rather, the algorithm when encountering a page with forms is
> roughly:
> 
> 1. look up the new way - if entry found, then use it; else
> 2. look up the old way - if entry found, then
>    a) migrate to new storage
>    b) use data to fill form
> 
> So it would be a gradual migration.  If the data is found under the old
> scheme, then for migration (Step 2a) I would think you have enough info to
> build an unambiguous key for the new scheme? 

I certainly have the information to build the new keys, but sometimes (rarely) 
there's not enough information to associate the existing data with the correct 
key. If the old data is under the key http://xyz.com# and the page has two 
forms, with entries http://xyz.com#f1 and http://xyz.com#f2, what should I do 
with the existing entry? Rename it as http://xyz.com#f1? Rename it as
http://xyz.com#f2? Create two entries, http://xyz.com#f2 and http://xyz.com#f2 
with the same contents? The last one is what I thought you meant: it keeps the 
ambiguity because it doesn't attempt to decide which form the entry 
corresponds to but uses it for all of them, leaving it to the user to correct 
things. In many circumstances, there are ways to attempt to determine a single 
entry, but in some edge cases they could fail. This is why I thought that 
having the user start the process would be better.

> So  I don't think I'm
> suggesting to keep ambiguity by "creating two entries".  Rather, I was
> imagining nothing happens until the next time the user hits the page and
> THEN migrate.

This is correct.
> 
> I freely admit that I'm way out of my depth here.  ;-)
> 
> Regards,
> -Steve

Thanks for your suggestions.

Stefano