|
| 1 | +# Common Package |
| 2 | + |
| 3 | +This package contains shared types and utilities used across the `corim`, `comid`, and related packages. |
| 4 | + |
| 5 | +## Purpose |
| 6 | + |
| 7 | +Created to address issue #11: "Factor out common code" |
| 8 | + |
| 9 | +## Analysis of Common Code |
| 10 | + |
| 11 | +After analyzing the codebase, the following areas of duplication were identified: |
| 12 | + |
| 13 | +### 1. Entity Name Implementation |
| 14 | +- **Location**: `comid/entity.go` and `corim/entity.go` |
| 15 | +- **Duplication**: |
| 16 | + - `EntityName` struct and methods (~200 lines duplicated) |
| 17 | + - `StringEntityName` type and methods |
| 18 | + - `IEntityNameValue` interface |
| 19 | + - `IEntityNameFactory` type |
| 20 | + - Factory functions: `NewEntityName`, `MustNewEntityName`, `NewStringEntityName`, `MustNewStringEntityName` |
| 21 | + - CBOR/JSON marshaling logic for EntityName |
| 22 | + - Entity name registry and `RegisterEntityNameType` |
| 23 | + |
| 24 | +**Recommendation**: The EntityName implementation is nearly identical between comid and corim packages. However, each package requires different CBOR tag registries. A refactoring would need to: |
| 25 | +- Extract common base types to `common` package |
| 26 | +- Keep package-specific CBOR/JSON marshaling in each package |
| 27 | +- Or use a more sophisticated registry pattern |
| 28 | + |
| 29 | +### 2. Role/Roles Implementation |
| 30 | +- **Location**: `comid/role.go` and `corim/role.go` |
| 31 | +- **Duplication**: |
| 32 | + - `Role` type (int64) |
| 33 | + - `Roles` slice type |
| 34 | + - `RegisterRole` function |
| 35 | + - `String()` method |
| 36 | + - `Valid()` method for Roles |
| 37 | + - JSON marshaling/unmarshaling logic |
| 38 | + - roleToString and stringToRole maps |
| 39 | + |
| 40 | +**Differences**: |
| 41 | +- Different role constants (comid: TagCreator, Creator, Maintainer; corim: ManifestCreator) |
| 42 | +- comid's Roles.Add() doesn't validate, corim's does |
| 43 | +- corim has additional ToJSON/FromJSON helper methods |
| 44 | +- comid has ToCBOR/FromCBOR methods |
| 45 | + |
| 46 | +**Recommendation**: Could extract a base `Role` type and registration system, but each package would keep its own role constants and any package-specific behavior. |
| 47 | + |
| 48 | +### 3. TaggedURI |
| 49 | +- **Location**: `comid/entity.go` |
| 50 | +- **Usage**: Used by both comid and corim Entity types |
| 51 | +- Simple string wrapper with `Empty()` method |
| 52 | + |
| 53 | +**Recommendation**: Easy candidate for extraction - it's a simple utility type with no dependencies. |
| 54 | + |
| 55 | +### 4. Common Validation/Marshaling Patterns |
| 56 | +- Many types implement similar `Valid()`, `MarshalCBOR()`, `UnmarshalCBOR()`, `MarshalJSON()`, `UnmarshalJSON()` patterns |
| 57 | +- Uses `encoding.PopulateStructFromCBOR`, `encoding.SerializeStructToCBOR`, etc. |
| 58 | + |
| 59 | +**Recommendation**: These patterns are already well-factored through the `encoding` package. No further action needed. |
| 60 | + |
| 61 | +## Implementation Considerations |
| 62 | + |
| 63 | +### Challenges |
| 64 | +1. **CBOR Tag Registration**: comid and corim have separate CBOR tag registries. Moving types to `common` would require either: |
| 65 | + - Maintaining separate encoders/decoders in each package |
| 66 | + - Creating a more complex registry system |
| 67 | + - Keeping marshaling logic in each package |
| 68 | + |
| 69 | +2. **Package Dependencies**: Need to avoid circular dependencies between common, comid, and corim |
| 70 | + |
| 71 | +3. **Backward Compatibility**: Any refactoring must maintain the existing public API |
| 72 | + |
| 73 | +4. **Test Coverage**: Extensive test suites exist for current code - all must continue to pass |
| 74 | + |
| 75 | +### Recommended Approach |
| 76 | + |
| 77 | +Given the complexity of CBOR tag handling and the relatively small size of the codebase, the most practical approach is: |
| 78 | + |
| 79 | +1. **Phase 1** (this PR): Document common code patterns and create the `common` package structure |
| 80 | +2. **Phase 2** (future PR): Extract truly independent utilities (like TaggedURI) |
| 81 | +3. **Phase 3** (future PR): Consider more complex refactoring of Role/EntityName if warranted |
| 82 | + |
| 83 | +## Status |
| 84 | + |
| 85 | +**Current**: Analysis and documentation complete. |
| 86 | +**Next Steps**: Team decision on whether to proceed with extraction or keep as-is with documentation. |
| 87 | + |
| 88 | +Note: The `cocli` package mentioned in the original issue has been moved to a separate repository, so cocli/cmd/common.go is no longer relevant to this codebase. |
0 commit comments