Le 31 mars 05, à 07:29, Stefan Urbanek a écrit :
Hello,
Nicolas, you have started with plan outline and I will continue with
questions. Many of them have obvious answer, however they need to be
explicitly answered.
On Mon, 2005-03-28 at 20:30 +0100, Nicolas Roard wrote:
<snip>
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.
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.
- What are existing mechanisms?
the pasteboard, the services, the filters
- How they work?
mostly they use NSPasteboard as a bus to exchange/transform data
- How are data shared and/or transferred using them and in what form?
using NSPasteboard (so you need to serialize)
- Do we have to serialise objects, make them accessible by shared
memory
or by distant objects or by other ways?
For the moment, serialization/NSPasteboard is enough, but perhaps in
more
complex cases we would like to have shared memory..
distant objects could be another solution, depending of what we want.
- Do the objects have to be written on the disk to be shared or can
they
be shared directly in live application as anonymous objects with known
structure?
they shouldn't need to be written on the disk
- Are those mechanisms currently public or not? Which of those
mechanisms can be made public and how? (for example: exporting handled
pasteboard types of an application and documenting contents of the data
in the pasteboard)
For NSPasteboard, there's a list of common pasteboard type; etoile will
perhaps
some types to that list.
- What are advantages AND disadvantages of certain method? -> What are
methods suitable for and what are not?
Well, if we use NSPasteboard, the advantages are that:
- it's easy
- it works
- it's powerful
the disadvantages are:
- it will only work for gnustep apps
- it can be inneficient
- it only answer the "communication" problem -- not the "embedding live
component" problem (although, it answers the "embedding component"
problem using NSDataLink)
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.
- To what mechanisms can be roles added and how?
A first step would be to have applications exposing their roles.
- How one finds appropriate mechanism for his task - find mechanism
with
given role?
That's what we need to program: some object that will keep track of all
the roles
and call the corresponding application.
- Who will define the roles? Are they going to be
etoile-cetralised/standardised or user definable or both?
probably both I think. Although we should define a lot of them for
etoile.
- Is there any hierarchy of roles? If yes, it is only one hierarchy or
can be there more? Or can the roles be grouped randomly?
I'm not completely sure; I first thought of a hierarchy, but in fact,
it's perhaps
not needed and over complex (we discussed that on irc if I remember).
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.
- How should application advertise its scripting capabilities?
(partially answered)
They should advertise it to StepTalk ?
Actually, something that could be interesting too would be to have
XMLRPC
proxies for the objects advertised -- so anything would be scriptable
directly
from more or less any programming language.
- Where objects of the scripting process live? (not fully solved yet)
What do you mean exactly ? The "remote objects" the script call ? or the
script objects themselves ?
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 !
Databases:
- What standard shared databases shoud be in the environment?
(Addresses, bookmarks, communication (emails, IMs), notes, ...)
In fact, I'm wondering if Addresses/Bookmarks shouldn't really be only
one
big database conceptually.. "bookmarks" are after all adresses; while
with web bookmarks
they are just addresses you keep to visit websites, ftp/scp/webdav
bookmarks are addresses
you can interact with (send information to) -- joining the idea of a
network-centric environment.
- Who defines the structure of the standard shared databases?
- How can be the standard structure customised? (userInfo dictionary?)
I don't think the user will really need to store customised structures
(ie, he won't do it by hand, he'll use an application). And an
application could easily define new formats; An application could say,
I want to store this structure in the database.
Components:
- What should be the API for components to be shareable between more
apps?
that remains to be defined :-) -- Quentin ?
I guess it will depends of the problem domain too -- we'll have
specialized components in addition to general components.. For example,
filtering components working on images or sound..
Also, I must say that using NSDataLink and NSFilter will give us
embedded components for free..
*not* "live embedded components" but I think thoses are not all that
necessary (even if we should have them).
- Should the applications have environment-provided mechanisms for
loading extensions/plugins/bundles/modules?
probably, for loading components.
More questions? :-)
:-)
Thanks,
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
