Le 1 avr. 05, à 02:02, Quentin Mathé a écrit :
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
yes. Anyway, adding serialization to an object isn't difficult, so I
don't think it's a problem.
First step is to support shared components, next step will be live
components which is way more complicated.
Yes. We need to start "small" and have a running environment (kinda
like first versions of KDE/GNOME)
-- waiting for completeness won't bring us anywhere.
- 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.
hm, I'm still not sure why hierarchy would be automatically needed --
key/value is probably enough..
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 ;-)
Well, It's surely possible to 1) create an ObjC-like language 2) have a
runtime for it 3) plug it into StepTalk. But frankly.. it's a lot of
work for no real gain !! Plus, I'm not sure it's really useful -- it
would be better to use an existing language.
What we should do, if possible, is to add Python and Ruby modules to
StepTalk. I had a quick look into Ruby embedding doc, and I think it
shouldn't be too complex to create a StepTalk Ruby module (I'm not
saying it would be super-efficient, but a basic implementation doesn't
look difficult). Duno for Python, but it's likely to be easy too.
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.
Yes, I think it would be great. As applications already expose their
objects to StepTalk, it's probably best to put that on the StepTalk
side.
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
It would have the benefit of beeing one DB .. duno.
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
