Hey Novin!
This is a pretty hefty set of APIs, so I think it's worth doing an "in-person" calibration so you can walk us through it. In fact, we may need more than one.
Before that, though, for the APIs that mirror other APIs that are used in other contexts, the main thing I'd like to take a look at is whether we're sure there needs to be a "mirror API" at all. For example, for incoming/outgoing directory, have we attempted to make the CF libraries more extensible and support other transports? For logging, have we determined that it's not viable for the logging folks to own the definition of the Logger interface, and the driver folks to own an implementation of that interface and a factory for getting one in the "writing a driver" context? At the moment, we're looking at a lot of interfaces that are liable to diverge gradually from their non-driver counterparts.
Assuming we determine that code sharing isn't viable here, then I imagine the council's advice for these APIs would be rather straightforward: match the existing APIs as closely as possible.
For the APIs that aren't mirroring other functionality, would you mind moving them into a smaller number of CLs? Maybe one for testing and one for not? It's just a lot to take in right now
@_@.
It'd also be helpful to have a companion doc that points out some of the more interesting design choices, and any questions you'd like to ask the council during the calibration. It doesn't need to be fancy, it's just to structure the conversation.
Should I try to book some time next week?
Thanks,