Highly customized meta-data, a user would have to create custom ones on their own, but a template for helping people search should be provided, a "file includes text:" or regular expression. (granted this stuff would be slower than snot)

Highly customized meta-data, a user would have to create custom ones on their own, but a template for helping people search should be provided, a "file includes text:" or regular expression. (granted this stuff would be slower than snot)

Line 24:

Line 29:

* We will have to determine how much of the meta-data to store permanently (in a database), and how much to throw away at each viewing of the directory. We will have to use the file-changed date

* We will have to determine how much of the meta-data to store permanently (in a database), and how much to throw away at each viewing of the directory. We will have to use the file-changed date

−

* We will expressly want parent directory as a column, and be able to have portions of the file name be categories.

* We will want to be able to sort in this manner:

* We will want to be able to sort in this manner:

root-directory-- mime-type, parent directory, size, file-name

root-directory-- mime-type, parent directory, size, file-name

−

Where we basically have directory like structures that are not directories. Where we show every file within a certain root-directory

+

*Ability to sort and group with directory like structures that are generated by a query. (limited to files within a certain countable category, like all files in a certain file-system folder, or from a server etc)

+

We will expressly want parent directory as a way to break down later, and be able to have portions of the file name be categories.

+

* We might have to integrate with FAMD to see if a file is modified.

+

* We will have to have timers that make it so the computer refreshes screen periodically, rather than on every single file has changed event.

+

* We will only need to poll the items visible in the view, or at least prioritize only the items visible, then low priority on other ones (unless we are using it as a search parameter)

+

* We will probably want to have the meta-data grabber store some stuff perminately,

+

*when we access the meta-data will will want to compare file modification time, with one that is actually recently grabbed.

+

*We will probably want a temporary database,

+

* Data size will probably not be a problem on most desktops

+

* We do not want to exclude possiblity will want a derived capability--or translator-- some files may give x and y dimensions, and some may only give area and x... so we could derive y.

+

Permissions, what happens the meta-data crawler is ran with, say root permissions and the user is bob, and he tries to access andy's stuff. It may be ok to run the indexer periodically as root, but then access to this data needs to be confirmed .

Highly customized meta-data, a user would have to create custom ones on their own, but a template for helping people search should be provided, a "file includes text:" or regular expression. (granted this stuff would be slower than snot)

Dealing with changing files, if a new file is created or modified. in an area that is being viewed, we want to have the indexer get the info.

No false information, If a file is changed or just not gotten to yet, we want the meta data filled with something that indicates not known yet...

If information should be there but is not, we want a blank indicator.

We will probably want put the ones that people are more likely to find useful at the top of the list.. and not restrict use of most, basically just hide it.

We will have to determine how much of the meta-data to store permanently (in a database), and how much to throw away at each viewing of the directory. We will have to use the file-changed date

We will want to be able to sort in this manner:

root-directory-- mime-type, parent directory, size, file-name

Ability to sort and group with directory like structures that are generated by a query. (limited to files within a certain countable category, like all files in a certain file-system folder, or from a server etc)

We will expressly want parent directory as a way to break down later, and be able to have portions of the file name be categories.

We might have to integrate with FAMD to see if a file is modified.

We will have to have timers that make it so the computer refreshes screen periodically, rather than on every single file has changed event.

We will only need to poll the items visible in the view, or at least prioritize only the items visible, then low priority on other ones (unless we are using it as a search parameter)

We will probably want to have the meta-data grabber store some stuff perminately,

when we access the meta-data will will want to compare file modification time, with one that is actually recently grabbed.

We will probably want a temporary database,

Data size will probably not be a problem on most desktops

We do not want to exclude possiblity will want a derived capability--or translator-- some files may give x and y dimensions, and some may only give area and x... so we could derive y.

Permissions, what happens the meta-data crawler is ran with, say root permissions and the user is bob, and he tries to access andy's stuff. It may be ok to run the indexer periodically as root, but then access to this data needs to be confirmed .

http://soprano.sourceforge.net/
This looks like it is the tool that will hold the meta data
Nepomuk RDF something or other... I don't know why this is different than any other database, but it looks like it fits the bill.