Le 31 mars 05, à 14:35, M. Uli Kusterer a écrit :
Hi,
one thing I always found confusing about Etoile was that it seemed to
"overload" certain terms that already had a meaning in GNUstep... So,
I thought I'd humbly request that we maybe set down a little
terminology dictionary that we try to stick to, to avoid confusion.
True :-) but when you spend lot of time to think, you twist words in
various way to fit your needs.
In particular, the term "role" recently came up, which, in the
Info.plist, is either "viewer" or "editor" and decides whether a
document of a particular type is imported as an untitled document or
opened for read/write access directly.
Well, role notion with "viewer" or "editor" values is just a very
restricted interpretation when you think about "role" idea we use
usually in real world; Nicolas is just proposing to abstract what this
term truly means in order to broaden its use in a convenient way.
Nicolas proposal could be put in relation with Responsability Driven
Design were objects in OOP are explained in terms of :
- roles
- collaborations
- reponsabilities
With this comparison, our "role" notion looks now like "key objects
pushed with their roles into user experience area".
We select UI objects to be explained in term of roles on the user side
: that's just restricting the fact every object has a role on the
developer side, and you can replace an object by another with identical
role thanks to encapsulation ;-)
Notes on RDD :
http://ide.roard.com/wakka.php?wiki=ResponsabilityDrivenDesign
Mails archive on "roles" notion :
http://lists.gnu.org/archive/html/discuss-gnustep/2004-02/msg00279.html
https://mail.gna.org/public/gnustep-ui/2005-02/msg00045.html
I have just added a Glossary page on the wiki :
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=Glossary&action=edit
Feel free to complete it. (You need to ask me for an account in order
to edit it)
The "context" notion I currently use to talk about linked pieces of
data like file system, model objects network etc. is not very clear… I
just wrote about it in thread "The plan":
« 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
»
I think "Service" was also a term that was sort of used ambiguously.
Could someone (probably Quentin) maybe provide an explanation of what
these terms mean, whether he means them to extend the existing
concepts in GNUstep (and if yes, how)? If they're actually different,
it may help to give them a different name and stick to that. Otherwise
there will be mix-ups that could cause people to do a lot of work that
then has to be thrown away.
Service is a really interesting example. For example, "component" has a
lot of widely used meanings (I will try to find some time to write on
this topic later) but the situation is probably even worse with
"service".
but…
My idea was to replace "Application" by "Service", mainly why:
- Application is written and used like a static and monolithic tool (in
its widely accepted form).
- Service is used to qualify what an object can provide to other ones
through messaging… NeXT moved this notion to higher level (aka
applications level) to talk about inter-applications communication with
eventual transformations applied on exchanged objects.
- Service in everyday use just means "Functionality provider"
- Application induces "Transformation" idea (when you consider Maths or
verb "to apply"), that's not always true
- Application isn't a really friendly word when you explain it to
people who use a computer for first time (yes it is strange to say that
:-), Service convey identical idea more clearly in my opinion.
Tomorrow is about "Decentralization" and "Protocol" (I read it everyday
then I think it's may be true ;-); new stuff like webservices could be
seen as a good illustration. Well webservices are very tailored
applications (from the user side) which need host applications to be
executed… Precisely the idea behind ComponentKit is to have an
Application/Component duality in order we could run component as
standalone application or as bundle/component loaded in whatever
application you are using .
At some point in future, I would like to see "NeXT services" refactored
within ComponentKit under component notion. Now I can state Étoilé
Services notion consist mostly in moving "NeXT services" idea to higher
level once again.
NeXT services would become just "subservices" or "child services"
proposed by "Top services" which are commonly called "Application".
There is a possible connexion with "roles" idea here : "Services"
concept could be eventually be hierarchical by having child services
which own other child services etc.
Now we would have mainly two application-like objects:
- Services <-- A host application which cannot be used as a component
in other applications
- Service components <-- A component which can be used as "classical"
component in other applications or as a standalone application
(eventually hosting components)
The later would be the more widely used form.
Now the problem is to decide whether we stick with "Application" or
"Service" word, or probably better look for some new term which
translates more clearly this "Service" notion as I exposed it.
May be we can stick with "Application" until we have our effective
component implementation, then we could shift to some new term.
Last comment:
I aim to avoid "meta" vocabulary as much as possible : to take an
example, I would prefer to talk about attributes rather than metadatas,
but I admit "attribute" or "property" words are colliding with their
use in OOP.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
