Le 28 mars 05, à 21:30, Nicolas Roard a écrit :
Hi everybody,
I was thinking about the project, and how it could be a good thing to
have a well-known, public roadmap, and a clear vision of what we want
to achieve, and how. The Wiki
(http://www.dromasoftware.com/etoile/mediawiki/) is interesting, but
I'd like to synthetise our plan.
There is a basic roadmap here :
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=Planned_development
We need to write a TODO list with various fine grained tasks I think.
Warning: it's long.
I'm ready… :-)
Étoilé wants to be a desktop. But, an innovative desktop -- there's no
point of redoing KDE and GNOME -- we are not enough people at the
moment to be able to catch up, and KDE/GNOME already works "well
enough" for most of the users.
Not sure of this point, but I like the fact you put "well enough"
between quotes. ;-)
What would be a good desktop then ?
A) components, cooperation and sharing
1) existing mechanisms
I think that one of the main point of a good desktop would be good
cooperation between the applications/components. It's better to have
applications/components doing only one thing, but doing it well,
cooperating with other applications, than to have huge, bloated
applications that do everything in an average way.
Yep, thin applications with framework based backends probably and which
were built to live in our components ecosystem.
How can we do that ? well, there's different possibilites. Using
GNUstep already gives us a lot of mechanisms for cooperation:
pasteboard, services, filters..
NeXTSTEP showed how the pasteboard could be the central communication
bus for exchanging data between applications. We should build on top
of that and encourage theses mechanisms.
First we should hack this with what we have.
Later we will need to unify pasteboard, services, filters, stored
objects etc.
Frameworks not written currently like ComponentKit, PickDropKit,
ExtendedWorkspaceKit (this one is partially written :-) will be
developed to support such role.
2) proposed additional mechanisms
On top of the current mechanisms, we probably want to add things like
"roles" (where you could identify roles in applications/components and
call / use roles instead of application -- hence providing a good
abstraction over which actual application / component will do the
job), "programmable services" (ie some kind of registry for services
callable using distributed object), a more powerful filter system, and
of course NSDataLink/Linkback for embedded documents edition.
This "Roles" idea would fit with various objects like applications,
components, but I would like to have it combined with "rich data types
support". I outlined this point in Workspace page
http://www.dromasoftware.com/etoile/mediawiki/index.php?title=Workspace
under "Advanced file types support" subsection.
An old opinion on metadatas topic which really enlightened me few years
ago (include explanation on "rich data types") :
http://www.igeek.com/articles/Interface/FileorTypeCreator.txt
3) scriptability : one virtual object environment
Another aspect is of course easy scriptability of the environment --
ideally we want to provides the illusion of cooperating objects over
applications. Exactly what StepTalk does : Étoilé applications should
have a good StepTalk support.
I think we should have StepTalk packaged by default with Étoilé in
order to promote such evolution.
4) sharing
Another important part in a good desktop would be an emphasis on Once
And Only Once : databases must be shared across applications (things
like the adressbook, the bookmarks...). The user should not have to
type/enter informations more than once, as a general rule.
This idea is also true for sharing components among programs as much
as possible. Providing Gorm palettes for components would be nice !
True.
It is difficult to know how we are going to be able to support
components within Gorm until we have drafted related frameworks.
B) Documents
1) Throw out the application centric point of view when it's applicable
We should try to provides an interaction model more directed toward
documents than toward applications. What I mean is, whenever it's
applicable, we should put the document first and the applications
second : the user don't want to "start OpenOffice" but he wants to
create a letter. For that, we need to provides an easy way (interface)
for creating documents; for example, applications creating documents
register to the system and that information can be used to present the
user a choice of all the available documents (s)he can create.
We should ask us here which application will host document pieces and
be used to layout them :
- every ComponentKit enabled applications
- Workspace application
- special document layout application
May be on choice is more easy to implement first and later we could
move to a different choice.
On the other hand, not every applications deal with documents (for
example, an FTP client), but overall documents are really important.
Yes.
2) Searching documents
If the documents are central to the user, something needs to be done
to help the user order and search its documents. LuceneKit will
probably be very helpful here. Perhaps we should just impose a
metadata-enabled filesystem such as ReiserFS ? remember, we shouldn't
care about compatibility..
I'm not against possibility to make a special FS like ReiserFS a
requirement, but we should keep a compatibility mode even limited when
ReiserFS isn't available (on some OS where has hasn't been ported).
To have a powerful search system à la Spotlight or Beagle we need to
think :
- metadatas database
- content index database
LuceneKit provides the later.
For metadatas database, iirc the problem is ReiserFS has metadatas
support (aka EA) but doesn't index them unlike BFS, then search is very
slow… but may be we can extend ReiserFS with a plugin to support
indexation (ReiserFS has a very flexible plugins architecture).
To have the complete search system, you need to add a daemon monitoring
file system changes and search tool with well done UI for the user. We
need to make very easy for applications developers to integrate our
search engine in their applications and documents/datas/objects theses
applications handle.
http://www.gnome.org/projects/beagle/
http://www.apple.com/macosx/tiger/spotlight.html
I have put some notes on such search system for Étoilé under FogVision
nickname here
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=ExtendedWorkspaceKit
Other User Interfaces ideas (Beagle?) for enabling search by creation
date ("I did that one week ago" are also worthwile. I think we could
modify NSDocument to provides some of theses things.
I don't understand why NSDocument is related to this date translation
support, any files on your computer have a date (NSFileManager is a
more relevant choice with other classes may be).
3) Versioning
In addition to search/order documents, one important and nearly always
forgotten aspect is the document versioning problem. We should
provides tools/frameworks for that ! it's a shame that the user either
does the versioning "by hand" (using multiple copies) or using a
versioning system not integrated to its tool ...
Yep. This could be plugged into PersistentObjectKit, may be not in
first iteration however.
My idea is to move ExtendedWorkspaceKit from its current POSIX semantic
to a Stored Object FS semantic (a bit like
http://sope.opengroupware.org/en/sope_appserver/ofs.html aka SOPE
Objects File System), then versioning could be supported more
conveniently with "objects oriented diff" and not "big files oriented
diff", especially when combined with CoreData clone and
PersistentObjectKit… but I need to think more about this topic.
I think it is probably better to replace the "context" term I use in
ExtendedWorkspaceKit and Étoilé wiki, with "Stored object" or
"Persistent object" term, they sound more explicit and don't induce
possible confusions with graphic context notion.
What do you think ?
I talk about contexts here for example :
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=CoreContext
I took this context notion from LibFerris project
http://witme.sourceforge.net/libferris.web/ I planned to use initially…
Versioning possibility (back to a previous link ;-) :
http://www.igeek.com/articles/Interface/FileorTypeCreator.txt
C) Network / Communication
In thoses days of Internet, we should have a core communication
framework. "Persons" should be first-order object in the UI -- you
should be able to drag'n drop something on your friend's icon to send
it to him. Different communications mechanisms exists : we can use
distributed objects, applications (mail, ftp..), jabber, soap or
xmlrpc, etc.
No objections. :-)
Having a generic communication/transfert framework would be
interesting -- an application could just do "I want to send that to
this" and the framework will relay the demand on the available
applications (in case of a person, we could check its adressbook
entry, and depending on the entries, propose to send by mail, by
jabber, etc).
Would be very nice, but I don't know what protocol we should use and
how to do it precisely. You have a more precise idea ?
C) The Desktop
3) filemanager ?
We'll provides a file manager (the one quentin is working on). But
using the "roles" ideas, we should be able to work transparently with
other file manager/desktops (as long as they answer to the "role
protocole").
Yep. Workspace application I'm writing currently is derived from Filie
http://www.zathras.de/angelweb/filie.htm
Special thanks to Uli ;-)
4) Documentation
Documentation is really important -- Étoilé applications should have
good online help. I expect to be able to work on HelpViewer in a
couple of weeks and commit it to the cvs.
Many people are waiting for new HelpViewer release so it's good news.
D) Roadmap ?
Thankfullly, a lot of what I have explained is implementable now using
GNUstep, it's more "rules" to abid to than whole new developments.
Though, there's of course new developments needed, apart applications.
I'm still unsure about the roadmap, which is why I'm requesting inputs
here :-)
Any other inputs would be welcome… I'm probably not objective ;-)
I think the "roles" idea / service registry is central enough to be
implemented soon, and will let us experiment a very flexible desktop.
Would be nice if you or someone else could write a proposal draft (with
some pseudo code examples, etc.)
E) Development tools
Étoilé's goal is to provides a desktop. But we should provides
development tools if they are helpful. For example, we have
UnitKit/UnitTests on the cvs, and we should use them as much as
possible (ie, it's strongly encouraged !). A framework implementing
High-order methods would also be a nice thing to have "by default".
etc.
UnitKit is going to be default unit testing framework. I think we
should probably require to have it used for new development.
For High order messaging, there are several possibilities I like :
- Marcel Weiher HOM implementation which is already compatible with
GNUstep but I need to test it really
- CHOMp which is a new HOM implementation
I like them because they are giving most advantages of blocks without
new syntax extensions and highly conceptual scheme… In future, when I
will find some times to work on TrackerKit which intends to implement
powerful APL model based on KVC, HOM will probably be less needed, but
anyway I'm sick to spend my time writing collections iterations ;-)
HOM --> http://www.cocoadev.com/index.pl?HigherOrderMessaging
-->
http://www.cocoadev.com/index.pl?HigherOrderMessagingDiscussion
CHOMp --> http://www.cocoadev.com/index.pl?CHOMp
TrackerKit -->
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=TrackerKit
Any opinions are really welcome here…
I wasn't very precise on some points and on the roadmap, but I tried
to put together a good overview of what I'd like in a desktop..
Critics encouraged !
We should put this roadmap summary on wiki a bit more formally.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
