2008/3/11 Ivan Krstić <[EMAIL PROTECTED]>: > On Mar 12, 2008, at 12:21 AM, Samuel Klein wrote: > > That works for a small group tweaking a large database. > > How is that not appropriate for each user's personal dictionary?
Having separate activities for maintaining personal and highly-collaborative dictionaries is fine. Jameson was talking about a school collaborating together on a dictionary over time. > > For any (initial) corpus, at some point user modifications are > > significant. > > Even 500 words out of, say, fifty thousand is not very significant > when it comes to making the choice about backend implementation. 1% is not so significant. In the long-term collaborative use case, at some point users have touched every word in a dictionary and added new ones. > > Consider many users revising a small database. Do they have to share > > updated corpora and "recent modifications" separately, as database and > > overlay files? > > That strikes me as fairly much optimal, yes. Is there a problem with it? Not as long as the modifications remain small, and someone regularly updates and shares a patched corpus. > > For speed, why not have a constant database that is checked on reads, > > and perform slower queries on "edit" / "update cached term" / "update > > all"? > > I don't know what this paragraph means. Instead of a (static core, dynamic overlay) where the overlay is most-recent and checked first, you could use a (dynamic core, static cache) where the core is most-recent and the cache stale and possibly incomplete, but checked first unless the user tries to edit or asks explicitly for an update. SJ _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
