Le 10 mai 06 à 22:04, Nicolas Roard a écrit :
On 5/10/06, Günther Noack <[EMAIL PROTECTED]> wrote:
Hi!
Am 09.05.2006 um 01:20 schrieb Yen-Ju Chen:
> Actually session manager will be the project manager for Etoile in
> the future.
Why that?
Considering that the project manager will probably be quite a complex
and experimental application in its first versions, I wonder if it
won't affect the overall Etoile stability if it kills the inherent
session manager on each crash. Wouldn't it be easier to let the
session manager be a minimal tool that is thus mostly bug-free?
What are the reasons both the session and the project manager are
designed to be the same application?
Probably because sessions -- as in, "saved sessions" will be
"projects", for étoilé.
Indeed.
And I'm not sure the "project manager" will be
such a complex application anyway -- most of the action will be in the
frameworks.
I think most of the action will take place in client application
(when they will be requested to store or restore their state). Having
the action in the frameworks wouldn't solve the stability problem
Günther is referring to… Except if the frameworks aren't used
directly by the "project manager" server but the client applications.
Finally even if such frameworks would be linked by the project
manager, I don't think we would have any stability problems. First
because they should be fairly small. Second because I don't think the
project manager should own its client applications as child
processes. By the way when it dies it could try loading its latest
checkpoint state (that supposes it dumps its state regurlaly) and
reconnects every clients wandering around. If it isn't able to reset
everything properly up, it could terminate itself and request its
application clients to terminate.
Anyway, we can start by having a small application that takes a plist
containing a list of applications to start, and start them, why not.
Yes. I think we could have some kind of SystemCore framework to write
such dameon. I should probably improve the code /Services/Private/
System (aka etoile_system, a process similar to launchd), then move
or refactor the code in a framework. I'm not supporting plist reading/
writing at this time from a config file, though Saso wrote similar
code for MenuSever few weeks ago.
But to implement projects we need a bit more than that; it's perhaps
interesting to have the discussion about projects now then :-)
Basically, what do we want with the projects, and how will they work ?
well, here is my take:
1) Think of a project as if it was a "session" -- you have a bunch of
running applications with opened documents, etc -- basically, a
running state -- and you want to be able to a) quit it and b) reopen
it without losing anything, ie, you want to "freeze" everything then
find it back as it was when you come back.
This is rather close to existing "session management" as done in X11,
apart from the reopening document thing / save state which is
half-baked currently.
Yes.
2) You want to be able to have more than one "project" open
simultaneously -- in that view, projects behave like virtual desktops
(and they will probably be implemented like virtual desktops)
True.
Solving 1) can be separated in two things:
- manage the applications: get the list of the running apps before
closing a project, and restart the apps when coming back
- manage the state: do the same thing for the current documents/state.
Solving 2) should not be very hard (virtual desktop already exist in
Azalea), but will still lead to some problems: shall we restart
applications already running (that is, have two copies) or not, etc.
Until now I was thinking it was the main debate point. However my
current opinion would be… we cannot afford to keep processes
sandboxed, I mean 'spawning a new copy of an application per project
session', because the user would try to circumvent the project
workflow logic to bypass 'the stupid application launch time'. When
there is a copy of the desired application already running, the user
would switch from the current project to the application's one,
mostly because the switch time from one project to another will be
almost null, unlike the time penalty of an application launch.
Having separate application copy per project would also mean it would
be impossible to move an open document across project sessions (at
least in a transparent way) and it's quite common in real life to
work on several projects and bringing a document from one project to
the one you're working on.
I will concentrate on 1) for now on; and "projects" for étoilé will be
stored/manipulated, technically, as normal folders, containing a
hidden directory where we can put any kind of additional metadata we
want (so this is where things like annotation will go, and this is
where the information for restoring the state will go too).
So... here is my try to show a possible technical path, please,
comment it !
For actually getting those projects working... we need to to add the
notion of "belonging to project(s)" in the application itself, simply
so that we can send a distributed notification to all running
applications, for a particular project, and get the complete list of
applications. We can perhaps start with adding some methods in
NSApplication for that (or in an eventual EApplication subclass, but
you get the point).
I think the problem isn't really in having applications aware of
which projects they are belonging to, but rather to have a simple
protocol to allow "project related talk" between applications and the
project manager (something less verbose and more fine-tuned than
XSMP). Anyway NSApplication related subclass or new delegates methods
can make the deal.
To know about "belonging to project(s)", Workspace or 'openapp' tool
(or similar) can just pass a request to the project manager when the
user opens either an application or a document, then the project
manager sends a message to the right application (first launching it
if needed) telling it "you belong to me".
With CoreObject nameserver, supposing there is an instance available
per user session, we can store the map application/project directly
in the nameserver. That would make the map public to any
applications, allow to launch applications without relying on the
project manager (applications would just know to update application/
project map) and simplify the protocol further.
Then, if we can properly discriminate which application is in which
project(s), we can implement the first part: stopping them by sending
the quit message, and save the list of running application in our
hidden metadata directory.
Now, we can implement a tool that will be able to take a project, read
the metadata, and restart all the applications.
ok
When that works, we have a standard session-saving management, and we
can move on more interesting/difficult things: saving/restoring the
state. For instance, we can use specific methods warning the
application to save its state instead of using the generic quit
notification.
And that's where we hit other difficulties -- not for implementing the
mechanism in the "project manager", which is fairly straightforward,
but rather, in the applications : saving a running state isn't all
that simple... Yet I think we can provide the developer with some
methods to facilitate it; possibly for example, a lot of work can be
done once and for all for NSDocument-based applications, so that the
developer won't need to bother with it, that will be done
automagically (from the developer's point of view).
Just curious… Can you think of any examples at NSDocument level right
now ?
Ok... so what we can do to try to save the running state (or rather to
approach that) is perhaps to 1) warn applications that the project
need to be serialized 2) ask them if they want to save some state, and
if so, request a list of opened documents and tell the applications to
save them
ok
(or save a delta) in the metadata directory,
Why a delta, it seems to a feature related to versionning rather than
project management ?
and secondly,
ask for a NSData object containing the application "running state"
[more likely, some information that the application will need to
restore something equivalent -- a real, full serialization is perhaps
too heavy].
Yes, but I think in most of cases having a dedicated defaults store
in the project directory would be enough to checkpoint application
related state on request.
Not sure whether or when the project defaults should override user
defaults or vice-versa.
For example, if we take a text editor (and actually I think we
_should_ start with Ink and work from that point), what will it need
to save ? Well, obviously the list of opened documents, and the
current document state as well. A first implementation could be done
by saving the documents directly, a cleverer implementation could take
advantage of the NSUndo mechanism to simply save a delta,..
In theory, yes but pratically I doubt of this mechanism. You never
cover every actions with undo, there is an history / memory
consumption limit for undo. Ultimately it's a lot of work (tricky
often) to have a very broad undo support, yet I'm not saying this
shouldn't be worked out as often as possible.
Then, Ink
will need to save some "state" information -- eg what are the opened
panels, the windows position, the selected font, etc. Some of this
information is already saved in the defaults, by the way, but we need
to save them per-project, obviously.
Yes.
Ok I stop here... I hope I clarified the path we could take to
implement projects in étoilé;
It seems so :-)
obviously things aren't that clean-cut,
and that's why I think we should try to implement that step by step:
first get a "session management" working; then add the "belonging to a
project" tidbit in nsapplication; then try to work out the saving
state problem starting with a simple NSDocument application like
Ink.app.
Finally we need to carefully study how we can implement properly open
documents hiding per project session (when they share an application
process accross projects) and we can switch on the fly from from one
UI setup to another one when switching between two projects yet
sticking to the same application.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
