From beepwg-bounces@dbc.mtview.ca.us Fri Feb 03 13:02:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55Fr-0005Ex-3t for beep-archive@megatron.ietf.org; Fri, 03 Feb 2006 13:02:09 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24863 for ; Fri, 3 Feb 2006 12:59:49 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k13Hvshh011386; Fri, 3 Feb 2006 09:58:16 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k13HvoXL011383 for ; Fri, 3 Feb 2006 09:57:51 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F55Bf-00025u-00 for ; Fri, 03 Feb 2006 18:57:35 +0100 From: Francis Brosnan Blazquez To: BEEPwg Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Fri, 03 Feb 2006 18:58:00 +0100 Message-Id: <1138989480.1594.36.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1F55Bf-00025u-00*LEc8BK9JsGk* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k13HvoXL011383 Subject: [BEEPwg] [ANN] Vortex Library stable release 0.8.9 is out! X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA24863 ########################################## ## Vortex Library 0.8.9 Stable Release ## ########################################## Release note ~~~~~~~~~~~~ Advanced Software Production Line is proud to announce the Vortex Library 0.8.9 availability: an open source "BEEP Core" protocol implementation written in C, mapped into TCP/IP. Vortex Library is a powerful toolkit to write new application protocols and application over the well-defined "BEEP Core" protocol defined at RFC3080/RFC3081.=20 Vortex Library has been developed inside the Af-Arch project as its data transport layer. Vortex Library is a stable and robust application protocol development toolkit. Currently it is running under Microsoft Windows and GNU/Linux platforms. Check out the following links to get ready with Vortex Library: - http://vortex.aspl.es=20 [Vortex Library homepage] - http://fact.aspl.es [Af-Arch homepage where Vortex Library is being developed] =20 - http://www.beepcore.org [BEEP Core community web site] =20 The release in short ~~~~~~~~~~~~~~~~~~~~ This release adds a properly implemented SEQ frame support that now enables Vortex Library to interop with beepcore-java.=20 Added better support for mime handling. Messages generated are automatically mime-tized according to the profile configuration associated to the given channel. Frames read inside the Vortex Library automatically separates the payload content from the mime headers. Additionally, many bug fixings, memory handling, and project documentation updates. Many thanks goes to answers received at the beepcore.org community list: Peter Hall, David Blacka, David Kramer and Marshall Rose while requiring information about the SEQ frame support. An special mention goes to Paul Lacy which has provided the enough java support and working examples to make Vortex Library to talk to beepcore-java.=20 Changes since 0.8.8 ~~~~~~~~~~~~~~~~~~~ * [fix] fixing compilation errors found while using Vortex Library without TLS support exposed by win32 platforms. * [fix] updating user documentation for SASL, more examples and examples of code. * [new] working on adding XML-RPC support (through RFC3529 definition) At this moment it is implemented initial bootstrap mechanism to create XML-RPC channels and type definitions to be used to define method calls and its values (include method response). Added initial vortex-xml-rpc-listener.c test example. API added: Type definitions (XML-RPC spec abstract type definitions): - XmlRpcMethodCall - XmlRpcMethodResponse - XmlRpcMethodResponseFail - XmlRpcMethodValue - XmlRpcStruct - XmlRpcStructMember - XmlRpcArray - XmlRpcParamType - XmlRpcResponseStatus - VortexXmlRpcState - vortex_xml_rpc_new_method_call API functions: - vortex_xml_rpc_is_enabled=20 - vortex_xml_rpc_boot_channel - vortex_xml_rpc_channel_status - vortex_xml_rpc_accept_negociation - VortexXmlRpcBootNotify (handler) - VortexXmlRpcValidateResource (handler) - VortexXmlRpcServiceDispatch (handler) * [fix] making error message validation to be public. It was defined as a private function inside the Vortex Channel module. Renamed into: - vortex_channel_validate_err Now the function returns not only if an error reply was found but also code number and its textual diagnostic message. * [fix] fixing memory leak at close message handling function. It wasn't unrefering code and message values. * [new] added new API to check if the a given profile is the one running for a given channel: - vortex_channel_is_running_profile * [fix] updated project documentation, making a conceptual separation for the API found inside Vortex, fixing conclusion section for the profile example tutorial, * [fix] added API to vortex frame module to check if a given frame contains an error message. Makes use of the new API defined at vortex channel. API added: - vortex_frame_is_error_message * [fix] making vortex tls module to enforce providing a tls notification handler if the asynchronous API is the one being used. * [fix] adding an internal parameter counting for method call object inside XML-RPC invocation. This will ensure user space doesn't perform wrong XML-RPC invocations with missing parameters. * [new] adding more API to handle XML-RPC abstract data types: - vortex_xml_rpc_method_value_new: allows to create a new method parameter used for method call and method response. - vortex_xml_rpc_method_call_add_value: allows to associate a given method value to a given method call following a sequential order. - vortex_xml_rpc_method_call_set_value: allows to set at a given position a given value into a given method call. - vortex_xml_rpc_method_call_create_value: convenience function to create a method value and add it to a given method call into one step. - vortex_xml_rpc_method_call_free: destructor function for method call object. - vortex_xml_rpc_method_value_free: destructor function for method value. - added several #macros to support calling previous function without being required to write "vortex_xml_rpc" prefix * [fix] making vortex sequencer to not allocate memory to perform frame fragmentation. This is an step required to implement full support for SEQ frames. Now vortex sequencer rely on vortex_frame_build_up_from_params to create frame fragments. * [new] vortex_frame_seq_build_up_from_params to create SEQ frames. * [fix] rewritten vortex_frame_build_up_from_params to support building frames paying attention to the payload size rather than rely on %s parameter format which seeks for then next 0x0 value to delimit the payload. This is an step to support SEQ frames. * [new] adding new function to create raw frames from values to replace previous vortex_frame_build_up_from_params. This new function returns not only the frame built but also the size of it. API added: - vortex_frame_build_up_from_params_s * [fix] rewritten vortex_frame_build_up_from_params to use services provided by vortex_frame_build_up_from_params_s. Updated function documentation to advise it is deprecated. * [fix] rewritten vortex sequencer frame building code to use previous function and to perform some additional checks to ensure frame sequencing works properly. * [fix] fixing __vortex_channel_common_msg and __vortex_channel_common_rpy to use memcpy sentences based on sizes provided by user application to copy payload to be sent. * [???] found that some several critical sections placed on vortex reader process are not really needed. Maybe this is an ancient code that has lived within the vortex reader until now. For now, it is removed and some test will be performed to ensure that they are indeed not needed. * [fix] adding support to vortex_frame_get_next function to parse and return SEQ frames. One step closer to SEQ frames support. * [fix] definitely, critical sections found at vortex reader wasn't really necessary. Remove all code about this internal mutex, mutex allocation and mutex destruction. Updated vortex reader code to not perform any call to: - vortex_channel_lock_to_update - vortex_channel_unlock_to_update Updating documentation for previous function to flag them as deprecated. * [new] adding support to SEQ frames to vortex library. Now the library is able to produce and accept SEQ frames to perform flow control inside a BEEP session. * [fix] making vortex-client to produce raw frames using \x0D\x0A CRLF representation rather than \r\n. * [fix] making vortex greetings module to use \x0D\x0A CRLF representation rather than \r\n while creating greetings messages. * [fix] making vortex greetings module to update status received channel to use vortex_frame_get_content_size rather than vortex_frame_get_payload_size. * [new] adding new API to register mime type value to be used for channels created under some selected profile at vortex profiles module. Now vortex library automatically handle mime content type and mime content transfer encoding values generated for every message sent under a channel using a global configuration provided at vortex profiles module. API added: - vortex_profiles_set_mime_type: which allows to register for a given profile, already registered, the content-type and content-transfer-encoding value to be used. - vortex_profiles_get_mime_type: returns for the given profile the content type associated. - vortex_profiles_get_transfer_encoding: returns for the given profile the content transfer encoding value associated. * [new] added new API to vortex queue to enable Vortex Library internals to queue new items not only at the tail but also at the header of the queue. API added: - vortex_queue_head_push: queue a new item at the headers queue. =20 * [fix] written vortex sequencer module to conform SEQ frames implementation. Now vortex sequencer do not sent more frames than the maximum allowed by the remote peer until a new SEQ frame is received. It has also the ability to keep track on messages that are pending to be sequenced while attending other message sequence operations to other channel under other connections. Added lot of documentation to internal vortex sequencer structures to explain which is the purpose for every element used. * [fix] now vortex sequencer uses vortex_frame_build_up_from_params_s rather previous version (without _s) which supports returning current frame size built. This is considered more secure and binary content proof because new function implement frame building using memcpy operations. * [fix] adding new API to vortex sequencer to allow vortex reader to notify that the maximum allowed segment to be sent have been increased due to SEQ frame reception. API added: - vortex_sequencer_queue_and_signal_sem * [fix] fixed memory leak while parsing greetings message and an error happen. It wasn't unrefering (wrong) greeting frame. * [fix] several modification to vortex channel module to include support to track down maximum buffer size that is willing to accept the remote peer and maximum buffer size that the channel is willing to accept. Internal API added, not exposed to application level: Management function for the M=A1maximum buffer size to accept: - vortex_channel_update_remote_incoming_buffer - vortex_channel_get_max_seq_no_remote_accepted - vortex_channel_update_incoming_buffer - vortex_channel_get_max_seq_no_accepted - vortex_channel_queue_pending_message Pending to be re-sequence messages on a given channel, due to stale state: - vortex_channel_queue_pending_message - vortex_channel_next_pending_message - vortex_channel_remove_pending_message * [fix] fixing second level invocation for frame received, under some circumstances it wasn't deallocating the frame delivered. * [new] added support to include mime information while sending messages and replies using current configuration associated to the profile. This is a transparent mechanism to the application programmer, making it life easier. Internal API added: - __vortex_channel_get_mime_headers_size - __vortex_channel_get_mime_headers * [fix] fixing memory leak while creating new channels, it wasn't deallocating frame reply to a start message. Ouught! * [new] making channel 0 to be mime-tized to application/beep+xml for the content-type value and "binary" for the content transfer encoding. * [new] added support to allow application level to get current content-type and content-transfer-encoding for a given channel. API added: - vortex_channel_get_mime_type - vortex_channel_get_transfer_encoding * [fix] making vortex_init function to not initialize vortex listener module. This is not required to until a call to vortex_listener_new is done. * [fix] making vortex_exit function to stop and cleanup vortex reader system and to cleanup vortex profiles module. * [fix] making vortex_frame_get_next to not leak while allocating a frame but a poorly one was received. * [new] now vortex frames are read in a way that application programmer could get only the payload size, without mime information, and later get current mime information defined. API have been added to manage this new situation: - vortex_frame_get_content_type: get current content-type value for the given frame. - vortex_frame_get_content_transfer_encoding: get current content-transfer-encoding. - vortex_frame_get_mime_headers_size: get current mime headers size that are kept for the mime information. - vortex_frame_get_content_size: which returns the frame payload size including mime headers information. * [fix] rewritten beep channel management function (, , ,...) to not include mime information inside the message, and to allow mime automatic mechanism to generate it. * [fix] making vortex dtd module to deallocate xml rpc dtd on vortex exit. * [fix] making vortex reader to not use frames that are already deallocated to write log information, (using deallocated memory that could lead to memory corruption problems). * [fix] making vortex_listener_new to allocate values received for host and port, to allow application level to use either static or dynamic values. This values are later deallocated. Added more details on you to use this function and a example on building a vortex listener using this. * [fix] making vortex_listener_init to be callable from several threads at the same time. Now this function is called from vortex_listener_new function. * [fix] fixing autoconf files (AC_CONFIG_AUX_DIR(.) is included). * [fix] a great effort have been done to make vortex library to not leak. And now it is complete, and all source code written inside the context of the vortex library do NOT leak. Great! (valgrind rules!!!) * [fix] vortex documentation have been upgraded, vortex manual have been splitted into sections to get them more clear. Common sections and related info is now grouped. * [fix] starting the ansification process, at this moment only comments are translated into the /* ansi form */ from the // modern form. * [fix] fixing a really incredible bug based on a race condition between building the next frame to be sent and queueing the rest of the message due to remote buffer size is complete but, under some circumstances the frame generated is fast enough to reach remote side, be delivered into the application space, generate a new SEQ frame, and make local vortex reader to start a re-sequencing process but the initial !!already didn't queue the rest of the message to be resequenced.!!!! Reorganized vortex sequencer code to avoid previous race condition: threads, lot of fun! * [fix] fixing initial values used for the max seq no that the remote peer is willing to accept and the local buffer for each channel from 4096 to 4095, which represent a total octet counting of 4096 starting from 0 up to 4095. Making vortex reader, vortex channel and vortex sequencer to reorganize its operational calculus to this change. * [fix] fixing vortex_channel_update_incoming_buffer to not report vortex reader to send a SEQ frame if it is detected that current configuration will not allow this. Making this function to directly report current ackno and window size values so the vortex reader completely depends on this function. * [new] adding support to vortex frame module to generate an unique global identifier to uniquely identify every frame, mainly to allow memory debugging but also providing application space a way to identify frames. API added: - vortex_frame_get_id=20 * [fix] making vortex_frame_create to use services provided by vortex_frame_create_full to build new frames. This new function not only uses memcpy instructions to build new frames but also adds support to specify frame content type and content transfer encoding values. API added: =20 - vortex_frame_create_full=20 * [fix] fixing horrible, difficult to find bug, which was causing to leak memory due to not deallocating memory for the frame received as a reply containing the profile to be used for a previously start message. * [fix] making __vortex_frame_get_next_id to also report which is the frame module section that is allocating the next, concurrent, frame identifier. * [fix] fixing vortex autoconf files. Including xml-rpc-invocation.png image path into doxygen configuration file (also included into af-arch doxygen file). * [fix] making vortex greetings to update message numbers to be expected, rather than making an exception for the channel 0. * [fix] making vortex_channel_empty_new to set as default reply sent and reply received for channel 0 values {1, 1}. This solves the problem found for the message 0 that is never sent for the channel 0. * [fix] fixing a bug while processing start messages. If the xml received contains garbage, that is spaces, tabulars, returns, between the element and the element, the libxml library set as a child node to the element the garbage!! Added some additional checks to test if the node read is a profile node or something else. * [fix] making vortex reader to accept first messages that starts from with msgno=3D1. API added to control this function: - vortex_reader_allow_msgno_starting_from_1. This will make vortex library to interop with beepcore-java library. * [fix] performing more code ansification. Updated vortex CSS style sheet for the vortex documentation center. * [fix] making vortex library internal queue for frames to be sent, to be splitted into two queues, one with normal frames, and the other with SEQ frames. This last one have higher priority over the messages inside the same channel. To perform this change only following function were modified so, the rest of the Vortex Library subsystems keeps on working the same: - vortex_channel_queue_frame - vortex_channel_queue_is_empty - vortex_channel_queue_next_msg - vortex_channel_queue_length * [new] adding a new function to perform a synchronous channel boot for the XML-RPC profile. This will allow a blocking initialization. API added: - vortex_xml_rpc_boot_channel_sync * [new] adding two new function to the XML-RPC API to provide asynchronous and synchronous invocation. API added: =20 - vortex_xml_rpc_invoke - vortex_xml_rpc_invoke_sync * [new] added a new asynchronous notification handler to report results received for XML-RCP invocation performed. API added: =20 - XmlRpcInvokeNotify * [fix] making internal __vortex_connection_set_non_connected to not perform a shutdown and a close operation over the underlying socket, delegating that job to the vortex_connection_free function, that is called by the entity that perform the ultimate unref operation. Now, allows to delay the close operation as long as possible. * [fix] fixing some error at TLS and XML-RPC building when they are disabled. * [fix] working on giving XML-RPC support to vortex-client tool to perform invocations. * [fix] making vortex dtd module to report an error when a dtd file is not found. * [fix] reverting change done at __vortex_connection_set_not_connected function which was delaying connection close to vortex_connection_free. However, this has some issues causing applications that do not properly implements some aspect of the BEEP protocol to hang until a new connection is received. * [fix] plenty of fixing inside the vortex documentation (global spell checking done). * [fix] making seq frame generation decision making code to not allow it if the channel to report is being closed. This also makes to work TLS implementation and any tuning profile, that requires to close the session (including the channel 0 to start talking other non-beep protocol). * [new] adding a new function to enable restoring default IO handler used to send and received data for a given connection. API added: - vortex_connection_set_default_io_handler * [fix] fixing TLS code to properly fall back into normal operations when the TLS negotiation have failed. Making also (for listener and initiators) to not flag the connection to be tls-ficated until it is really done. * [fix] making vortex_channel_get_reply and vortex_channel_wait_reply to not get blocked until a specific reply is received for ever. A timeout mechanism has been introduced to perform a limited blocking wait. * [new] adding lot of documentation explaining how vortex_channel_get_reply and vortex_channel_queue_reply is used to implement synchronous, blocking frame reading. Added documentation at the frame dispatch schema documentation. About Us ~~~~~~~~ Advanced Software Production Line is leading the Af-Arch project: a complete framework to develop distributed application to manage enterprise process. Af-Arch project relies on Vortex Library to exchange data between its distributed nodes. Advanced Software Production Line also provides GNU/Linux support and consulting services on how organization can introduce GNU/Linux inside its process, making other platforms to interact with GNU/Linux. You can reach us: http://www.aspl.es - info@aspl.es We hope Vortex Library help you. Enjoy Vortex Library! =20 -- Francis Brosnan Bl=E1zquez - francis@aspl.es Advanced Software Production Line - http://www.aspl.es 3th Feb 2006, Madrid (Spain) =20 --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Wed Feb 08 13:32:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6u6y-00083E-G8 for beep-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:32:35 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19349 for ; Wed, 8 Feb 2006 13:30:24 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k18ISl90001068; Wed, 8 Feb 2006 10:28:48 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k18IQFtV001041; Wed, 8 Feb 2006 10:26:16 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F6u0w-0008Tu-00; Wed, 08 Feb 2006 19:26:02 +0100 From: Francis Brosnan Blazquez To: BEEP , BEEPwg Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 08 Feb 2006 19:27:03 +0100 Message-Id: <1139423223.4106.27.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1F6u0w-0008Tu-00*3n9UyWPZkqc* Subject: [BEEPwg] new BEEP Core community web site X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit Hi, beepcore.org community site has been upgraded to reorganize all information available around BEEP. I hope you find it useful. Activities ~~~~~~~~~~ There are many on going activities where collaboration is welcome. As a brief, these activities involves: - writing articles about aspects around the BEEP protocol and products/protocols making use of it, - notifying new BEEP toolkits and BEEP enabled products. There is also a service directory inside the support section that is organizing companies/organizations and products around BEEP. Some of previous yet listed products were missing (broken link on most cases), so, anyone how is interested on making its products to get listed again contact us. Articles ~~~~~~~~ As an initial step, an article about SEQ frames has been written [1], taking advantage from discussions on the beepcore.org mailing list. Articles are really important because many people can get lot of experience from those people that has already faced problems found inside the BEEP framework. Contact us ~~~~~~~~~~ To reach us for comments, suggestions, writing articles, or any related issue with the beepcore.org community portal, you can webmaster@beepcore.org. Enjoy BEEP! [1] http://beepcore.org/seq_frames.html -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Feb 09 01:07:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74xu-0005l6-T3 for beep-archive@megatron.ietf.org; Thu, 09 Feb 2006 01:07:38 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18887 for ; Thu, 9 Feb 2006 01:05:50 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1964CNv007498; Wed, 8 Feb 2006 22:04:15 -0800 Received: from hotmail.com (bay21-f16.bay21.hotmail.com [65.54.233.105]) k1964BbH007495 for ; Wed, 8 Feb 2006 22:04:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Feb 2006 22:04:00 -0800 Message-ID: Received: from 209.170.95.147 by by21fd.bay21.hotmail.msn.com with HTTP; Thu, 09 Feb 2006 06:03:59 GMT X-Originating-IP: [202.180.167.69] X-Originating-Email: [lucky7456969b@hotmail.com] X-Sender: lucky7456969b@hotmail.com From: "Jacky Luk" To: beepwg@lists.beepcore.org Date: Thu, 09 Feb 2006 06:03:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Feb 2006 06:04:00.0344 (UTC) FILETIME=[9EE18580:01C62D3E] Subject: [BEEPwg] Vortex/BEEP peer to peer protocol X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Hi, I need to implement a peer-to-peer wireless connection protocol, that is big request, big response. Any side can act as client and server and the data is full-duplex. I've got the book BEEP The definitive Guild from Marshall T. Rose It introduces some concepts on that, but did not supply code in C++ Code Snippet: wl = new Wireless(); wl->vortex_act_as_server(); wl->vortex_act_as_client(); the server code was taken from vortex-omr-server.c and the client code was taken from vortex-simple-client.c The problem is I use listener wait for the server so the code vortex_act_as_client never gets invoked.... Is there anywhere I can look? Thanks Jack _________________________________________________________________ FREE 'A WORD A DAY' - learn English easily! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-02ETFJ-0211E _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Feb 09 05:37:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79BI-0007rN-UQ for beep-archive@megatron.ietf.org; Thu, 09 Feb 2006 05:37:45 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07465 for ; Thu, 9 Feb 2006 05:35:55 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k19AEXo5011845; Thu, 9 Feb 2006 02:14:34 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k19AEUra011842 for ; Thu, 9 Feb 2006 02:14:31 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F78lR-0007gO-00; Thu, 09 Feb 2006 11:11:01 +0100 Subject: Re: [BEEPwg] Vortex/BEEP peer to peer protocol From: Francis Brosnan Blazquez To: Jacky Luk In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Thu, 09 Feb 2006 11:12:07 +0100 Message-Id: <1139479927.24842.24.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1F78lR-0007gO-00*sFdoBBeW2AE* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k19AEUra011842 cc: beepwg@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA07465 El jue, 09-02-2006 a las 06:03 +0000, Jacky Luk escribi=F3: > Is there anywhere I can look? Being a Vortex specific issue, and to those interested, this messages is being replied at [1]. -Francis [1] http://lists.aspl.es/pipermail/aspl-fact-users/2006-February/000040.html --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Fri Feb 10 05:15:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VIi-0007Yp-BO for beep-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:15:02 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05523 for ; Fri, 10 Feb 2006 05:12:55 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1AABJTr027759; Fri, 10 Feb 2006 02:11:36 -0800 Received: from hotmail.com (bay21-f13.bay21.hotmail.com [65.54.233.102]) k1AABGHf027755 for ; Fri, 10 Feb 2006 02:11:16 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Feb 2006 02:11:06 -0800 Message-ID: Received: from 67.131.237.20 by by21fd.bay21.hotmail.msn.com with HTTP; Fri, 10 Feb 2006 10:11:06 GMT X-Originating-IP: [202.180.167.69] X-Originating-Email: [lucky7456969b@hotmail.com] X-Sender: lucky7456969b@hotmail.com From: "Jacky Luk" To: beepwg@lists.beepcore.org Date: Fri, 10 Feb 2006 10:11:06 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 10 Feb 2006 10:11:06.0847 (UTC) FILETIME=[4E9416F0:01C62E2A] Subject: [BEEPwg] Vortex (Need 4 a persistant link example) X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Dear BEEP/Vortex gurus, I don't really want the session/connection to go away after sending and receiving data. How do I make a persistant link with vortex? probably asynchronous. Any examples to download This is quite urgent! Thanks Thanks Jack _________________________________________________________________ FREE 'A WORD A DAY' - learn English easily! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-02ETFJ-0211E _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Fri Feb 10 05:39:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Vgq-0000VQ-5X for beep-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:39:48 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06947 for ; Fri, 10 Feb 2006 05:38:03 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1AAavkc028094; Fri, 10 Feb 2006 02:36:58 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1AAarf9028091 for ; Fri, 10 Feb 2006 02:36:54 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F7Vdh-0005We-00; Fri, 10 Feb 2006 11:36:33 +0100 Subject: Re: [BEEPwg] Vortex (Need 4 a persistant link example) From: Francis Brosnan Blazquez To: Jacky Luk In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Fri, 10 Feb 2006 11:37:46 +0100 Message-Id: <1139567866.6374.37.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1F7Vdh-0005We-00*C6.HNDgZY.I* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k1AAarf9028091 cc: beepwg@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA06947 El vie, 10-02-2006 a las 10:11 +0000, Jacky Luk escribi=F3: > Dear BEEP/Vortex gurus, Hi Jack, Some clarifications are required. This mailing list is being run to answer BEEP protocol specific questions. Vortex Library users questions has nothing to do here. Vortex is just an implementation of the BEEP protocol. If you need help and clarifications about Vortex usage, use the mailing list provided for such purpose [1] If you have questions about the BEEP protocol itself, use this list. -Francis [1] http://lists.aspl.es/cgi-bin/mailman/listinfo/aspl-fact-users --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Feb 13 02:42:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YLU-00061a-1H for beep-archive@megatron.ietf.org; Mon, 13 Feb 2006 02:42:06 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21737 for ; Mon, 13 Feb 2006 02:40:17 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1D7c7YN008057; Sun, 12 Feb 2006 23:38:11 -0800 Received: from hotmail.com (bay21-f16.bay21.hotmail.com [65.54.233.105]) k1D7c4fc008054 for ; Sun, 12 Feb 2006 23:38:04 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 12 Feb 2006 23:37:55 -0800 Message-ID: Received: from 67.131.237.20 by by21fd.bay21.hotmail.msn.com with HTTP; Mon, 13 Feb 2006 07:37:55 GMT X-Originating-IP: [202.180.167.69] X-Originating-Email: [lucky7456969b@hotmail.com] X-Sender: lucky7456969b@hotmail.com From: "Jacky Luk" To: beepwg@lists.beepcore.org Date: Mon, 13 Feb 2006 07:37:55 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Feb 2006 07:37:55.0916 (UTC) FILETIME=[679890C0:01C63070] Subject: [BEEPwg] Meaning of uamn; X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us I saw a structure inside beepcore-c that is named uamn. I want to know what does it do? And what are the differences between message types? Thanks in advance Jack _________________________________________________________________ Get 10Mb extra storage for MSN Hotmail. Subscribe Now! http://join.msn.com/?pgmarket=en-hk _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Feb 13 09:01:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8eGP-0008KK-H6 for beep-archive@megatron.ietf.org; Mon, 13 Feb 2006 09:01:14 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21547 for ; Mon, 13 Feb 2006 08:59:26 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1DDv1oW014225; Mon, 13 Feb 2006 05:57:03 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1DDuvti014220 for ; Mon, 13 Feb 2006 05:56:58 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F8eC5-0002AM-00; Mon, 13 Feb 2006 14:56:45 +0100 Subject: Re: [BEEPwg] Meaning of uamn; From: Francis Brosnan Blazquez To: Jacky Luk In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Mon, 13 Feb 2006 14:58:22 +0100 Message-Id: <1139839102.3965.9.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1F8eC5-0002AM-00*P70ZNQwyfLY* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k1DDuvti014220 cc: beepwg@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21547 El lun, 13-02-2006 a las 07:37 +0000, Jacky Luk escribi=F3: Hi Jack, > And what are the differences between message types? >From RFC 3080 [1], under section 2.1.1 Exchange Styles, you can find: BEEP allows three styles of exchange: MSG/RPY: the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply). MSG/ERR: the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply). MSG/ANS: the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply. The first two styles are termed one-to-one exchanges, whilst the third style is termed a one-to-many exchange. Cheers, [1] http://www.rfc-editor.org/rfc/rfc3080.txt --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Tue Feb 14 23:57:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9EjU-0003wS-1u for beep-archive@megatron.ietf.org; Tue, 14 Feb 2006 23:57:44 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06685 for ; Tue, 14 Feb 2006 23:55:53 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1F4sEWq007367; Tue, 14 Feb 2006 20:54:18 -0800 Received: from hotmail.com (bay21-f10.bay21.hotmail.com [65.54.233.99]) k1F4sC1I007364 for ; Tue, 14 Feb 2006 20:54:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Feb 2006 20:54:00 -0800 Message-ID: Received: from 67.131.237.19 by by21fd.bay21.hotmail.msn.com with HTTP; Wed, 15 Feb 2006 04:54:00 GMT X-Originating-IP: [202.180.167.69] X-Originating-Email: [lucky7456969b@hotmail.com] X-Sender: lucky7456969b@hotmail.com From: "Jacky Luk" To: beepwg@lists.beepcore.org Date: Wed, 15 Feb 2006 04:54:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Feb 2006 04:54:00.0608 (UTC) FILETIME=[D61F2A00:01C631EB] Subject: [BEEPwg] About Profiles X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Hi, I'm looking into how to go about writing profiles. I have a question, If the profile is written in C, do I have to compile it? What is a profile basically? Can you explain what nullprofile and plain profile do? Thanks Jack _________________________________________________________________ FREE 'A WORD A DAY' - learn English easily! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-02ETFJ-0211E _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Wed Feb 15 04:00:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9IWK-0008MR-Tm for beep-archive@megatron.ietf.org; Wed, 15 Feb 2006 04:00:21 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21455 for ; Wed, 15 Feb 2006 03:58:33 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1F8vM2V010211; Wed, 15 Feb 2006 00:57:25 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1F8vJvH010207 for ; Wed, 15 Feb 2006 00:57:20 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F9IT6-0001nS-00; Wed, 15 Feb 2006 09:57:00 +0100 Subject: Re: [BEEPwg] About Profiles From: Francis Brosnan Blazquez To: Jacky Luk In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Wed, 15 Feb 2006 09:58:51 +0100 Message-Id: <1139993931.25351.15.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1F9IT6-0001nS-00*J.II9zy31uc* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k1F8vJvH010207 cc: beepwg@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA21455 El mi=E9, 15-02-2006 a las 04:54 +0000, Jacky Luk escribi=F3: Hi Jack, > What is a profile basically?=20 BEEP is a protocol to write new application protocols. This means that you can't use BEEP directly to send and receive data, if you don't extend BEEP to implement your specific application protocol. This is done by extending BEEP, adding your application protocol on top of it. The way BEEP is extended, to fulfill your protocol requirements, are: profiles. >From a conceptual point of view, without taking into account how each BEEP toolkit implements the profile concept, we could say that a profile is just an agreement between BEEP peers that they implement some application protocol, identified by the profile, which involves to know how to process messages to be exchanged by the profile and their meaning. Another concept to consider is that BEEP channels are created under the semantic of a profile. In other words, if you define your profile "A" and a profile "B", which are different application protocols, you are allowed to create channels that are bound to run under the profile "A" or "B". Now, once the profile, that define your application prototol, is defined, you need to implement it following indications of the BEEP toolkit you are using.=20 Cheers! --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Wed Feb 15 13:56:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9RpL-0004sh-Tr for beep-archive@megatron.ietf.org; Wed, 15 Feb 2006 13:56:36 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22843 for ; Wed, 15 Feb 2006 13:54:48 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1FIrZab018412; Wed, 15 Feb 2006 10:53:37 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1FIrWVt018409 for ; Wed, 15 Feb 2006 10:53:33 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F9RmA-0007an-00 for ; Wed, 15 Feb 2006 19:53:18 +0100 From: Francis Brosnan Blazquez To: BEEPwg X-Sieve: CMU Sieve 2.2 In-Reply-To: <1139423223.4106.27.camel@vulcan.aspl> References: <1139423223.4106.27.camel@vulcan.aspl> X-Scanner: exiscan *1F8sit-0004Y2-00*s.6GAFSKFrE* X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on dolphin.aspl.es X-Spam-Status: No, score=-1.2 required=3.0 tests=AWL,BAYES_40,RCVD_BY_IP autolearn=ham version=3.0.3 Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 15 Feb 2006 19:53:17 +0100 Message-Id: <1140029597.28031.44.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Subject: [BEEPwg] Re: [BEEPbuilders] new BEEP Core community web site X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit With Gabe's permission, I'm forwarding its message I encourage everyone who hasn't paid attention to beep in a while to go check out the new beepcore - its quite nice. Am I sensing a renewed interest in BEEP? On 2/8/06, Francis Brosnan Blazquez wrote: > Hi, > > beepcore.org community site has been upgraded to reorganize all > information available around BEEP. I hope you find it useful. > > > Activities > ~~~~~~~~~~ > > There are many on going activities where collaboration is welcome. As a > brief, these activities involves: > > - writing articles about aspects around the BEEP protocol and > products/protocols making use of it, > > - notifying new BEEP toolkits and BEEP enabled products. > > There is also a service directory inside the support section that is > organizing companies/organizations and products around BEEP. Some of > previous yet listed products were missing (broken link on most cases), > so, anyone how is interested on making its products to get listed again > contact us. > > Articles > ~~~~~~~~ > > As an initial step, an article about SEQ frames has been written [1], > taking advantage from discussions on the beepcore.org mailing list. > > Articles are really important because many people can get lot of > experience from those people that has already faced problems found > inside the BEEP framework. > > Contact us > ~~~~~~~~~~ > > To reach us for comments, suggestions, writing articles, or any related > issue with the beepcore.org community portal, you can > webmaster@beepcore.org. > > > Enjoy BEEP! > > [1] http://beepcore.org/seq_frames.html > > -- > Francis Brosnan Blazquez > Advanced Software Production Line, S.L. > > _______________________________________________ > BEEPbuilders mailing list > BEEPbuilders@lists.beepcore.org > http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepbuilders > -- Gabe Wachob / gwachob@wachob.com / http://www.wachob.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Wed Feb 15 13:59:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Rs1-0007fu-J8 for beep-archive@megatron.ietf.org; Wed, 15 Feb 2006 13:59:21 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23090 for ; Wed, 15 Feb 2006 13:57:34 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1FIudMU018460; Wed, 15 Feb 2006 10:56:40 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1FItP5m018439 for ; Wed, 15 Feb 2006 10:55:25 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1F9Rny-0007bh-00; Wed, 15 Feb 2006 19:55:10 +0100 From: Francis Brosnan Blazquez To: Gabe Wachob In-Reply-To: References: <1139423223.4106.27.camel@vulcan.aspl> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 15 Feb 2006 19:55:08 +0100 Message-Id: <1140029708.28031.48.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1F9Rny-0007bh-00*d5moAny9L/c* cc: BEEPwg Subject: [BEEPwg] Re: [BEEPbuilders] new BEEP Core community web site X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit Hi Gabe, > I encourage everyone who hasn't paid attention to beep in a while to > go check out the new beepcore - its quite nice. > Thanks, > Am I sensing a renewed interest in BEEP? I hope so. It is a great protocol that people should know to make a better desicion while writting new network connection oriented stuff. Cheers! -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From smith12_1@iwon.com Fri Feb 17 13:56:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAmT-0000Jr-Ff for beep-archive@megatron.ietf.org; Fri, 17 Feb 2006 13:56:37 -0500 Received: from afzhg1458.com ([196.207.197.249]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21739 for ; Fri, 17 Feb 2006 13:54:48 -0500 (EST) Message-Id: <200602171854.NAA21739@ietf.org> From: "Mr. Smith Dickinson" Reply-To: smith_2@iwon.com Date: Tue, 17 Jan 2006 13:15:10 +0100 Subject: I Hope That Our Mail Meet You In Good Time Mr. Smith Dickinson & Sister. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Friend=2C I am Mr=2E Smith Dickinson=2C the son of Mr=2E Johnnie Dickinson who died in New Orleans with My mother and one of my sister as a result of Hurricane Katrina in New Orleans=2E There is this huge amount of US$15=2E5million which my late father kept for us in company here in Senegal before he was died=2E Now I and my younger sister have decided to invest this money in your country or anywhere save for security and political reasons=2E We want you to help us claim and retrieved these funds from the Fiduciary Fund Holders and Transfer it into your personal account in your country for investment purposes on profitable ventures=2E If you can be of assistance to us=2C we will pleased to offer you 32% of the total fund=2E I await your soonest response through our private Mailbox=3A smith1=5F2=40iwon=2Ecom Telephone =3A +447031851113 Best Regards=2C Mr=2E Smith Dickinson & Sister=2E From smith12_1@iwon.com Fri Feb 17 13:57:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAnM-0000U2-01 for beep-archive@megatron.ietf.org; Fri, 17 Feb 2006 13:57:32 -0500 Received: from n2now2172.com ([196.207.197.249]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21782 for ; Fri, 17 Feb 2006 13:55:41 -0500 (EST) Message-Id: <200602171855.NAA21782@ietf.org> From: "Mr. Smith Dickinson" Reply-To: smith_2@iwon.com Date: Tue, 17 Jan 2006 13:16:03 +0100 Subject: I Hope That Our Mail Meet You In Good Time Mr. Smith Dickinson & Sister. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Friend=2C I am Mr=2E Smith Dickinson=2C the son of Mr=2E Johnnie Dickinson who died in New Orleans with My mother and one of my sister as a result of Hurricane Katrina in New Orleans=2E There is this huge amount of US$15=2E5million which my late father kept for us in company here in Senegal before he was died=2E Now I and my younger sister have decided to invest this money in your country or anywhere save for security and political reasons=2E We want you to help us claim and retrieved these funds from the Fiduciary Fund Holders and Transfer it into your personal account in your country for investment purposes on profitable ventures=2E If you can be of assistance to us=2C we will pleased to offer you 32% of the total fund=2E I await your soonest response through our private Mailbox=3A smith1=5F2=40iwon=2Ecom Telephone =3A +447031851113 Best Regards=2C Mr=2E Smith Dickinson & Sister=2E From beepwg-bounces@dbc.mtview.ca.us Mon Feb 27 05:27:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfax-0000rQ-8l for beep-archive@lists.ietf.org; Mon, 27 Feb 2006 05:27:11 -0500 Received: from [168.143.123.173] (helo=drakken.dbc.mtview.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDfas-00048C-U4 for beep-archive@lists.ietf.org; Mon, 27 Feb 2006 05:27:11 -0500 Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k1RAPVZx009568; Mon, 27 Feb 2006 02:25:35 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k1RANpeM009513; Mon, 27 Feb 2006 02:23:51 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1FDfXJ-0005ok-00; Mon, 27 Feb 2006 11:23:25 +0100 From: Francis Brosnan Blazquez To: Regina Aggio , BEEP , BEEPwg Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Mon, 27 Feb 2006 11:23:26 +0100 Message-Id: <1141035806.3997.9.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1FDfXJ-0005ok-00*naWaD85Wze2* Subject: [BEEPwg] New article X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi all, A new article, mainly based on first chapter, from the BEEP book, is available on the beepcore.org site [1]. For those who didn't read the BEEP book, it includes some interesting insights. I hope you find it helpful. Comments and sugestions are welcome! Cheers, [1] http://www.beepcore.org/mrose_beep.html -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg