Extend .info file

[bmarkus]

.info file structure is unchanged since TC 1.0 and still OK. However number of available extensions are growing and if you do not know exactly name of a package not so easy to find one, specially when useful information is missing in .info saying description like 'Latest abcd package' for abcd.tcz

Lets add a tag line to info file with free content, however with a published guidelines with propesed tags to make it unified. I think it wouldn't break current applications processing .info files. Also, it doesn't force to recreate .info files, can be introduced during regular updates and still keep optional. Also, AppBrowser search can use it as it is now.

Just an example:

Title:          unixcw.tcz
Description:    Morse code library and applications
Version:        3.0.1
Author:         Simon Baldwin, Kamal Mostafa, Kamil Ignacak
Original-site:  http://sourceforge.net/projects/unixcw/
Copying-policy: GPL v2
Size:           61k
Extension_by:   bmarkus
Tags:           CLI HAM RADIO CW
Comments:       Binaries only
                ----
                Compiled for TC 4.x
                ----
                PPI compatible
Change-log:     ----
Current:        2012/02/03 First version, 3.0.1

[hiro]

Why not just write them into the comments field?

[bmarkus]

Why not just write them into the comments field?

Comment is a free form for any additional info, like configuration, usage notes, etc. Tags are like multiple categories. They are different. You can efficiently filter based on tags if they are used properly with a simple tool defining criterias like any or all tags must be found, tags to exclude, etc. Tagging is widely used solution in IT world to help finding pictures, books, software in fact anything instead of searching notes.

The question is not to find arguments against doing something but how to make something better

[vinnie]

Yes! please please please 

In regard to this topic http://forum.tinycorelinux.net/index.php/topic,11562.0.html

I think it's important to have an entry in .info corresponding to the button "keyword", I'm doing the latest packages so arranged as I have specified here
http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example

[bmarkus]

Yes! please please please 

In regard to this topic http://forum.tinycorelinux.net/index.php/topic,11562.0.html

I think it's important to have an entry in .info corresponding to the button "keyword", I'm doing the latest packages so arranged as I have specified here
http://wiki.tinycorelinux.net/wiki:creating_extensions#tczinfo_example

Please, do not mix description with tags and please, do not advise to do so in the wiki!  Description is not for tags! In fact, there are no place for tags, this why I'm advicing to introduce it. To fix a bug with an another bug which compensate it is a bad practice.

[vinnie]

bmarkus, please, not take a contrasting position with me, is quite evident that with my actions I tried to patch up grossly and not to vandalize the wiki and waste best practice method.

The proposed solution in wiki is brutal but functional (and frankly do not even like me), but if you look my topic date, I have written two months before the wiki edits, when I had lost hope that someone was interested to solve this (what I believe) problem.

To be honest, I was hoping that someone complained about the editing of wiki (noting the incoherence with the description field criteria) to reopen the discussion.
Was not this the course of things, but the result is the same.

[Rich]

Why not just write them into the comments field?

1. A lot of extensions lack useful information in this field making it unsuitable for this task.
2. Unrelated extensions may contain the keyword in a different context.

If a  Tags  or  Keyword  field were to be added it would make sense to do a little planning first to
make it efficient and user friendly. Possibly something like this:

Tags: SUBJECT FUNCTION [FUNCTION] [FUNCTION] [FUNCTION]

This way, when doing a search, if there is no match on SUBJECT, you don't any waste time looking at
the other tags. A standard table of  SUBJECTs  and  FUNCTIONs  would make it easier for an end user
to find things and easy for the extension maintainer to pick standard keywords. Example:

Code: [Select]

SUBJECTs          FUNCTIONs
compiler          c c++ fortran ada cross assembly
driver            audio video tablet network firmware
editor            text hex audio video picture programmers tabbed html office spreadsheet
filemanager       small twopanel dragdrop ftp
fileutil          compress expand sort search backup
game              text graphic network
library           math audio video network fortran
network           monitor fileshare ftp discovery client webserver
player            audio video networkSo if someone is looking to play music over the network, they would search for  player audio network.
If they simply want to know what players are available, they would search for  player, and all players
would be returned by the search. There is an implied  and  in the search, meaning all keywords must
match, as I have my doubts as to how much value would be added by an  or  function.
Although not perfect, I think the above example, while far from complete, has some merit. The difficult
part is coming up with a list of  SUBJECTs  and  FUNCTIONs  that:
1. Everyone can agree upon.
2. That are generic enough so the list of choices does not get out of hand. For example, if you are
    looking for a math library, the only choice for  FUNCTION  is math. No trig, float, integer, etc.
    keywords, as the search will already have narrowed the field to find what you are looking for.
3. That can handle applications that may not fit neatly into one  SUBJECT.

[coreplayer2]

IMO  only extra Keywords to help in search function would be helpful,  although I feel this option exists already but is just under utilized by the extension creator.

[Rich]

Hi coreplayer2
And where would you place those keywords?

[coreplayer2]

Hi Rich, yes I knew I was going to get cornered on that one.   

Assuming keywords are searched for within the description or comments fields, I'd put them there.    I'd be grateful for more keywords anyhow. 

[roberts]

I introduced keyword search with the release of v4.0. The Description field is currently used.
But, it is mainly ignored. I don't care what field or if a new field is used, as long as extension makers use it!
If a new field is used then it will take a long time for keywords to be useful. This is one of two areas that the infrastructure is waiting on good data. Otherwise garbage in, garbage out.

[Rich]

Hi coreplayer2
TC3.x appears to search the entire  info  file. Do a search for  backup  and you will get back every
extension that tells you to backup your user settings. It also does partial matches so a search for
email will return  autoconf-2.13.tcz  because one of the authors is named  Akim Demaille. Granted
it is in the  Author  field but it demonstrates how you can get results you are not looking for. If a
Comment field contained the phrase "change the config file using a plain text editor" you would
receive that extension whether it was relevant or not.
TC4.x appears to search only on the  Description  field, also with partial matches.
In either case, try doing a search for an extension that provides file sharing without using the terms
Samba, Windows, or NFS and see how that works out for you.

[Rich]

Hi roberts
I want to begin by saying that none of this is a criticism of what you have done. A good search system
requires a lot of work to be done well, along with cooperation by extension makers.

If a new field is used then it will take a long time for keywords to be useful. This is one of two areas that the infrastructure is waiting on good data. Otherwise garbage in, garbage out.

Agreed. If a new field were introduced for keywords, the description could be used as a fallback
to maintain compatibility with extensions that do not yet contain the new field. As new extensions
are added and existing ones are updated, the  submitqc  script could verify that the field is present
and contains at least two entries, though syntax would not be checked as the list of keywords is
liable to change over time.

[Guy]

I think keywords could be used that are not part of the description. So it is ideal to have it separate.

Why not encourage people to update files, adding keywords. Then include a keyword search.

The method suggested in the previous post is a possible temporary option.

[Rich]

Hi Guy
In an ideal world, it would be nice to do this in one shot. Having only one extension in the repository,
it would be very easy for me. However, some members maintain upwards of 300 extensions, and
I would not expect them to start updating them all for this change. I don't think of this as a temporary
option, rather, I consider it to be a gradual upgrade path that could accommodate both existing and
newly submitted packages. This would allow package maintainers, should they choose to, to gradually
upgrade their packages over time, preferably starting with applications and leaving libraries for last.
Not to mention, if everyone upgraded their packages at once, JasonW would get swamped by all the
resubmissions.