I know it's semantics, but I think it's important in this case to mention that the entire article is about the open-source Chromium browser, not the proprietary Google Chrome one.
Thank you! I thought people might know it more as Google Chrome. Hence why I changed it on the HN title. But the original blog title specifically mention Chromium.
What about having an intermediate server running on the same box as the browser, that connects to CDP using a pipe, and forwards messages to the Redis server, instead of modifying Chrome s source ? It's painful to maintain Chrome patches.
Really cool project in any case, seems like working at Pikkit must've been a lot of fun ! Thanks OP for sharing.
This would work. We started prototyping this way and it worked well to an extend. The main issue you're going to have, is you need to have both chromium and the forwarder process to run at the same time. This makes it difficult to track what is running exactly.
If you're forwarder is running but the browser crashed, it will still appear as available on the Redis side. While if you're making the browser setting a key with expiration itself, if it crashes, it will stop appearing on redis side.
Those are the kind of stuff you get modifying the source, and that will be hard to do with dual process type of setup.
Chromium*
I know it's semantics, but I think it's important in this case to mention that the entire article is about the open-source Chromium browser, not the proprietary Google Chrome one.
Thank you! I thought people might know it more as Google Chrome. Hence why I changed it on the HN title. But the original blog title specifically mention Chromium.
What about having an intermediate server running on the same box as the browser, that connects to CDP using a pipe, and forwards messages to the Redis server, instead of modifying Chrome s source ? It's painful to maintain Chrome patches.
Really cool project in any case, seems like working at Pikkit must've been a lot of fun ! Thanks OP for sharing.
This would work. We started prototyping this way and it worked well to an extend. The main issue you're going to have, is you need to have both chromium and the forwarder process to run at the same time. This makes it difficult to track what is running exactly.
If you're forwarder is running but the browser crashed, it will still appear as available on the Redis side. While if you're making the browser setting a key with expiration itself, if it crashes, it will stop appearing on redis side.
Those are the kind of stuff you get modifying the source, and that will be hard to do with dual process type of setup.
Not the OP but I’ve been thinking to write exactly this as part of making my personal browser available over MCP.