DanielLeens commented on issue #11304: URL: https://github.com/apache/seatunnel/issues/11304#issuecomment-5186334728
Thanks for coming back with a much narrower phase-1 proposal. This is substantially stronger than the original umbrella framing. Treating phase 1 as a plain source -> memory sink for one concrete backend (Mem0), with upsert + delete only and no new core abstraction, is exactly the kind of scope reduction that makes this discussable. At this point the remaining design questions are less about whether the problem is real, and more about architecture boundaries and long-term evolution: 1. whether the first Mem0 sink can stay fully connector-local on top of the existing HTTP base without introducing a premature shared "memory" abstraction; 2. how delete semantics, idempotency, and user / agent / run scoping are represented in config and record shape; 3. what the retry / partial-failure contract is when the backend API rate-limits or only partially accepts a batch; 4. what exact e2e contract proves this is a data-integration connector rather than an agent-runtime add-on. The next useful step is to turn this narrowed MVP into a formal STIP/design document with: - explicit goals vs non-goals for phase 1; - request/record mapping examples for upsert and delete; - an explicit compatibility statement that phase 1 does not change engine/core/SPI contracts; - a test plan for self-hosted Mem0 via testcontainers. If you draft it in that shape, this can move from a broad discussion thread into a reviewable STIP path. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
