Harkrishn Patro

> > Does option 1 require a change to the module build process? We currently build each module into its own .so file. > > Does option 2 affect the...

> If we did go with Option 1, I think we should be selective about what gets automatically bundled, it should only be widely-used production-ready modules. @murphyjacob4 that's the idea...

Note: Our current testing infrastructure doesn't support testing engine upgrade scenario, we can invest on building it separately into Redis.

@zuiderkwast Now might be the best time to reserve some channel namespace for server side purpose. And should we disable external publish on those reserved channels?

> We can add a channel alias now (in the 7.2.4-rc2) if we're really fast. I don't know if it's necessary though. WDYT? > > Maybe we should call it...

Albeit a breaking change, by reserving channel(s) for server side, we gain few things: 1. The schema of the message remains the same, doesn't create any problem around parsing. 2....

Changes to handle trademark violation ### External Facing 1. Clients 1. Do we need separate client(s)? 2. Compatibility (what are we compatible with?) 1. Can we advertise “RESP” (Redis Serialization...

> On module load, the existing modules will be looking for `RedisModule_*` APIs. We can double-register on the server side with both prefixes (`RedisModule_` and `XXXXModule_`) but only expose the...

> > So, registering on the server side for `RedisModule_` wouldn't be a trademark violation? > > This goes back to @zuiderkwast's earlier comment ([#25 (comment)](https://github.com/placeholderkv/placeholderkv/issues/25#issuecomment-2018976668)). > > I guess...

@madolson Tried making the comments generic. PTAL.