[Edbrowse-dev] The Ongoing Cookie Saga

[Edbrowse-dev] The Ongoing Cookie Saga

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

For 2 or 3 weeks I've been working on the duktape conversion, and for all that time I've had the API web page up in console 6.
Any question I have about what to call or what it does I switch to console 6 and read about it, then switch back.
Then after 3 weeks I'm done and I exit the API page and close that instance of edbrowse.
What does that do?
Writes the cookie file as it was 3 weeks earlier.
All cookies that might have accrued during those 3 weeks are gone. Poof!
This is something we've talked about before, but this incident really brought it to the fore.

The strategy was always to spin off an edbrowse curl process to be our curl server, and all user instances of edbrowse would talk to it, and it would manage the cookies in one central place, and so on.
I laid out some interprocess messages to and from the curl server, and I just recovered those from the archives, just for grins.
Around February of last year if you're interested, thread "Messages to and from edbrowse-curl".
But there are things we didn't even get round to talking about, like how that process probably has to be multithreaded
with one thread per user edbrowse process, so one slow http connection doesn't bog down the other processes,
and how to implement the interprocess messages in a unix window portable manner,
and how to start the edbrowse curl process, and how then everybody communicates with it,
and how it remains efficient even for large downloads, and how they can happen in the background as they do today,
and when will it write the cookie file (since it never exits),
and how to pass changing config options from user processes over to the curl process (such as the NTLM toggle and others), and on and on.
In other words it's a huge amount of work.
I knew it was a lot before but now I see it's more, like would take 6 months of my full time effort,
and the result would be some pretty fragile and confusing code that I probably wouldn't like anyways.
Anybody who had to maintain or enhance it would probably cuss me out.

As Fegin said in Oliver, "I think I'd better think it out again."
Or as Karl says from time to time, "A moment of thought is worth a megabyte of programming."

How bout this instead? It's like 0.1% the effort.
Just before curl closes down, which is when it writes out the cookie file,
read the cookie file in again, and incorporate any new cookies, or any cookies whose expiration date exceeds the date of the cookie we have internally.
Then exit, and curl writes the cookie file as usual, with all current cookies.
It's a merge of what we know plus what's in the jar.
We have written most of this code already.
I read the cookie jar at edbrowse startup, and I have code to check for a duplicate cookie, but I just take the second one instead of comparing the expire times.
Well that's a pretty small change.
Overall I think it would be easy peasy lemon squeezy, and would solve the problem.
Thoughts?
If I were to work on this would you want me to switch back to the master branch - it has nothing to do with duktape or js.


Karl Dahlke