[arch-general] Automatic File Associations Alloting

[Jayesh Badwaik]

Yeah. I too have my personal stuff for that. I have a script actually
which uses a file and from that creates the default.list file which is
then used by anyone who cares to use it (Firefox, KDE etc). But I am
now tired of the custom stuff. I just wanted to explore. And XML
seemed quiet universal in the sense.

And I have heard a lot but I still don't get it. Why is XML a beast? I
have read everything from every source where people have even given
point wise listings. But I am not able to appreciate anything. XML is
just a way of writing data, right? Instead of parsing text you parse
tags and their values. The only difference and advantage is that the
stuff is more human readable.

----------------------------------------------------------------------------------------------------------------------------------------------
Cheers and Regards
Jayesh Vinay Badwaik
Electronics and Communication Engineering
VNIT, INDIA
-





On Sat, Nov 26, 2011 at 2:48 AM, clemens fischer
<ino-news at spotteswoode.dnsalias.org> wrote:
> Jayesh Badwaik wrote:
>
>> Now whenever a new package is installed. It will contain an XML file
>> containing description of the mimetype in the same manner. When the
>> package is installed, the file will be transferred to a folder. The
>> main file which contains the descriptions of the mime type will be
>> somewhere else. This folder will contain the mime files which have not
>> yet been incorportated into the main file.
>>
>> Now, a program would run which will take this folder and the original
>> file as the default arguments and then update the file types. If there
>> is a conflict, especially if the priority of the application for the
>> mime type is already taken, then there can be a ncurses based
>> resolution window, letting window resolve the conflict (modeled on the
>> file association selectors in Windows applications). The priority in
>> the package files can be -1 if the file wants to go to the last
>> priority if possible. (like the nice factor of the processes)
>>
>> But no one can occupy the priority zero. Suppose a user opens an app
>> using open with command and then checks the box, then automatically an
>> entry is created in the folder with priority zero and then it is
>> updated. This way, automatic software will never trump the user set
>> defaults under any circumstances and the conflict management would
>> prevent the irritation at the file open time. I am sure people are
>> more careful during install than they are during file opening.
>>
>> Now the final XML file is created. This file can be then modified into
>> whatever is demanded by any DE etc etc. What do you think?
>
> XML is such a nasty beast to handle, especially for such a simple
> application.  I'm using a custom lessopen command as a companion to
> less(1).  My lessopen keeps a simple textfile with one
> mimetype/extension/open-helper per line.  Each file is checked against
> this "database" with "file -Lsbz --mime-type" or "file -Lsb
> --mime-type".  If a specific mimetype/extension/open-helper tuple cannot
> be found, the user is queried for it.
>
> In your case you want a unified database, because new programs may
> suggest some entry.  This requires merging and conflict resolution.
> I wouldn't go this way, I'd just use two different databases, where the
> user supplied one is checked first and a distribution one second (or
> last, in case the searching stops here).
>
> Database entries look like this (mimetype "_:_" extension ":::" helper):
>
> application/vnd.ms-cab-compressed_:_CAB:::7z l
> # an entry with a catchall (wildcard)
> application/x-executable_:_*:::readelf -d "${FILE}"; strings -a <
>
> If a filename contains several dots, the last few are taken to be the
> extension unless a catchall entry exists.  Using extensions for
> additional differentiation lets one use different programs in special
> cases.  The variable "$FILE" can be used in case the helper wants a real
> file, the "<" redirection operator lets the shell handle the readonly
> case.
>
> If lessopen isn't used by less, it can equally well be used for
> interactive, even GUI programs.
>
> I wrote the script because I was not at all satisfied with the official
> version, which is very complicated, doesn't let me configure my own
> programs and doesn't use a separate database, everything is needlessly
> hardcoded.  My version is simpler and more versatile.
>
>
> clemens
>
>