Comments (9)
I do not have precise answers to the questions, however I would like to make the following considerations.
I found Iodine well designed to deploy fast, reliable and scalable Ruby apps. All feature and components are appropriate and well integrated, like Redis support for example. My preceding experience to manage high numbers of concurrent WebSockets connections in Ruby with different application servers and gem stacks was frustrating before adopting Iodine. Moreover, I always found Bo’s support and suggestions on any issue. Last version of Iodine is mature and very stable.
I understand the need to have hands on real project in Ruby to maintain the gem more easily. I understand also the potential of having Iodine working also in Windows--this certainly tend to improve the quality of the codebase-- even if I do not know Isomorfeus purposes.
I think that greater community involvement is crucial for the future of the project, whatever it will be.
from iodine.
Hi Bo, Hi @adam12,
the differences between branches are visible in this PR #119
The version bump to 0.8 is because of Rack 3, which changed its API a bit (breaking iodine). I took over the API change to i-iodine, removing code from i-iodine, so it now depends on Rack 3 (previously it could work without Rack). A breaking change, so i bumped the version.
I expect to invest some more time into i-iodine soon again. Also my requirements for iodine changed over time with the advancement of my isomorfeus framework. Most probably it will become a easy to use application server for isomorfeus applications. Since i am using Bo's cstl within isomorfeus, one of the next steps will be to adapt i-iodine to cstl. Also one more fix is waiting for i-iodine 0.8 for upcoming Ruby 3.2. And i think, i need to pull a few fixes from iodine 0.7 into i-iodine 0.8
Users of iodine maybe dont expect it to become a isomorfeus application server, as that also includes removing features, that i dont require (like redis support), but users of iodine may depend on; and adding features i require for isomorfeus, but current user of iodine will never need.
Bo, please feel free to decide.
from iodine.
@fabio Isomorfeus is a full stack isomorphic Ruby Webapp/SPA framework: https://github.com/isomorfeus , Ruby everywhere and for everything, one Ruby to rule them all, basically
from iodine.
Hi @janbiedermann ,
Would you mind sharing the reason you removed the redis
support rather than just leave it as an unused feature?
There is something that makes a lot of sense about having the redis
support a little separate.
The reason I am asking is that memory restrictions and storage restrictions lead to different solutions, one allowing the redis
code to be kept in the same gem *with a require "iodine/redis"
to be loaded) and another requiring it to be moved to a separate gem... both are options raising their own questions and challenges.
Kindly,
Bo.
from iodine.
Hi @boazsegev ,
i did not remove it yet, i plan to remove it, rather replace it with a iodine internal solution based on fio_hash. Iodine already has cluster communication, so that can be used to have some internal "redis", well hashmap. Thats my plan.
The reason behind it, isomorfeus is for regional scale distributed services, comes with data store, no need for redis, so i can remove the cost of mainaining it. Reduce cost, effort. I simply want to make things as easy as possible for isomorfeus apps, no need to configure services or use external services, instead start the app and everything just works.
Basically like this.
from iodine.
Well, isomorfeus is a somewhat "complete" framework, it employs two large c-extensions, one for i-ferret and one for iodine and a smaller one for i-preact. They are somewhat self contained and together a huge C code base, that i would like to maintain. So naturally i look for things to exclude to reduce the effort required on my side.
from iodine.
Hi @janbiedermann ,
Thank you for your answer and explanation.
I totally understand your reason for wanting to remove Redis - code maintenance is always a burden. If we can decide on a common C and Ruby API for pub/sub "engines" we could probably export the Redis implementation to an external gem which can be shared across iodine
flavors.
replace it ["
reidis
"] with a iodine internal solution based onfio_hash
...
Indeed for version 0.8.x of the C framework (facil.io) I was hoping to add similar features:
-
Auto-discovery for "shared network" app clusters.
Using UDP broadcasts to discover and connect multiple
iodine
instances, it will be possible to combine multiple instances into an even bigger pub/sub cluster. This would allow micro-services in the same local-network to share pub/sub messages and events. This will not improve pub/sub performance (msg/sec), as that would require sharding, but it could be helpful in other ways such as failure resistance, event notifications, data sharing and supporting more concurrent clients. -
Key based in-memory local/cluster cache storage... the complexity and features of which I am still debating. I was thinking of either one of:
-
Simple String key => String value cache of limited capacity (i.e., 100,000 keys with LRU eviction) with no race condition resolution. This would be the simplest to implement and would provide a "near enough" source of truth for many implementations... but it would require the end-user (developer) to be creative about storying keys and clearing them out.
-
JSON style storage that allows the constant updating of a JSON tree. However things like Array updates (push / delete / eviction / ordering) and stale data removal are still unclear to me. Deleting data can be as easy as setting a key to
nil
(NULL
), but race conditions may have unclear effects and Array management introduces other challenges.
-
However, I doubt if these will replace the use-case for Redis completely, as Redis can be used for cross-region messaging, persistent event/task queues and sharding - all cases which require a 3rd party app / service (which can also be implemented in iodine
, but why reinvent the wheel).
from iodine.
Hi @boazsegev ,
that sounds very interesting. A common engine framework would be great, maybe thats a chance modularize iodine even a bit more, maybe for protocols.
Please clarify the state/relationship of cstl vs facil.io
from iodine.
Hi @janbiedermann ,
A common engine framework would be great...
I agree :)
I think we can come up with a Ruby specification API for pub/sub engines as well as a specification API for attaching protocols to iodine (or any compatible server).
I'm guessing we can also come up with a C API specification, but if we're to use the same C library it is mostly academic (as the library's API will be the de-facto specification).
Please clarify the state/relationship of cstl vs facil.io
TL;DR; - once completed it, the CSTL should become the facil.io version 0.8.0, replacing the core library (fio.h
& fio.c
).
The CSTL project started as something small, just unifying the Type Templates in fio.h
(i.e., here) with the FIOBJ
types. I wanted a cleaner and more consistent API for the different dynamic types...
...but it grew to swallow the whole of the facil.io core - including the server, pub/sub, JSON, FIOBJ types, etc'.
Protocol and extension specific logic (i.e., WebSockets, HTTP, Redis) are currently placed in an extras
folder, where they are likely to remain.
The way I currently see it, the CSTL + extras
folder will together become the facil.io version 0.8.0 (and hopefully move us towards a 1.0 release).
I'm not sure how I'll organize the GitHub repos, but I think I will either move the CSTL into the facil.io repo or dedicate the facil.io repo to the documentation and app builder script.
Obviously suggestions are welcome :)
Thanks for asking,
B.
from iodine.
Related Issues (20)
- Iodine failing to compile with Ruby 3.2.0preview_2 HOT 5
- [Rack 3] Response headers with Array value should produce multiple header fields HOT 3
- CPU usage when idle HOT 3
- Iodine.unsubscribe crashes when called with symbol. HOT 4
- Subscribing from the enter_master block subscribes even the children. HOT 3
- unix socket not writeable due umask HOT 8
- Writes to STDOUT even when Iodine.verbosity = 0 HOT 1
- Does not honor HUP signal. HOT 1
- Iodine stops on TERM signal with error when it run with -pid key and more than one worker HOT 1
- The Fixnum is gone as of Ruby-2.4 HOT 3
- response code 418 results in 500 Internal Server Error HOT 1
- [FEAT] return reason for closed connection/client HOT 7
- Static file serving: allow mounting of multiple local dirs HOT 14
- binary C extension not built? HOT 26
- How to get client instance id HOT 3
- ondisconnect example HOT 1
- rage-rb HOT 1
- undefining the allocator of T_DATA class IodineObjectStorage at startup HOT 2
- Iodine failing to build in fedora 40 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iodine.