On 6/7/05, Alex Perez <[EMAIL PROTECTED]> wrote: > Nicolas Roard wrote: > > Hi, > > > > I'd like more infos/discussions about CoreObject... > > Ignorant Question: How is CoreObject different from Apple's CoreData? > They seem very similar in many respects. Why reinvent the wheel?
Ok, well in fact I misunderstood what was CoreObject, apparently. After discussing with quentin, I would describe CoreObject as sort of "corba light" for sending messages to objects, not particularly tied to Objective-C, and with a more dynamic approach than Corba and similar techs. What confused me is that at least originally CoreObject was also supposed to handle object persistency. Now, quentin wants more to focus on the messaging part, and personally I'd like to have a stint to implement the persistence side, closer to what I was describing in my original email (eg, a DataStore). Ideally I'd like something like WinFS, functionality wise. As obviously it's a lot of work I won't do that (well not at once) but I'm trying to see what subset I can implement that can later be extended part by part, and particularly, what would be the best way to use such a datastore while still having a normal filesystem. What I'm thinking at the moment is to have the datastore managing documents/objects (eg, like a directory containing all the objects). The objects will be stored as bundles. In the simplest case, an object will be a directory containing 3 files: object information (type, name, paths..), data and metadata. Ideally then the datastore would be improved to handles "structured" objects, so an object containing other objects (so, not a "data" file, but a "data" object/bundle). With that, it at least let us easily add metadata. And then, extend that scheme to handles versioning is easy -- just add directories for each new version... Objects would have unique ID and references to objects will just use that ID. In addition to such a "flat" datastore, we can then create hierarchy containing objects, so you could reference an object by a path. The paths (you could have multiple path referencing a same object) will be stored in the "object information" file in the object bundle. Ok, so that provides us with a very simple datastore. Now, how can we mix such a datastore with the normal filesystem? well, what can be possible is to have a special file (say, with a .managedObject extension) containing the object ID. The filemanager, when you click on such a "managed object" will query the datastore with the ID to get the object type, and then launch the appropriate application/component. The application will need to be "datastore aware", although it should be fairly straightforward to have applications "updated" to handle that. Obviously the goal is that all étoilé apps will know the datastore. Possibly having a subclass of NSDocument dealing with it transparently for instance, with additional methods to query specific versions or metadata. In addition to .managedObjects, we could also have other objects to represent categories/projects, that the filemanager "understand" -- eg it will query the datastore to show the content of such items instead of querying the filesystem. On top of that, the DataStore should use LuceneKit to do its indexation, to do quick search; and it should probably let you query objects by creation date too (eg browse by "something I did last week"), type, etc. Here I just described the simple case where the object data is still a blob (an opaque binary file), but something that would be neat would be to have structured objects -- instead of having the data serialized in one big blog, you'd have it containing other "managed objects". And then, again ideally, the application will describe the object structure via a schema, so developers could browse the datastore, browse an object directly in the file manager and have additional infos about the different fields.. To finish this pie in the sky plan, you could have translators to get objects/files in and out the datastore. So.. obviously, it's quite a lot of work if you consider everything; but if we (I?) start doing the basic things, eg a datastore which will handle unique objects, then handle metadata and versioning, all relying on a structure of files and folders on the actual fs, it's not that complex (famous last words). Comments ? ps: it's not a pure, perfect, ideal solution; it's obviously limited to applications that are aware of it. But it has the merit of (at least from my point of view) beeing quickly implementable and provide us with a start; in the end, perhaps we'll be able to change the datastore backend to use directly a database instead of the rough solution of using files and folders, or even better, use reiserfs plugins (or something similar)... but in the meantime we'll have something to play with and do our tests and refine an API... ps2: it looks very similar to WinFS or even GNOME Storage, but that's a feature, not a bug. Why not using GNOME storage, at least libStorage ? well... why not... but it needs GObjects.. and it's not very active.. and furthermore the storage part isn't complex to do.. so I don't know. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke
