On Oct 9, 2007, at 2:19 PM, Grant Baillie wrote:
On 9 Oct, 2007, at 12:48, Andi Vajda wrote:
On Tue, 9 Oct 2007, Philippe Bossut wrote:
Also, one could think about addressing performance and
scalability at the repo level, without changing the whole
architecture.
While Chandler was developed with an infinitely scalable and
infinitely fast repository in mind, it might be time to let
reality sink in. The repository has come a long way in terms of
performance and could still be improved, for sure, but coulddn't
one think about addressing performance and scalability at the app
level as well, without changing the whole repository architecture ?
Well, one can think about anything, so sure :). But as things
stand, there isn't really an "app level" to speak of: The
repository is intertwined with everything, and its API shapes the
app layer in ways that aren't always so effective. (The current
indexing situation is one concrete example).
Hmm. I think the repository is pretty separate from the app. For
example, it would be pretty easy to replace the repository as long as
the replacement had a similar API. Changing the API would be a
problem if the replacement didn't provide the necessary features the
app used. It's hard to imagine any data access mechanism whose API
would not affect the code that used the API. Of course, we could
probably improve the API.
The last time I looked into performance, the problems I saw were due
to notification storms and in those cases it was pretty clear most of
the notifications weren't actually necessary.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
