Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Thu, 31 May 2001 16:54:25 +0400 From: egor duda X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <72147580509.20010531165425@logos-m.ru> To: "Robert Collins" CC: cygdev Subject: Re: [RFD]: Egor's proposal for a Cygwin server process In-reply-To: <041801c0e9c0$23a3e4b0$0200a8c0@lifelesswks> References: <20010531124452 DOT G1870 AT cygbert DOT vinschen DOT de> <041801c0e9c0$23a3e4b0$0200a8c0 AT lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Thursday, 31 May, 2001 Robert Collins robert DOT collins AT itdomain DOT com DOT au wrote: >> I think we will find more later on. RC> - Persistent Clipboard data. This would allow on-demand data provision, RC> not on-write, which would be _much_ faster for large files. (it's not RC> _slow_ now, but it could be significantly faster if it only wrote when RC> an application requested the data :]). any persistent fhandler_* data, actually. >> Has somebody a suggestion how to interact with that server process? >> Sockets? Named pipes? Smoke signals? RC> Smoke signals. Definately. They will offer us many benefits: RC> * We will gain instant cross-platform access. (Smoke signals are RC> understood equally well on any binary computer). RC> * Lower heating bills for folk in cold places. RC> * Smoke Access Protocol (SAP). Derived from the source for SMOKE(wet RC> foliage), this protocol offers sticky information tagging, an important RC> resource for a wide area system such as smoke signals. ROTFL :)) And don't forget about _enormous_ peer review and verification base :) RC> More seriously? RC> Sockets: I think this offers security issues. RC> Named pipes: Ditto. named pipes is (supposedly) secure enough, at least i don't know any way to compromise them. their problem is lack of support on w9x RC> I think COM with out-of-process only offers the capability for tight RC> integration between the daemon and the process calling it. I'm not RC> religious on this - just offering more work for someone else :]. i'm not sure, but i thought cross-process COM is implemented via normal old fashioned OS mechanisms (named pipes or LPC or shared memory). Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19