Building on #72, I propose a focused follow-up with an isolated exporter that reuses Archify's existing rendering path. This issue is to discuss the implementation boundary, delivery slices, and acceptance criteria before coding.
@tt-a1i's review and @YunyueLi's follow-up provide the starting point: a fresh branch, a shared converter, stronger native diagrams.net checks, and fixes for source-file preservation and compatibility. The questions below focus on how to turn that into reviewable implementation steps.
@kidoln, is a successor already in progress? Let's coordinate the scope so the work is complementary. Any follow-up would reference #72 and preserve attribution for reused work.
The main decisions to discuss are:
-
How should we split the first PR?
I suggest a CLI-focused first slice, with five diagram types, both modes, and the relevant brand/group/sequence semantics remaining the overall acceptance target. Would that support incremental review, or are there dependencies that make full converter coverage necessary before the first merge?
-
Is rendered SVG the right adapter boundary?
My proposal is to consume existing rendered SVG and semantic annotations, keeping the conversion in a separate module shared by CLI and Viewer. Small, general-purpose annotations might fill gaps such as sequence activation identity. Would that fit the architecture, or is there a better existing seam?
A related case is that ordinary architecture boundaries can have overlapping memberships, which do not always map naturally to draw.io's group hierarchy. How should that mismatch be handled while preserving current input behavior? I suggest discussing any broader core changes separately, so they can be evaluated on their own merits.
-
How should we define fidelity and acceptance?
For editable versus strict export, which geometry/style properties are essential, and which differences could be reported as limitations? Would representative import → edit → save → reopen checks in a pinned diagrams.net version, together with visual comparisons, be a reasonable starting point? More specific fixtures and tolerances could follow once the initial scope is clearer.
-
How should package freshness fit the staged approach?
Current CI expects archify.zip to match runtime source. I suggest including the necessary ZIP rebuild when the first slice is ready for merge, with Gallery/example/proof regeneration in later stages. Does that fit the intended review sequence?
@tt-a1i @YunyueLi, let's use this thread to compare the options and settle a practical first slice. What tradeoffs or constraints should we account for? The proposal is open to alternatives; preserving compatibility and keeping the changes reviewable are the priorities.
Building on #72, I propose a focused follow-up with an isolated exporter that reuses Archify's existing rendering path. This issue is to discuss the implementation boundary, delivery slices, and acceptance criteria before coding.
@tt-a1i's review and @YunyueLi's follow-up provide the starting point: a fresh branch, a shared converter, stronger native diagrams.net checks, and fixes for source-file preservation and compatibility. The questions below focus on how to turn that into reviewable implementation steps.
@kidoln, is a successor already in progress? Let's coordinate the scope so the work is complementary. Any follow-up would reference #72 and preserve attribution for reused work.
The main decisions to discuss are:
How should we split the first PR?
I suggest a CLI-focused first slice, with five diagram types, both modes, and the relevant brand/group/sequence semantics remaining the overall acceptance target. Would that support incremental review, or are there dependencies that make full converter coverage necessary before the first merge?
Is rendered SVG the right adapter boundary?
My proposal is to consume existing rendered SVG and semantic annotations, keeping the conversion in a separate module shared by CLI and Viewer. Small, general-purpose annotations might fill gaps such as sequence activation identity. Would that fit the architecture, or is there a better existing seam?
A related case is that ordinary architecture boundaries can have overlapping memberships, which do not always map naturally to draw.io's group hierarchy. How should that mismatch be handled while preserving current input behavior? I suggest discussing any broader core changes separately, so they can be evaluated on their own merits.
How should we define fidelity and acceptance?
For editable versus strict export, which geometry/style properties are essential, and which differences could be reported as limitations? Would representative import → edit → save → reopen checks in a pinned diagrams.net version, together with visual comparisons, be a reasonable starting point? More specific fixtures and tolerances could follow once the initial scope is clearer.
How should package freshness fit the staged approach?
Current CI expects
archify.zipto match runtime source. I suggest including the necessary ZIP rebuild when the first slice is ready for merge, with Gallery/example/proof regeneration in later stages. Does that fit the intended review sequence?@tt-a1i @YunyueLi, let's use this thread to compare the options and settle a practical first slice. What tradeoffs or constraints should we account for? The proposal is open to alternatives; preserving compatibility and keeping the changes reviewable are the priorities.