Le 28 mai 06 à 03:27, Hubert Chan a écrit :
Sorry for the late reply. I'm just starting to get back into
GNUstep stuff...
On 2006-05-06 09:30:54 -0400 Quentin Mathé <[EMAIL PROTECTED]
internet.fr> wrote:
- FileManager == GWorkspace? or it's going to be rewritten from
scratch?
Rewritten from scratch for two reasons :
- it doesn't match Étoilé ideas
- its design and code are overly complicated and not always clear
(broken
MVC, high coupling between classes) imho
There is an experimental Workspace in /Services/Private/
Workspace, but it's
based on a port of Filie which was really well written. The last
time I
worked a bit on it in Spring 2005, my integration was still very
buggy, I
stopped working on it because I thought ExtendedWorkspaceKit
design was
wrong.
Just wondering how you think ExtendedWorkspaceKit design is wrong,
and how you think it should be designed. I started writing my own
file manager a while ago, before I came across Etoile, and I
thought it would be better to help out the Etoile file manager if I
could.
Well, I think now ExtendedWorkspaceKit shouldn't try to reimplement a
Unix-like VFS with objects granularity, but rather be based on
CoreObject one providing simple interactions :
- move
- copy
- link
- store (save)
- restore (load)
- do (for forwarding/sending a message)
That means to remove EXVFS.h, EXVFSHandle.h, EXFileManager.h (since
file manager API is going to be bridged directly at CoreObject level)
and EXWorkspace.
EXContext should also be simplified to be just a subclass of
CoreObject COCoreObject and it could be better to rename it
EXCoreObject (or EXPersistentObject) I think… this terminology
"context", "entity context" should be probably replaced by a simpler
one; "entity" was used to mean either "folder", "virtual folder" or
"search results" notions . "node" or "group" are surely more accurate
terms than "entity".
We have to remove also the VFS splitted class cluster :
- EXVFS.h front
- EXVFSBack.h backend and its current subclasse EXGNUstepVFS.h
The point of this front/backend model was to allow several backends
to be used at the same time (like host FS, FTP etc.). The front part
was created to handle virtual objects and make the class cluster
invisible.
I precisely don't like now this whole VFS stuff in the framework.
In CoreObject, I'm working on using a single class COObjectServer
which implements a VFS-like protocol (COTranslator)… When an
operation is requested on this object server, it checks whether it
needs to delegate it to another object server by checking a
translator table (mapping namespaces to object server classes).
This is a lot simpler and more flexible (specially when you consider
the fact, object servers can be either proxies or local instances).
Finally I think the indexing/searching part of ExtendedWorkspaceKit
is fine, it's just need to be bridged with LuceneKit (may involve
some minor LuceneKit API tweaks, but it should be fine since we
already discussed it with Yen-Ju). Herea are the two LuceneKit classes :
- <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/
LuceneKit/Headers/LCIndexManager.h>
- <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/
LuceneKit/Headers/LCIndexManager.h>
The remaning parts to add are :
- project/user sessions related facilities
- system interaction support (log in, log out, hardware notifications
for stuff like power, medias, FS)
- IconKit integration
- document support (by extending NSDocument)
Then later would be nice to have :
- versioning (not sure that should be handled at CoreObject level)
- CoreData integration (in a bundle), interesting to automatically
handle persistent objects indexing or versioning
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
