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

[Steven Robbins]

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.

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

I freely admit that I'm way out of my depth here.  ;-)

Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240922/2848b62b/attachment.sig>