From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (75-164-203-192.ptld.qwest.net [75.164.203.192]) by hurricane.the-brannons.com (Postfix) with ESMTPSA id E8FDF77EF7 for ; Wed, 30 Dec 2015 18:53:32 -0800 (PST) From: Chris Brannon To: Edbrowse-dev@lists.the-brannons.com References: <20151130125742.eklhad@comcast.net> Date: Wed, 30 Dec 2015 18:54:00 -0800 In-Reply-To: <20151130125742.eklhad@comcast.net> (Karl Dahlke's message of "Wed, 30 Dec 2015 12:57:42 -0500") Message-ID: <87mvsrcoqf.fsf@mushroom.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Edbrowse-dev] Ports X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 02:53:33 -0000 Karl Dahlke writes: > Just thinking about ports, in regards to sockets. > I don't know if it's the best way, but the easiest way is to decide > somewhat arbitrarily that edbrowse will use the ports between 47380 and 47390, or some such range. My primary concern would be multi-user systems. How do you keep Alice's edbrowse from conflicting with Bob's? Then there's security. You can have your thing listen on loopback, so it isn't accessible from the big bad Internet, but if you're on a multi-user system, it's still open to whoever is sharing the system with you. Granted, most of us use this program on what are basically single-user systems. There aren't exactly a lot of edbrowse users out there, either. So maybe the answer is "don't care". For me, the optimal answer would be Unix domain sockets. If you don't know about them, they're like sockets, but represented by named files in the filesystem. So to connect to a daemon, you might connect to /run/my-daemon/socket or whatever, rather than some port on localhost. The advantages are that they can only be used for local interprocess communication between things running on the same machine, and access control is based on the Unix filesystem permission checks that we all know and love. But I'm guessing that these aren't usable on Windows, are they? Please tell me it has an equivalent...