Live data from Hacker News

Apache Iggy, a message streaming platform in Rust, graduates to an Apache TLP

iggy.apache.org

31–35 of 35 posts

Re: Apache Iggy, a message streaming platform in Rust, graduates to an Apache TLP

#31
post #24
post #16

Will it integrate directly with MQTT? Or should I use a MQTT broker and pipe into Iggy?

There's an open PR to implement sink + source for MQTT https://github.com/apache/iggy/issues/3385 Also, since we've been asked about this a lot, there's a high chance, that we might implement MQTT Gateway, just like we currently do for Kafka (proxy on top, as a separate runtime).

Could be nice indeed, if it can handle MQTT5 and replace EMQX!

Re: Apache Iggy, a message streaming platform in Rust, graduates to an Apache TLP

#32
post #27

Earlier quoted context omitted.

Don't worry about it, Apache is the hospice where software projects go to die.

There are roughly 400 projects on that page; about 90 are in the attic, meaning formally retired. Another 25 are incubating, and some of those look like they’re already dead; nobody has checked the pulse and filled out the paperwork yet. A huge chunk of Apache is Java libraries. Some projects are just academia doing academia things; they graduate, the original people move on, and the project dies. Others are corporat…

> Saying Apache is where software go to die is just wrong.

...and yet you proceeded to list all the ways that dead projects are being kept undead by Apache? I'm getting conflicting vibes here from your post.

Re: Apache Iggy, a message streaming platform in Rust, graduates to an Apache TLP

#34
post #27

Earlier quoted context omitted.

There are roughly 400 projects on that page; about 90 are in the attic, meaning formally retired. Another 25 are incubating, and some of those look like they’re already dead; nobody has checked the pulse and filled out the paperwork yet. A huge chunk of Apache is Java libraries. Some projects are just academia doing academia things; they graduate, the original people move on, and the project dies. Others are corporat…

> Saying Apache is where software go to die is just wrong. ...and yet you proceeded to list all the ways that dead projects are being kept undead by Apache? I'm getting conflicting vibes here from your post.

Yeah, the incubation projects. Do you not understand the difference between an incubation project and a TLP?

No conflicting vibes: 80% of projects survive the incubation, become TLP, and live a long life. How is that a hospice?

I only listed one way the undead project kept undead - "nobody has checked the pulse and filled out the paperwork yet." That was about _some_ of the 25 projects out of 400 projects. As for academia projects - some of them survive.

There is only one category that has a high mortality rate in Apache: government-donated projects.

Re: Apache Iggy, a message streaming platform in Rust, graduates to an Apache TLP

#35
post #9
post #4

I believe spetz is on the project, so I'd like to ask: Is this a MQ implementation, or can this be used in place of e.g. something like protobufs and iroh/tonic? Does it have something akin to grants/capabilities/authorization? Does it have RPC? Can I have services speak a more privileged set of instructions/commands and clients needing auth to speak dumber/more high level administrative commands just like gRPC? Also…

It's more like Kafka or Pulsar in terms of being the message streaming infrastructure (so an append-only log, not the message broker like, e.g., raw RabbitMQ). I think that the main docs page should give you a good understanding of how the data is stored/organized https://iggy.apache.org/docs/ - for example, on top of the topics, we also have "stream" which is just an extra hierarchy that can be used for something li…

How is client logic support for different languages designed in your project? Some time ago I found Kafka clients for several languages are pretty much unusable due to bugs and/or performance non-debuggability. The reason, I think, was that the client logic is quite complex and each client project had to re-implement it from scratch (or use some C FFI monstrosity - which was pretty much a dead end too).
Post reply on HN