Re: [MirageOS-devel] Irmin API evolution

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> I'm currently experimenting with adding a "connect" method to BC so
> that you connect to a repository first, and then use that to get
> additional branches:
> 
>  https://github.com/mirage/irmin/pull/275

I've added some comments to that issue. I'm mainly in favor of the change.

> One problem I have is with the task-maker functions that get passed
> around everywhere.
> 
> Currently, you specify the task-maker when you open a branch. You then
> pass a value of the appropriate type to the response to get the store,
> e.g.
> 
>  let task_of_msg x = Irmin.Task.create ... in
>  Store.create conf task_of_msg >>= fun store_maker ->
>  let store = store_maker "unused string" in
>  Store.read store ...
> 
> I think this API is pretty strange and confusing anyway, but it's a
> particular problem for sharing connections because we don't want to
> create a new connection every time the user wants a new commit
> message.
> 
> I know this design came out of previous discussions:
> 
> http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00154.html
> 
> But I'm not really clear on what the original aims were and whether
> the current design meets them (it looks like it was intended to convey
> some other context, but now it's just the commit message).
> 
> The problem is that my BC.connect method shouldn't take a task-maker
> argument, but internally it needs to create the various backing stores
> (contents, node, commit and tag) and these currently require a
> task-maker.

The trick to solve that problem by putting the connection in the closure. See 
https://github.com/mirage/irmin/blob/master/lib/git/irmin_git.ml#L157 for 
instance when the Git handler is created outside of the closure which is 
returned to the user, so this is shared on every invocation of `t`.

> [ And ideally, it would make more sense to me if you only specified
> the commit message when making a commit. The rest of the strings just
> get thrown away, I think. ]

The initial idea was to use that task to (i) populate an audit log on all the 
database operations (including reads) and (ii) attach the debug messages to the 
task, instead of throwing them on the error channel. None of these have been 
completed yet, but would be nice if they are still possible to do later.

Thomas
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel