Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes: > On 6/24/2019 9:02 AM, Nguyễn Thái Ngọc Duy wrote: > ... >> +void jw_object_stat_data(struct json_writer *jw, const char *name, >> + const struct stat_data *sd) > > Should this be in json_writer.c or in read-cache.c ? > Currently, json_writer.c is concerned with formatting > JSON on basic/scalar types. That's an interesting question. In the longer run, is it reasonable to assume that the current callers of these functions will stay to be the only places that would want to say "For this path, various attributes like timestamps and other stuff are these values"? The answer is probably no. Would it be reasonable to assume that the future callers are all likely to be closely related to what functions that are currently in read-cache.c do and would appear only in that file? I think the answer would also be no. Functions in entry.c may want to report "I've created/updated these filesystem entities and their stat info now look like so", for example. So (assuming that we would want to represent "struct stat" the same way no matter who wants to write it out), I think it is reasonable to have this function on the json side, not on Git side. I do not think it is a bad idea to have a layer that sits above json-writer.c and below read-cache.c that give us standardized mapping from in-core objects (like "struct stat") to objects in json (they are set of key-value pairs after all). Call it json-schema.c or something? What other "higher than scaler" types do we foresee that we'd need to serialize in a standardised way? If we do not have that many yet, perhaps a split like that might be a bit premature and we can start by having the function in json-writer.c side, not in the API consumer side. Thanks.
