Le 31 mars 05, à 16:26, Quentin Mathé a écrit :
Yep, thin applications with framework based backends probably and
which were built to live in our components ecosystem.
Yes. Although, as Sergei and Uli recalled, that's only the "technical
part" -- this is not the main point after all.. eg, the main and really
important point in the end is the user, not the technology.
We need to keep that in mind :-)
But of course, as a rule of thumb, our technological approach would be
small apps and frameworks cooperating together for a better world ;-)
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.
Well, first we need to use what's already there, yes. After, if really
we see it's better, why not try to unify ? but that shouldn't be
automatically our goal -- premature optimisation is the root of all
evil :-)
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
Hmm, this article is interesting, but what's the relation with roles ?
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.
Agree.
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.
of course :-)
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.
"layout them" ? well, sounds quite DTP-centred point of view ! :-D
Could you be more explicit ? (and how it relates with B.1 ?)
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).
ok..
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).
yes, that could be a possibility.
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).
I mean, we could modify NSDocument so that any change/save to the
document is advertised to the system.
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.
A bit like the article you cited about the File cretors/ File id stuff
? Assigning an ID to a document and storing the document in a
directory, with the metadatas ?
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 ?
yes, Persistent Object is clearer.
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 ?
For the communication part itself, I was thinking of XMPP (Jabber)
-- it's extensible, it uses XML, flexible enough..
But for the behavior I describe, we can/should implement that using
roles; ie, an application will add a role "transfert" and the desktop
will thus be able to present all the available transfert
possibilities.. ?
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.)
Yes, I probably should do that, to have something clear.
UnitKit is going to be default unit testing framework. I think we
should probably require to have it used for new development.
I agree. Use TDD, it's nice !
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…
Any of them looks interesting to me. We just need to pick one :-D
pfiou, next time I will post shorter article... too long/messy to
answer each points ;-)
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
