This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFD]: Egor's proposal for a Cygwin server process


----- Original Message -----
From: "Corinna Vinschen" <vinschen@redhat.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@cygwin.com
> Red Hat, Inc.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]