Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <041801c0e9c0$23a3e4b0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "cygdev" <cygwin-developers AT cygwin DOT com>
References: <20010531124452 DOT G1870 AT cygbert DOT vinschen DOT de>
Subject: Re: [RFD]: Egor's proposal for a Cygwin server process
Date: Thu, 31 May 2001 20:54:59 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 31 May 2001 10:46:27.0042 (UTC) FILETIME=[F1752C20:01C0E9BE]

----- Original Message -----
From: "Corinna Vinschen" <vinschen AT redhat DOT com>


> Hi,
>
> The reason is that I found another good example how such a server
> could be used: s-uid and s-gid applications and files.

Neato.

> Only a server process running under LocalSystem account (or
> another account with appropriate privileges) could serve
> non-privileged user processes with that feature.
>
> So, as far as I can see, we have already three reasons to
> invent that server process:
>
> - Secure handles
> - IPC
(including SHM/MSG queues and semaphores ).
> - s-uid, s-gid facility
>
> I think we will find more later on.

 - Persistent Clipboard data. This would allow on-demand data provision,
not on-write, which would be _much_ faster for large files. (it's not
_slow_ now, but it could be significantly faster if it only wrote when
an application requested the data :]).

> So, how is the current "mood" related to such a server process
> and how keen are people to work on that?

Very keen. Keen to work on it too, but 0 time. Happy to sit in the
peanut gallery. Happy to test stuff however broken.

> Has somebody a suggestion how to interact with that server process?
> Sockets? Named pipes? Smoke signals?

Smoke signals. Definately. They will offer us many benefits:
* We will gain instant cross-platform access. (Smoke signals are
understood equally well on any binary computer).
* Lower heating bills for folk in cold places.
* Smoke Access Protocol (SAP). Derived from the source for SMOKE(wet
foliage), this protocol offers sticky information tagging, an important
resource for a wide area system such as smoke signals.

More seriously?
Sockets: I think this offers security issues.
Named pipes: Ditto.

I think COM with out-of-process only offers the capability for tight
integration between the daemon and the process calling it. I'm not
religious on this - just offering more work for someone else :].

Most importantly: I think that the daemon interface needs a some-what fo
rmal API for us in the peanut gallery that want to be able to add calls
to it in the future.

Rob

> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin
to
> Cygwin Developer
mailto:cygwin AT cygwin DOT com
> Red Hat, Inc.
>