Le 7 mars 05, à 21:41, Stefan Urbanek a écrit :
Hi
The talk about document oriented environment reminded me something ...
what we are missing is cooperation between tools and applications. They
simply can not talk to each other! Why? Because developers are selfish
and are not creating any interfaces to their codes. Ok, except library
developers.
We get back to the protocol related issues, we would need real "Glue
protocols" to allow applications to talk between them or to be easily
scripted, the problem is how to write theses protocols to allow rich
applications interaction (without real work on developers side) and to
let the developers flexibility in their implementation design ?
For theses protocols, it is a choice between the words "fuzzy/flexible"
and "detailed"…
How it should be? Instead of creating an application, create a
framework. Self-sufficient application should be considered a prototype
and proof of concept for given functionality. Application should be
only
an user interface for a framework. The application should be as thin as
possible.
I fully agree, we discussed this in the past with Nicolas (on Backbone
list I remember to read related things also).
With this attitude, the developer creates a framework - perhaps a
derivate of the prototype application. On top on this framework other
developers can build:
- an application - interaction between user and the framework through
UI
- command-line tool - interaction between user and the framework
through
terminal; scriptability of the framework (and therefore of the
application)
- scripting environment - glue functionality of the framework with
others
Moreover, the framework should be split into two: UI and non-UI part.
hmm probably. For documents applications, theoretically as you explain
it would be good to have two frameworks :
- the first to manipulate "document model"
- the second to implement "document display"
The first framework could be used to avoid the need to reread the
document model when you are editing a composite documents and you
switch to whatever new editor application in order to edit another part
of this document. (Not very easy, unless we have a standard and
versatile data source protocol may be…)
With this approach, which is nothing more than reversed point of view
on
certain elements in a system, a document focused environment can be
created more easily. Why? Because everything in the system is able to
cooperate - frameworks have interfaces for the outside world.
Thoughts?
True, but difficult to implement in really efficient way on both user
and developer side :-)
Well…
That's the Étoilé plan for the future but not immediately because of
unfinished state of GNUstep, legacy applications and Cocoa
compatibility in my opinion… Moreover it is very difficult to do it
right because we probably need some kind of standard protocols, in
order to allow real applications interaction, easier development as I
have outlined in my first lines… Applications developers shouldn't
reinvent the wheel for its own framework API. May be such move would
involve important changes to AppKit, but I'm not sure ?
Without API draft and explanations of the implementation, it is
difficult to know how we can achieve that I admit… May be you have a
more precise code idea which would make clearer how we could implement
such architecture ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
