Le 31 mars 05, à 16:21, Nicolas Roard a écrit :
Le 31 mars 05, à 07:29, Stefan Urbanek a écrit :
- 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 serializes objects too. At some point, we will probably need to hack
shared memory support to NSPasteboard mechanism because live shared
data with a 50 MB image relying on current pasteboard implementation is
unrealistic.
Advanced components architecture may need DO tweaked with shared memory
support too -->
https://mail.gna.org/public/etoile-dev/2005-03/msg00024.html
- 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
For sure.
- 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.
Yes
- 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
I don't like so much NSPasteboard API, but it could be worst.
I wouldn't summarize it just by saying "it's easy" and "it's powerful".
;-)
the disadvantages are:
- it will only work for gnustep apps
Not really a problem, we could implement some limited compatibility
with other applications.
- it can be inneficient
We need to do some experiments to know how much we can tolerate.
- it only answer the "communication" problem -- not the "embedding
live component" problem (although, it answers the "embedding
component" problem using NSDataLink)
First step is to support shared components, next step will be live
components which is way more complicated.
- 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.
Yes both.
- 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).
Hierarchy of roles will be needed when we will support rich data types
in order to bind applications to documents. It will be useful too when
we will have true components support, but for our first step with
composite documents (relying on NSDataLink) I think it's probably too
much complexity.
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 ?
Yes.
I would like to have an Objective-C language bundle for StepTalk, I
would say it's possible ?
For people who don't want to learn Smalltalk for example and may be
more importantly to be able to reuse Objective-C code time to time.
I need to dig deeper in 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.
That's light CORBA support in some way but with XMLRPC ?
That could be really 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.
Not sure it's really a good or needed concept
- 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.
Yep.
Components:
- What should be the API for components to be shareable between more
apps?
that remains to be defined :-) -- Quentin ?
:-)
That's the most complex part of Étoilé… I would like to release one or
two early Étoilé version before working really on component stuff APIs.
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).
For application components, I started to list what could be really
useful components. I think this list should be used as a flexibility
check list when we will start to write API.
Application components list here:
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=Service_components
- Should the applications have environment-provided mechanisms for
loading extensions/plugins/bundles/modules?
probably, for loading components.
That's a really tricky part too (taking in account possible
application/component duality), we already talked about this topic in
February.
iirc Stefan you replied to my last mail in the thread "First step
toward document orientation" saying you needed to think more before to
be able to give me a real reply. Have you been able to find some time
to think about it ?
"First step toward document orientation" reference:
https://mail.gna.org/public/etoile-dev/2005-03/msg00024.html
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
