Re: Enriching the Application Manager scripting experience
I hope you are planning on at least a DTD for this, if not a more advanced schema such as RelaxNG. This would allow you to define the grammar in a rigorous fashion, so that those of us who need to parse or create your files can use the standard libXML2 tools to insure our files are both well-formed and correct. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
ext David Hagood [EMAIL PROTECTED] writes: I hope you are planning on at least a DTD for this, if not a more advanced schema such as RelaxNG. Urks. I knew I was going to regret touching XML... ;-) I will be happy to put such a DTD next to the documentation when someone contributes it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
Hi, On Fri, Feb 23, 2007 at 02:56:27PM +0200, Marius Vollmer wrote: we need to make the .install files more capable and more extensible for the future, so I came up with a design that I want to run past you. That's good! Please go here for preliminary documentation about what I am planning (the text is also appended below for easy commenting). ... I managed to sneak a bit of Lisp into the Application Manager, but I kept it enterprise ready by hiding it behind XML. So while the new way of writing .install files looks quite verbose, it is really quite simple. Now I'm worried. None of the documented stuff has been implemented, except the basic support for X-expressions and storing catalogues in X-expression form. So, what features do you think are missing from .install files? Now is a good time to add them. The ability to add more than one repository. E.g. I have an app in my repo that needs some library from repositories.maemo.org. ### Basic syntax ... It is important to distinguish empty lists from empty texts. An empty list is written as empty/ while an empty text is written as empty/empty According to the XML spec, these two are exactly equivalent. -1 for insisting for different spellings in different contexts. All text must be encoded in UTF-8. ... ### Example The following X-expression is a installation script to install the maemofoo package from the Foobar repository. install-instructions update-catalogues catalogue tagcom.foobar.repository.automatic/tag version0/version name en_GBFoobar Catalogue/en_GB de_DEFoobar Katalog/de_DE /name urihttp://example.com//uri distautomatic//dist componentsmain/components /catalogue /update-catalogues install-packages pkgmaemofoo/pkg /install-packages install-instructions Compare this to a hyphotetical .ini-based format like the one used by GNOME/Freedesktop .desktop files [install] repo_name = Foobar Catalogue repo_name[de_DE] = Foobar Katalog repo_deb = http://example.com/ mistral main repo_deb_3 = http://example.com/ bora main package = maemofoo I think the XML-ish format is harder to write, harder to read, and provides too many features that I do not see any need for. But that's my personal opinion. (Yes, using a text markup language to represent data structures (let alone programs) gives pretty unreadable results.) XML can be pretty readable. Here is another, slightly more involved example. This one can be used on a memory card. It will offer to install the listed packages and will use a repository on the memory card for that. Repositories for bora and mistral are supplied, and they are located relatively to installation script. Afterwards, it will offer to add a automatic repository that might be used to deliver updates. install-instructions with-temporary-catalogues add-catalogues catalogue no-network filter-distbora/filter-dist urifile-relative.repository/bora/file-relative/uri /catalogue catalogue no-network filter-distmistral/filter-dist urifile-relative.repository/mistral/file-relative/uri /catalogue /add-catalogues install-packages pkgfrozen-bubble/pkg pkgcrazy-parking/pkg /install-packages /with-temporary-repositories add-catalogues catalogue name en_GBFoobar Games/en_GB de_DEFoobar Spiele/de_DE /name urihttp://foobar.com//uri distautomatic//dist componentsmain/components /catalogue /add-catalogues install-instructions Let me try... [install] temporary_file_relative_repo_deb = .repository/mistral mistral temporary_file_relative_repo_deb_3 = .repository/bora bora package = frozen-bubble crazy-parking repo_name = Foobar Games repo_name[de_DE] = Foobar Spiele repo_deb = http://foobar.com/ mistral main repo_deb_3 = http://foobar.com/ bora main ### Compatability with IT OS 2007. Yup. The old GKeyFile format used by IT OS 2007 is still supported. You can embed a X-expression in it as comments like so: # install-instructions # ... # /install-instructions Ouch. Comments that are not really comments. I can't say I like it. [install] repo_deb_3=deb http://foobar.com/ bora main package=maemofoo If the Hildon Application Manager encounters such a file with an embedded X-expression, it will use that and ignore the rest. If there is no X-expression, it will transform the GKeyFile according to the following rules. Summary: I would prefer a straightforward extension of the current .ini-based file format. Marius Gedminas -- A Law of Computer Programming: Make it possible for programmers to write in English
Re: Enriching the Application Manager scripting experience
On Fri, Feb 23, 2007 at 04:28:37PM +0200, Marius Gedminas wrote: Let me try... [install] temporary_file_relative_repo_deb = .repository/mistral mistral temporary_file_relative_repo_deb_3 = .repository/bora bora On second thought, this would be better: temporary_repo_deb = file-relative:///.repository/mistral mistral temporary_repo_deb_3 = file-relative:///.repository/bora bora The app manager can straightforwardly replace the file-relative:/// prefix to file:///path/to/the/location/ package = frozen-bubble crazy-parking repo_name = Foobar Games repo_name[de_DE] = Foobar Spiele repo_deb = http://foobar.com/ mistral main repo_deb_3 = http://foobar.com/ bora main Marius Gedminas -- Everyone has a photographic memory. Some don't have film. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
ext Marius Gedminas [EMAIL PROTECTED] writes: I managed to sneak a bit of Lisp into the Application Manager, but I kept it enterprise ready by hiding it behind XML. So while the new way of writing .install files looks quite verbose, it is really quite simple. Now I'm worried. :-) ### Basic syntax ... It is important to distinguish empty lists from empty texts. An empty list is written as empty/ while an empty text is written as empty/empty According to the XML spec, these two are exactly equivalent. -1 for insisting for different spellings in different contexts. Yeah, I was afraid of that. I am going to fix this. All text must be encoded in UTF-8. ... ### Example The following X-expression is a installation script to install the maemofoo package from the Foobar repository. install-instructions update-catalogues catalogue tagcom.foobar.repository.automatic/tag version0/version name en_GBFoobar Catalogue/en_GB de_DEFoobar Katalog/de_DE /name urihttp://example.com//uri distautomatic//dist componentsmain/components /catalogue /update-catalogues install-packages pkgmaemofoo/pkg /install-packages install-instructions Compare this to a hyphotetical .ini-based format like the one used by GNOME/Freedesktop .desktop files [install] repo_name = Foobar Catalogue repo_name[de_DE] = Foobar Katalog repo_deb = http://example.com/ mistral main repo_deb_3 = http://example.com/ bora main package = maemofoo (You are missing the tag, version, the en_GB translation, and the automatic distribution thing.) I myself prefer the S-expression approach: (install-instructions (update-catalogues (catalogue (tag com.foobar.repository.automatic) (version 0) (name (en_GB Foobar Catalogue) (de_DE Foobar Katalog)) (uri http://example.com/;) (dist automatic) (components main))) (install-packages (pkg maemo-foo))) which can be shortened to (install-instructions (update-catalogues ((tag com.foobar.repository.automatic 0) (name (en_GB Foobar Catalogue) (de_DE Foobar Katalog)) (deb http://example.com/; automatic main))) (install-packages maemo-foo)) Maybe I go with this approach if XML turns out to be too unwieldy. The .ini-based formats are not expressive or extensible enough, in my opinion. When you have multiple repositories each with their own set of localized names, you are stretching the format quite a bit already. Essentialy, .ini files don't lead to nice recursive in-core data structures. The idea with X-expressions is that they have a simple mapping to an internal data structure and your program actually works with that data structure directly. For example, to get the tag of a catalogue, the code currently does 'xexp_aref_text (cat, tag)'. There are no special purpose conversion functions for catalogues from/to XML, there is just xexp_read and xexp_write. This makes not only the file format extensible, but also gives you code that can be follow when you do it. With this approach, it is quite trivial to load, store and let the user modify catalogues. I no longer want to encode all information about a catalogue in sources.list, and while we could store this information in the form of .ini files, I would rather not. I think the XML-ish format is harder to write, harder to read, I agree. and provides too many features that I do not see any need for. Most of the features are needed for new features of the Application Manager. But the fundemantal idea still is that we need something more expressive and extensible for the future. Let me try... [install] temporary_file_relative_repo_deb = .repository/mistral mistral temporary_file_relative_repo_deb_3 = .repository/bora bora package = frozen-bubble crazy-parking repo_name = Foobar Games repo_name[de_DE] = Foobar Spiele repo_deb = http://foobar.com/ mistral main repo_deb_3 = http://foobar.com/ bora main (Again it's not exactly the same, and keys like temporary_file_relative_repo_deb really don't look like the way to go for me. In the end, you will encode arbitrary tree structures in key names, with sequence numbers and levels, etc...) The old GKeyFile format used by IT OS 2007 is still supported. You can embed a X-expression in it as comments like so: # install-instructions # ... # /install-instructions Ouch. Comments that are not really comments. I can't say I like it. Me neither. It's a compatibility hack. Summary: I would prefer a straightforward extension of the current .ini-based file format. We have that currently in the code, and it is not pretty (sorry Jose). I would like to improve upon it. Maybe XML is the wrong choice, but I wanted to
Re: Enriching the Application Manager scripting experience
On 2/23/07, Marius Vollmer [EMAIL PROTECTED] wrote: Hi,extentions you expect (sorry, for the marketing attack in the subject, but it's Friday... :) we need to make the .install files more capable and more extensible for the future, so I came up with a design that I want to run past you. Can you elaborate a little bit on what kind of problems you are trying to solve? Please don't see this as a rant. I wonder how this experiment will turn out. your the coder so you make the calls:p I think the real problem is the difference between the way debian repositories work and what a software developer can provide(one package v.s a repository). A real software vendor will want to provide a tested package with no dependencies otherwise his software will brake and playing with repositories is a deadly action. what happens with sirocco and greagale users in your system my feeling is that the xml based system would not really solve problems but make it harder for somebody to understand what is going to happen if he clicks yes I think the .install system should follow such guidelines -simple -not allow booth the repository name and location to be changed separately(security) -The manager should download a list of know / valid /kinda trusted list of repositories from maemo.org -try to solve the problem server side by perhaps just sending a different .install file or allowing a minimal set of variables.insall=repo://maemo-extra:$distro/ -I should be able to click a .install file and I should be presented with a list of proposed changes. -Should really not contain relative path and other vague fields that are hard to test -Should have a uninstall, I was not happy that when I removed canola a lot of different canola bases packages remained on the system (this is a debian problem) Perhaps looking at the jar/.jad file format might be a good idea it allows plenty of control to both the user and the developer (things like an install success/failure automatic feedback url), and a list of allowed operations/required services to be able to install. I think in other words , what is the problem with the current .install format? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
On Fri, Feb 23, 2007 at 04:28:37PM +0200, Marius Gedminas wrote: [snip] distautomatic//dist This looks a bit strange (=not intuitive). Compare this to a hyphotetical .ini-based format like the one used by GNOME/Freedesktop .desktop files [install] repo_name = Foobar Catalogue repo_name[de_DE] = Foobar Katalog repo_deb = http://example.com/ mistral main repo_deb_3 = http://example.com/ bora main package = maemofoo I've never really liked the syntax of these ini-style install files. Especially the artificially generated structure (with underscores, e.g. repo_deb_3) looks ugly to me. I know it's too late but why not use simply: [install] package = maemofoo [repository] name = Foobar Catalogue dist = mistral deb = http://example.com/ mistral main I know that the improvement would be merely cosmetic but actually it's not that easy to make it radically better because of the limitations of GKeyFiles and the GLib parser (only one level of hierarchy, group names must be unique). Of course you could have support for multiple repos by allowing magic group names (repository-*) or having something like [install] package = maemoxyzzy repositories = maemofoo maemobar ... [maemofoo] name = Foobar ... [maemobar] ... but that's a bit clumsy, although cleaner. [install] temporary_file_relative_repo_deb = .repository/mistral mistral temporary_file_relative_repo_deb_3 = .repository/bora bora package = frozen-bubble crazy-parking repo_name = Foobar Games repo_name[de_DE] = Foobar Spiele repo_deb = http://foobar.com/ mistral main repo_deb_3 = http://foobar.com/ bora main Looks even uglier. The old GKeyFile format used by IT OS 2007 is still supported. You can embed a X-expression in it as comments like so: # install-instructions # ... # /install-instructions Ouch. Comments that are not really comments. I can't say I like it. +1 [install] repo_deb_3=deb http://foobar.com/ bora main package=maemofoo If the Hildon Application Manager encounters such a file with an embedded X-expression, it will use that and ignore the rest. If there is no X-expression, it will transform the GKeyFile according to the following rules. Summary: I would prefer a straightforward extension of the current .ini-based file format. My suggestion is that if you're going to change it, do it right this time. Backwards-compatibility is nice but if you see that GKeyFiles will cause inevitable problems in the future, drop them now. Do, however, think a bit about the format so that people don't need to have Lisp knowledge to write them. Br, Jari -- Jari Tenhunen, stardate [-29]7187.98 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
