Replies: 2 comments 1 reply
-
It's hard to really determine what the differences are between the branches. Do you know if it was published anywhere? |
Beta Was this translation helpful? Give feedback.
1 reply
-
Personally, I don't care about Windows version of iodine at all. All I wanted when I found iodine was a performant puma alternative for Sinatra applications with native support for websockets for Linux environment. I don't need any special support for database access nor complex heavily evented framework - waiting on a database makes enough room for parallel processing in our cases. Just my 2p. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi maintainers, users and community members.
I wanted to ask:
Should we make isomorfeus-iodine the main branch?
I am working on a new version of the facil.io C framework that powers iodine and I was wondering about the future of iodine (if at all).
@janbiedermann forked iodine and created the isomorfeus-iodine branch which seems to be a good replacement for the main branch as well as supports Windows.
On one hand it seems that @janbiedermann is more involved and active as a maintainer and so the work they do might superior.
On the other hand, I cannot help but think that the isomorfeus-iodine branch might be following a different roadmap into the future than the one I have in my head.
In the end, if @janbiedermann wants the iodine gem I would happily give them control of the name and the project.
A server or a framework?
Originally I came up with iodine as I needed to write a a real-time app and could find a library I liked with reasonable performance.
This led me down a rabbit hole and it is my current belief that the Ruby community would really benefit from a one-stop evented framework for authoring micro-services and SPAs (which was what I tried to do with plezi.io for a while).
Expending iodine so it becomes that framework would add the need for a database access API (i.e, having C bindings to PostgreSQL) and making HTTP responses evented would require a departure from the current Rack specifications...
... Maybe iodine should not be that framework. The iodine server is a fast and performant server. It follows the Rack specification, which is based on CGI and does not allow for an evented design. Perhaps iodine should remain as it is and evolve according the to vision @janbiedermann holds.
Maybe it is time I let iodine go and revived my vision for the plezi.io framework instead?
Let me know what you think in the comments below.
Thanks!
Bo.
Beta Was this translation helpful? Give feedback.
All reactions