monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] encapsulation branch


From: Thomas Keller
Subject: Re: [Monotone-devel] encapsulation branch
Date: Fri, 20 Apr 2007 00:21:00 +0200
User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326)

Markus Schiltknecht schrieb:
> Hi,
> 
> as you might have noticed, I've done some work in
> nvm.experiment.encapsulation. Based on Zack's idea, I've removed the
> app_state from lots of functions and objects. This has two reasons:
> 
>  - reducing the amount headers included
>  - allow for read only database functionality (which is enforced by the
> compiler)

I like the idea. One question though: if we look at certain system
entities, like a database or a workspace as single entities, and no
longer in terms of a global, single "app_state" object, would it be
possible (in general) to make these exchangable easily?

What I was thinking of here is automate stdio, which, once started, runs
on exactly one single database / workspace, and this is determined
during initialization. The basic problems here are

a) one cannot load another database or workspace within one and the same
stdio process (workspace is problematic because of path initialization
AFAIR)
b) if a) is not a real problem for many people because they like to
start a separate process for every workspace / database anyways, one
still does not know if the workspace or database is a valid one for the
running monotone instance _until_ you trigger commands which use them.
If a database or workspace is loaded deferred, i.e. with a separate
automate command, it could explicitely fail if something is wrong,
rather than implicit as it is now.

Thomas.

-- 
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.thomaskeller.biz
> Music lyrics and more: http://musicmademe.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]