edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev]  curl handles and general comms design
Date: Tue, 29 Dec 2015 14:57:27 -0500	[thread overview]
Message-ID: <20151129145727.eklhad@comcast.net> (raw)
In-Reply-To: <20151229191702.GB1766@122oven.adamthompson.me.uk>

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

  reply	other threads:[~2015-12-29 19:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-29 19:17 Adam Thompson
2015-12-29 19:57 ` Karl Dahlke [this message]
2015-12-29 22:27   ` Chris Brannon
2015-12-30 12:01   ` Adam Thompson
2015-12-30 12:26     ` Karl Dahlke
2015-12-30 13:22       ` Adam Thompson
2015-12-30 13:41         ` Karl Dahlke
2016-01-05  0:38 ` Chris Brannon
2016-01-08 19:43   ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151129145727.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).