All Versions
125
Latest Version
Avg Release Cycle
63 days
Latest Release
-

Changelog History
Page 13

  • v0.1.4 Changes

    ๐Ÿ›  Fix: fixed an issue with where the WebsocketClient#on_close wouldn't be called for a renewable Websocket connection during shutdown.

    ๐Ÿ›  Fix: fixed an issue where a protocol's #on_close callback wouldn't be called if the Iodine server receives a shutdown signal.

    ๐Ÿ›  Fix: fixed an issue where HTTP2 header size limit condition was not recognized by the Ruby parser (a double space issue, might be an issue with the 2.2.3 Ruby parser).


  • v0.1.3 Changes

    ๐Ÿ›  Fix: fixed an issue with the new form/multipart parser, where the '+' sign would be converted to spaces on form fields (not uploaded files), causing in-advert potential change to the original POSTed data.


  • v0.1.2 Changes

    ๐Ÿ›  Fix: fixed an issue where the default implementation of ping did not reset the timeout if the connection wasn't being closed (the default implementation checks if the Protocol is working on existing data and either resets the timer allowing the work to complete or closes the connection if no work is being done).


  • v0.1.1 Changes

    ๐Ÿ›  Fix: Fixed an issue where slow processing of HTTP/1 requests could cause timeout disconnections to occur while the request is being processed.

    ๐Ÿ”’ Change/Security: Uploads now use temporary files. Aceessing the data for file uploads should be done throught the :file property of the params hash (i.e. params[:upload_field_name][:file]). Using the :data property (old API) would cause the whole file to be dumped to the memory and the file's content will be returned as a String.

    ๐Ÿ”’ Change/Security: HTTP upload limits are now enforced. The current default limit is about ~0.5GB.

    ๐Ÿ”‹ Feature: WebsocketClient now supports both an auto-connection-renewal and a polling machanism built in to the WebsocketClient.connect API. The polling feature is mostly a handy helper for testing, as it is assumed that connection renewal and pub/sub offer a better design than polling.

    ๐ŸŒฒ Logging: Better HTTP error logging and recognition.


  • v0.1.0 Changes

    ๐Ÿš€ First actual release:

    We learn, we evolve, we change... but we remember our past and do our best to help with the transition and make it worth the toll it takes on our resources.

    ๐Ÿ”จ I took much of the code used for GRHTTP and GReactor, changed it, morphed it and united it into the singular Iodine gem. This includes Major API changes, refactoring of code, bug fixes and changes to the core approach of how a task/io based application should behave or be constructed.

    For example, Iodine kicks in automatically when the setup script is done, so that all code is run from within tasks and IO connections and no code is run in parallel to the Iodine engine.

    Another example, Iodine now favors Object Oriented code, so that some actions - such as writing a network service - require classes of objects to be declared or inherited (i.e. the Protocol class).

    This allows objects to manage their data as if they were in a single thread environment, unless the objects themselves are calling asynchronous code. For example, the Protocol class makes sure that the on_open and on_message(data) callbacks are executed within a Mutex (on_close is an exception to the rule since it is assumed that objects should be prepared to loose network connection at any moment).

    ๐Ÿš€ Another example is that real-life deployment preferences were favored over adjustability or features. This means that some command-line arguments are automatically recognized (such as the -p <port> argument) and that Iodine assumes a single web service per script/process (whereas GReactor and GRHTTP allowed multiple listening sockets).

    ๐Ÿš€ I tested this new gem during the 0.0.x version releases, and I feel that version 0.1.0 is stable enough to work with. For instance, I left the Iodine server running all night under stress (repeatedly benchmarking it)... millions of requests later, under heavy load, a restart wasn't required and memory consumption didn't show any increase after the warmup period.