I've put together some patches for ObjectMerging4 that: 1) Add makefiles for GNUstep 2) Fix compilation errors 3) Add primitive value persistence
Please find them attached at: https://gna.org/patch/index.php?2652 Furthermore, I wanted to promote some discussion on OM4. I've identified some issues that come to mind: 1) Object Roots OM4 does not seem to provide a way to separate "core objects" so that you have separate object graphs that cannot overlap - it seems everything in the same repository can reference any other object in the repository. On first thought, this seems to be okay, but it makes it almost impossible to work on the same repository from different processes without a synchronisation or notification mechanism (which I don't think sqlite3 can provide). We need object roots at some point so that we can identify the top-level objects in a users workspace during search. Having a table for them would also help with indexing because we could store the object's type (used for opening it) and the date it was last created/accessed so that we can improve search results (i.e. put more recently accessed objects first in a search). 2) Property storage At the moment we are persisting objects using XML property lists. I think this could reduce the quality of text-based searches, as any search will pick up XML nodes any things like dictionary keys, which shouldn't be indexed. By the looks of things, we could use a custom tokenizer with the FTS (full text search) mechanism (http://www.sqlite.org/fts3.html#tokenizer), but this would be easier if we stored them as old OpenStep property lists. For simple properties, we should probably have a type column that specifies its type, even if we store the value as a string. For this case, sqlite provides almost automatic type conversion, which we could use to our advantage to help make search results more relevant. For example, if the user types in a string that can be converted to a date, we could also do a "date" search on the database against any date-type properties. This will expand the list of relevant results, especially where data is stored in a different locale to the way the user is using it (e.g. different date or number formats). --- Christopher Armstrong carmstr...@fastmail.com.au _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
