Le 14 mars 05, à 16:01, Stefan Urbanek a écrit :
Hello,
Now let us go to the packages. We have:
- Host OS packages (deb, rpm, tar.gz, Install.EXE, ...)
- GNUstep packages (no standard format defined yet)
We need to distinguish between them and handle them separately if
possible. That
means that we get following package management applications:
1. manage host os packages
2. manage gnustep environment packages
3. manage host os packages and gnustep environment packages
4. manage gnustep system packages
We do not have to care about the #1 packager. #2 packages should be
available
everywhere where GNUstep environment is installed - on MS Windows,
Linux, OS-X.
It should handle ONLY gnustep packages. #3 should not be a priority
and should
be offered as option to the GNUstep likers to manage all their
packages on
their system. The #4 is like #3, but is native to its system.
This was my point of view to environments and packages. How do you see
it and
how do you think it should be handled in Etoile?
Like that :-)
More precisely until we have GNUstep distribution (which is going to
happen soon probably) because in this case we would probably need to
have real integration with host os packages management system.
For #3 I think it is still important, psychologically speaking for
Linux/BSD users and more importantly when you need to manage GNUstep
deployment on several computers unless we add the possibility to have
installation scripts for Installer.app.
Installation scripts would allow to submit a list of packages, a list
of packages sources and an optional list of networked computers where
deployment should be done. Well that's just a package management system
(a la Linux/BSD) but dependencies support ripped out, however I think
it is too much work to start.
A possibility I would like to have for Étoilé when you are connected to
internet : when you double-click a document without applications to
read it, Workspace.app starts Installer.app related tool which requests
"special Étoilé server" in order to obtain possible viewer/editor
applications list. This tool would would build the request by relying
on double-clicked document type passed by Workspace.app. In fact, this
would be really possible only when we will have "rich document
description" support not just "extensions" to encode the type
(extensions would become optional at this point). Then you have the
possibility to download and install the application you would like to
use.
A such system could be a foundation to have in distant future, optional
user experience with local documents and non local applications; we
would build applications with possible "light client use" (just
clicking a "Share" check box in Info panel ideally ;-) implemented like
that :
- server side controller/model execution
- client side view/controller execution,
And nib files would be sent by the server with a packaged
"view/controller related applet".
That's looks like Macromedia Flex but with GNUstep and no ActionScript
nightmare :-)
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
