Return-Path: Delivered-To: apmail-avro-user-archive@www.apache.org Received: (qmail 94178 invoked from network); 4 Jan 2011 10:54:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jan 2011 10:54:09 -0000 Received: (qmail 10449 invoked by uid 500); 4 Jan 2011 10:54:09 -0000 Delivered-To: apmail-avro-user-archive@avro.apache.org Received: (qmail 10214 invoked by uid 500); 4 Jan 2011 10:54:06 -0000 Mailing-List: contact user-help@avro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@avro.apache.org Delivered-To: mailing list user@avro.apache.org Received: (qmail 10196 invoked by uid 99); 4 Jan 2011 10:54:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 10:54:06 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gaillard@asperasoft.com designates 209.85.214.171 as permitted sender) Received: from [209.85.214.171] (HELO mail-iw0-f171.google.com) (209.85.214.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 10:53:58 +0000 Received: by iwn2 with SMTP id 2so13916844iwn.30 for ; Tue, 04 Jan 2011 02:53:37 -0800 (PST) Received: by 10.42.239.198 with SMTP id kx6mr22127545icb.360.1294138417238; Tue, 04 Jan 2011 02:53:37 -0800 (PST) Received: from [10.1.0.1] (AMarseille-552-1-135-102.w92-150.abo.wanadoo.fr [92.150.38.102]) by mx.google.com with ESMTPS id k38sm18526024ick.9.2011.01.04.02.53.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 02:53:36 -0800 (PST) Message-ID: <4D22FC31.20800@free.fr> Date: Tue, 04 Jan 2011 11:53:37 +0100 From: Gilles Gaillard Reply-To: Gilles Gaillard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: user@avro.apache.org Subject: [Avro C] Interoperability with Java Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, we'd like to use Avro for inter process communication between C and Java using regular sockets and we noted that there is not yet an implementation ready for RPC with Avro-C. Our requirements do not include to have a full 'block-mode' RPC and therefore we would be happy with an asynchronous mode where no return value is expected when a message is sent. So using the IDL, that's equivalent to defining messages as methods with a void return value. With the current implementation of Avro-C, we see the following questions and would like to know if anybody has answers or has already thought about a solution - or even better code that is ready to go ;-) - On August 25, there were commits reverted in preparation for 1.4.0 branch (949400, 947962, 947389, 947385, and 947299) for AVRO-441, AVRO-464, AVRO-466, AVRO-549, and AVRO-552. Do you plan to plan to incorporate them back in a near future - since the branch for 1.4.x now exists ? Specifically: AVRO-551 / 552 - Build for Win32 AVRO-549 - Route memory management through an allocator interface - We would like to avoid any unnecessary data copies when transferring byte arrays (defined with "type" : "bytes" in the schema). In java the binary encoder takes care of encoding the messages in a list of buffers - this is called 'Message Framing' in the Avro specification - which can then be transferred as such on the wire. For arrays of bytes this often mean they're simply passed through and sent separately which means they're nicely read from the wire and processed at no cost when decoding. My understanding is that such framing does not exists in Avro-C. Has anybody already written this or have stub for it (and similar for decoding) ? Using this message framing would then allow to use the avro_reader_memory (a modified version of it). Another way to go would be to write an avro_socket_reader (to be added in the avro_io_type_t enum) Any hint, what's the best way to go ? Thanks, -- Gilles