Files
calendar/integration_plan.md
Connor Johnstone f266d3f304 Implement RFC 5545-compliant calendar system with v2 API
This major refactor eliminates manual string parsing throughout the
codebase and introduces proper RFC 5545 iCalendar specification
compliance with significant code simplification benefits.

## Backend Improvements
- Add complete RFC 5545-compliant data structures (VEvent, VTodo, etc.)
- Create simplified v2 API endpoints with direct DateTime support
- Eliminate ~150 lines of manual string parsing in handlers
- Add structured attendee and alarm support
- Maintain backward compatibility with existing v1 APIs

## Frontend Improvements
- Replace 16+ parameter create_event calls with single structured request
- Add automatic date/time conversion in EventCreationData
- Eliminate enum-to-string conversions throughout event creation
- Add v2 API models with proper type safety

## Technical Benefits
- Direct DateTime<Utc> usage instead of error-prone string parsing
- Proper RFC 5545 compliance with DTSTAMP, SEQUENCE fields
- Vec<AttendeeV2> instead of comma-separated strings
- Structured alarm system with multiple reminder types
- Enhanced RRULE support for complex recurrence patterns

## Code Quality
- Reduced create_event call from 16 parameters to 1 structured request
- Added comprehensive integration plan documentation
- Both backend and frontend compile successfully
- Maintained full backward compatibility during transition

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-29 17:06:22 -04:00

186 lines
5.4 KiB
Markdown

# RFC 5545 Integration Plan
## Phase 1: Core Structure Replacement (High Impact, Low Risk)
### 1.1 Replace Event Models
**Files to Update:**
- `backend/src/calendar.rs` - Replace `CalendarEvent` with `VEvent`
- `src/services/calendar_service.rs` - Replace `CalendarEvent` with `VEvent`
- Remove duplicate structures, use single source of truth
**Benefits:**
- ✅ Eliminate duplicate event definitions
- ✅ Add missing DTSTAMP (RFC required)
- ✅ Add SEQUENCE for proper versioning
- ✅ Standardize on DateTime<Utc> instead of string parsing
### 1.2 Simplify Request/Response Models
**Files to Update:**
- `backend/src/models.rs` - Replace string-based fields
**Current (Complex):**
```rust
pub start_date: String, // YYYY-MM-DD format
pub start_time: String, // HH:MM format
pub categories: String, // comma-separated
pub attendees: String, // comma-separated
```
**New (Simple):**
```rust
pub dtstart: DateTime<Utc>,
pub categories: Vec<String>,
pub attendees: Vec<Attendee>,
```
**Benefits:**
- ✅ Remove ~50 lines of manual string parsing in handlers
- ✅ Better type safety
- ✅ Automatic validation
## Phase 2: Enhanced Functionality (Medium Impact, Medium Risk)
### 2.1 Add Rich Attendee Support
**Current:** `Vec<String>` (just emails)
**New:** `Vec<Attendee>` with roles, status, RSVP
**Benefits:**
- ✅ Proper meeting invitations
- ✅ RSVP tracking
- ✅ Role-based permissions (Chair, Required, Optional)
### 2.2 Structured Reminders/Alarms
**Current:** Simple reminder minutes
**New:** Full `VAlarm` component with actions, triggers
**Benefits:**
- ✅ Multiple reminder types (email, display, audio)
- ✅ Complex trigger patterns
- ✅ Better CalDAV compatibility
### 2.3 Geographic Location Support
**New Addition:** `GEO` property for latitude/longitude
**Benefits:**
- ✅ Map integration possibilities
- ✅ Location-based reminders
- ✅ Travel time calculations
## Phase 3: Advanced Components (High Impact, Higher Risk)
### 3.1 Add VTODO Support
**New Component:** Task/To-Do management
**Benefits:**
- ✅ Unified calendar + task system
- ✅ Due dates, completion tracking
- ✅ Priority management
### 3.2 Add VJOURNAL Support
**New Component:** Journal/diary entries
**Benefits:**
- ✅ Meeting notes integration
- ✅ Daily journaling
- ✅ Full calendar suite
### 3.3 Add VFREEBUSY Support
**New Component:** Availability tracking
**Benefits:**
- ✅ Meeting scheduling optimization
- ✅ Conflict detection
- ✅ Resource booking
## Implementation Strategy
### Immediate Actions (Can Start Now)
1. **Add compatibility layer** in existing `CalendarEvent` to support new fields
2. **Implement conversion functions** between old/new structures
3. **Update backend models** to use DateTime instead of string parsing
### Quick Wins (1-2 hours each)
1. **Replace string date parsing** in `backend/src/handlers.rs`
2. **Add missing DTSTAMP** to all events (RFC compliance)
3. **Convert categories/attendees** from comma-separated strings to vectors
### Medium Effort (3-5 hours each)
1. **Unified event structure** across frontend/backend
2. **Rich attendee management** with roles and status
3. **Structured alarm system**
### Long Term (Future enhancements)
1. **Full VTODO implementation**
2. **VJOURNAL support**
3. **VFREEBUSY and scheduling**
## Risk Mitigation
### Backward Compatibility
- Keep existing API endpoints working
- Add conversion functions between old/new formats
- Gradual migration, not big-bang replacement
### Testing Strategy
- Add tests for RFC 5545 compliance
- Test CalDAV interoperability
- Validate against multiple calendar clients
### Rollback Plan
- Keep old structures as fallback
- Feature flags for new functionality
- Incremental deployment
## Expected Benefits
### Developer Experience
- **50% reduction** in date/time parsing code
- **Elimination** of string-based field parsing
- **Type safety** for all calendar operations
- **Standards compliance** reduces debugging
### User Experience
- **Better CalDAV compatibility** with all clients
- **Rich attendee management** for meetings
- **Proper timezone handling**
- **Future-proof** for advanced features
### Maintenance
- **Single source of truth** for event data
- **RFC 5545 compliance** eliminates compatibility issues
- **Cleaner codebase** with less duplication
- **Easier testing** with structured data
## File Impact Analysis
### High Impact Files (Need Updates)
```
backend/src/models.rs - Replace request/response structs
backend/src/handlers.rs - Remove string parsing logic
backend/src/calendar.rs - Replace CalendarEvent
src/services/calendar_service.rs - Use unified structures
```
### Medium Impact Files (Minor Changes)
```
src/components/create_event_modal.rs - Update form handling
src/components/event_modal.rs - Display enhancements
backend/src/lib.rs - Add new modules
```
### Low Impact Files (Minimal/No Changes)
```
src/components/week_view.rs - Just use new event structure
src/components/month_view.rs - Just use new event structure
styles.css - No changes needed
```
## Next Steps
1. **Review this plan** with team/stakeholders
2. **Create branch** for RFC 5545 integration
3. **Start with Phase 1.1** - Core structure replacement
4. **Implement conversion functions** for compatibility
5. **Update one handler at a time** to reduce risk
The integration will significantly simplify the codebase while adding professional-grade calendar functionality!