> What's most important and > whos doing what currently? I'm afraid I'm doing not a damn thing, as my mother is dying, my wife is in a cast and even the slightest household task requires the coordinated efforts of the two of us, my son's emotional issues never seem to end, my daughter is flirting with homelessness and destitution again, dragging her son down with her, and my wife and I will soon need to move again, as this was my Mom's house and is underwater so the bank will glom onto it. If any one else wants to work on edbrowse I'd be happy to direct / advise; that's probably all I can do for the foreseeable future.
As for priority, I continue to suggest the find&fix method, what can't people run, like google groups or github etc, why, and is it really requiring a complex system like ajax or is it something silly like a missing dom object? I say that only because I tend to be user driven, market driven, and Adam generally is not, design it all to work as it should from the get-go, and that's good, if we all have the time. So I don't know. Love you all and glad you're on my team. Ok, here's a thought. I think the next step is separating the curl stuff out into its own curl server process, edbrowse --mode curl See main.c line 550. This would render almost no change from the user's perspective, but would seem to be necessary for future things to work right. I think we were talking about this when everyone went into hiatus for various reasons. I proposed a series of messages back and forth between user edbrowse and edbrowse curl, to fetch data and coordinate cookies and certificates and the like. I'll seee if I can find that thread. One curl server per user, so that parallel instances of edbrowse would not access and clobber the same cookie jar. I've done this experiment: edbrowse in two different consoles, 1 reads website A, 2 reads website B, 1 exits and writes the jar, 2 exits and writes the jar, cookies from site A are gone. This is a big job, a necessary job, a job that lays some ipc groundwork, but not as big as asynchronous js and some of the other things we're flirting with. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
