I'm building a project with taskchampion and just absentmindedly tried to pass around a Task over a serialization boundary (in this case, JSON), when I noticed that it does not implement either of the typical serde traits (Serialize and Deserialize).
Would it make sense to either provide a "view" over a Task (e.g. ReadOnlyTask or similar) that would implement these traits, or to implement them over the types directly?
I noticed that for Task there are some fields for which this might not be trivial, but for TaskData at least it appears that the derive macro should be able to handle it out-of-the-box, since it's basically just a uuid::Uuid + HashMap<String, String>.
I understand that the aim of the library is for direct manipulation of tasks via this storage layer, but this change would also enable users of the crate to use the same types for end-to-end communication. For example, being able to list pending tasks in a request to a backend, and then send a request with Operations already correctly encoded for it 🙂
I'm building a project with
taskchampionand just absentmindedly tried to pass around aTaskover a serialization boundary (in this case, JSON), when I noticed that it does not implement either of the typicalserdetraits (SerializeandDeserialize).Would it make sense to either provide a "view" over a
Task(e.g.ReadOnlyTaskor similar) that would implement these traits, or to implement them over the types directly?I noticed that for
Taskthere are some fields for which this might not be trivial, but forTaskDataat least it appears that the derive macro should be able to handle it out-of-the-box, since it's basically just auuid::Uuid+HashMap<String, String>.I understand that the aim of the library is for direct manipulation of tasks via this storage layer, but this change would also enable users of the crate to use the same types for end-to-end communication. For example, being able to list pending tasks in a request to a backend, and then send a request with
Operationsalready correctly encoded for it 🙂