Yes, sorry if edbrowse is in a state of flux right now. I'm closing curl handles more as a proof of concept, not saying we need to or want to do that in general. Can we retain our cookie state with at least one handle open? We know about the sharing interface and Chris is going to work on that, and then all the handles should tie together with one cookie state and then some things should clear up. Some of the inefficiency could be rereading and rewriting the cookie file all the time, and that will go away.
I put more of our state variables for downloading files etc on the stack in preparation for threads. I use to use static variables and got away with it since processes forked off, but we know that won't work so now moving to stacks in preparation for threads. This is the "curl http background download mini project" that we agreed on last week, and it should finish up soon and then we can talk about the next step. I'm thinking about an edbrowse-http process to handle these curl requests and maintain the one and only cookie state, but perhaps not just for edbrowse, perhaps for all instances of edbrowse running. I run edbrowse from various virtual consoles, sometimes without realizing it, and indeed one edbrowse could clobber cookies introduced by another edbrowse. I haven't noticed that specifically but it probably has happened. So if edbrowse-http became a daemon serving the curl needs of all edbrowse processes running, then that would solve any and all cookie collision problems forever more. Wonder if Chrome and others effectively share the cookie jar and favorites etc among separately running instances of the browser? Well it's something to think about. I also need to resurrect some of the socket routines that are buried in git, so we can use them. They're suppose to hide the differences between unix and windows, and they were tested at one time but that was like 15 years ago, so I'll want Geoff to look at them again. Send any bug reports or disasters to me, and hopefully this will stabilize soon. Cheers. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
