Hi Frederico, Le 18 sept. 07 à 00:22, Frederico Muñoz a écrit :
> Hi all, > > First of all, quite sorry for not saying anything in the last 5 > months, as usual private life and two job changes took the better of > me. Welcome back! > Having said that I would like to begin by giving my congratulations to > everyone, I've been following Étoilé SVN and the feeling of it is > quite good. thanks :-) > Now, as some of you will recall I wrote the awfully incomplete > Installer.app, which was invited into Étoilé. I now can more or less > dedicate a fixed ammount of time to personal projects, and since > that's the code I know best I am enquiring if in terms of the project > that is something that would be worthwhile to continue. I'm asking > this because I view as completely normal and even desired is anyone > else wants to take the lead, or even make something from scratch. I > abhor duplication of efforts if avoidable, so I would surely find some > way to be useful. I think having an Installer is still necessary. iirc two years ago we came to the conclusion almost everything should be installed by drag and drop, only falling back on Installer when it's not possible. It happens with applications that wants to provide a framework or extra system resources (like fonts, images etc.). A key idea was also to let applications handling the installation directly on their first launch by relying on an installer tool (with or without UI). In this perspective, the main interest of Installer seems to be a standard compressed package format and a simple dependency tracking based on retain count. The goal of dependency tracking is to allow several applications to share the same elements (framework, resource). If an application installs an element, the retain count of the latter is 1. If another application try to install or checks for the same element, the retain count becomes 2. When an application is uninstalled, the retain count of all its related elements are decremented. Let me know whether this summary matches your ideas and our past discussions… Other interesting ideas were version tracking and app casting, the website has still a detailed summary here: <http://www.etoile- project.org/etoile/mediawiki/index.php?title=Installer> In the meantime, CoreObject idea has evolved a lot. It isn't yet fully implemented, but prototypes for both the persistency layer (EtoileSerialize) and name service layer (CoreObject/OrganizeKit) exist. Since CoreObject will give to Étoilé its own FS-like interface (based on tagged objects), Installer development is going to be closely related to it. CoreObject name service API will be very close to <http://svn.gna.org/ viewcvs/etoile/trunk/Etoile/Frameworks/CoreObject/Headers/>). Tags are called Groups in CoreObject. When the framework will be ready, Étoilé environment will be fully abstracted from the underlying storage organization and you won't see the host system FS unless you want it. This point means we will probably provide a new Resources access API for stuff like images, fonts, dictionaries, color profiles etc. Applications would benefit from the possibility to publish their internal resources by tagging them as shared resources. Tagging such resources would mean adding them to special groups named 'Shared Resources', 'Shared Images' etc. By doing that an application would made transparently available in a system-wide way any of its resources without installing anything. Uninstalling becomes unecessary too. For both security reason and ease of integration with the host system, it is surely better to avoid publishing executable code in such way… so framework installation/uninstallation (and bundles in some cases too) would still rely on Installer. Another benefit of CoreObject here is that retain count mechanism can be implemented by tagging each framework with application identifiers. On uninstallation, Installer just checks whether the framework is tagged only by the application getting uninstalled. If it's not the case, the framework won't be uninstalled and the identifier of the uninstalled application will just be removed from the framework's tags. Another more long-term use for Installer would be a classical OS-like installer which is able to update an existing Étoilé environment by installing a new version. > So, I'm really open to whatever you guys decide, and can completely > assure you than any decision is fine by me. Well, I'm curious to hear other opinions about Installer since we haven't talked about this topic for a while. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
