On Mon, Aug 12, 2013 at 1:03 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> the radar). Ideally the library itself will have zero dependencies on any > sort of transport layer (HTTP/SSH) and can instead work over an abstract > i/o interface (which is already in place but may not be sufficient - time > will tell). If you have concrete ideas regarding such details, please feel > free to make suggestions. > Back to that for a moment... i'm trying to keep the library as ignorant as possible of i/o. All operations on the db happen in terms of content in memory, not files (at least not at this point). Even though your repo db might name a certain blob "my-file.txt", it doesn't ever have to exist in the filesystem as a file as far as the library is concerned. My goal is to have the core library not deal with any i/o outside of (A) the db files and (B) generic i/o interfaces which take data from or feed data to the user (but the user provides the i/o routines, so the library can use arbitrary i/o channels). For the sake of usability and memory-use, there will need to be at least some core support for working with files (e.g. checking in/out from/to disk instead of memory), but i'm still a good ways away from knowing what that API might eventually look like. Suggestions and bikeshedding are welcomed. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
