Andi Vajda wrote:
I remember when our original design goal of the repository was as a separate process. The reason for this was that your data could be available even when you weren't running Chandler.
Multiple processes can run against the same repository files, Berkeley DB supports that just fine. So, if you're not running Chandler and want to make your data available somehow, another process for that is still possible. But this does not imply that Chandler has to go through that same process to access the repository, it can do that by accessing the repository files directly via the same Berkeley DB APIs.
Accessing the repository via the Berkely DB APIs would be difficult without the much of the code in the repository, so I think it till makes a lot of sense to package up that code into another process, e.g. in a daemon or service that always runs. So you have the choice of having Chandler share an extra copy of the code or having a single service with a single copy of the code and Chandler accessing the service.
Andi.. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
