Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!bcyclone01.am1.xlned.com!bcyclone01.am1.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.052 X-Spam-Evidence: '*H*': 0.90; '*S*': 0.00; 'supported,': 0.07; 'imported': 0.09; 'objects.': 0.09; 'advance': 0.10; 'python': 0.10; 'enough.': 0.16; 'general.': 0.16; 'ideally,': 0.16; 'side.': 0.16; 'trivially': 0.16; 'looked': 0.16; 'transform': 0.18; 'project,': 0.18; 'input': 0.18; 'windows': 0.20; 'doc': 0.22; 'subject:problem': 0.22; 'accuracy': 0.23; 'matching': 0.23; 'second': 0.24; 'recognized': 0.24; 'header:In-Reply-To:1': 0.24; 'module': 0.25; 'linux': 0.26; 'mostly': 0.27; 'question': 0.27; 'executing': 0.27; 'module.': 0.27; 'pieces': 0.27; '---': 0.28; 'actual': 0.28; 'queue': 0.29; 'usable': 0.29; 'use?': 0.29; 'windows,': 0.29; 'environment': 0.29; 'objects': 0.29; "i'm": 0.30; 'server.': 0.30; 'code': 0.30; 'initially': 0.30; 'another': 0.32; 'implement': 0.32; 'related': 0.32; 'class': 0.33; 'problem': 0.33; 'point,': 0.33; 'suit': 0.33; 'case,': 0.34; 'running': 0.34; 'advice': 0.35; 'gets': 0.35; 'trouble': 0.35; 'next': 0.35; 'clear': 0.35; 'eric': 0.35; 'execution': 0.35; 'community': 0.36; 'needed': 0.36; 'there': 0.36; 'to:addr:python- list': 0.36; 'being': 0.37; 'turn': 0.37; 'thanks': 0.37; 'received:org': 0.37; 'things': 0.38; 'doing': 0.38; 'architecture': 0.38; 'google': 0.39; 'data': 0.39; 'does': 0.39; 'application': 0.39; 'to:addr:python.org': 0.40; 'where': 0.40; 'subject:with': 0.40; 'called': 0.40; 'some': 0.40; 'easy': 0.60; 'side': 0.62; 'programs': 0.62; 'back': 0.62; 'export': 0.63; 'relatively': 0.63; 'remember,': 0.66; 'results': 0.66; 'partner': 0.70; 'inform': 0.79; 'fast,': 0.84; 'recognition': 0.84; 'shoved': 0.84; 'speech': 0.84; 'subject:calls': 0.84; 'url:edit': 0.84; 'choices.': 0.91 DKIM-Filter: OpenDKIM Filter v2.8.4 z.eggo.org BB77C3C2B27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=harvee.org; s=5A244BA4-9B4C-11E4-B3C5-4D2F21081A62; t=1437621019; bh=Pw9Z1zh/MXhEt+Rdw/dWZO5yH3215mBhOMbo23sQuaU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Kt3cZpP8VfE5sYu6ebwNvI9kQ0Cd8mVBuzJ5ymqtQ4MnBlwuOm3xV8hXE56XbXP2z tdyksAi9f3wON8p9IPm3vaz7MRtUxJIp4EJejfOlYcL+JZvVWTRD0+uFatYMNzxvkq ejbCi6HquhpdiPvmvrt0J0JiTKwzZAOs4nrz4tg8= X-Virus-Scanned: amavisd-new at harvee.org Date: Thu, 23 Jul 2015 06:10:17 +0300 (EEST) From: eric johansson To: python-list@python.org In-Reply-To: <29701817.315.1437619102225.JavaMail.eric@aho> Subject: problem with selecting remote procedure calls MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [73.38.247.110] X-Mailer: Zimbra 8.0.5_GA_5839 (Zimbra Desktop/7.2.7_12059_Linux) Thread-Topic: problem with selecting remote procedure calls Thread-Index: FdMoZOidQvSuX56Y5664MS9t9HcqtQ== X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 16 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1437621589 news.xs4all.nl 2831 [2001:888:2000:d::a6]:57332 X-Complaints-To: abuse@xs4all.nl X-Received-Bytes: 6087 X-Received-Body-CRC: 1767573252 Xref: csiph.com comp.lang.python:94416 https://docs.google.com/drawings/d/1M-TzfRaSaAhFXQk1OmcmHNOaW31_7W_7q0bf8CAJqSw/edit?usp=sharing while this is related to my speech recognition through the next project, is actually a good question for RPCs in general. Specifically, are there any good-RPCs out there that are fast, supported, and easy to use? The Google Doc image given above shows the kind of things I'm doing to make speech recognition, running on windows, drive linux. The relay and emitter pair are almost trivially easy. The RPC is used to communicate the Windows scan code or codes for a given key and then the inner side translates that scan code into an actual code understood by Linux and it is shoved into the input queue. it's much harder to create a natlink module with a matching object in the RPC server. In this case, the class "data jammer" queries the application I built and extracts data necessary to inform the grammar back in the natlink module. Once the grammar executes, "data jammer" is called again to transform the results of the recognized grammar into usable data that will drive another application. In this case, I stuffed the data into the Windows input queue which in turn gets injected into win_relay. At this point, this is where I'm having some trouble with the RPC choices. I initially settled on rpyc because it was easy, it looked like it would do what I needed and it might even be fast enough. The problem being that the user community is mostly inhabited by crickets. Second problem is that it's not clear if I can export multiple objects from a single server. Ideally, I want there to be a pair of Python programs executing for any given grammar. The first would be the module imported into natlink and the other would be it's matching partner in crime on the linux side. I'm looking for ways to implement a plug-in architecture with independent objects. I would welcome advice on pieces I can recycle to meet my needs. for example, which Python RPC environment would best suit my needs. Remember, it needs to be relatively light because execution time does have an influence on recognition accuracy and speed. thanks in advance --- eric