On Thursday 17 January 2008 14:45, William Skaggs wrote:
> From: peter sikking [EMAIL PROTECTED]
>
> > chiming in here (getting back to speed). [...]
>
> Peter! Great to hear from you again!
>
> I absolutely agree about the virtues of a tagging system, but
> I fear that the difficulties are not being appreciated well enough.
> Here, for example, is just one of the problems:
>
> Problem: should tags be stored as part of a data file, or in a
> separate tags-database?
separate tags "database" - which might be a xml file, I think.
>
> 1) If they are stored as part of the data file, then this calls for
> a new file format for every sort of gimp resource object, and
> changing tags calls for file system operations.
ok - this won't happen.
>
> 2) If they are stored in a separate database, keyed by file
> names, then there is a great danger of losing the linkage
> between tags and object. If, for example, the user renames
> the directory holding some brushes, all of the tags for those
> brushes will be lost. The only way to prevent this sort of
> thing from happening is to make sure that all operations
> on resource files are mediated by Gimp (or some new
> utility program) that will make sure to keep the tags in
> sync with the data files. If for some reason a user's tags
> database gets corrupted, it will be a major disaster.
>
I think we just need to worry about it being a "minor" disaster. I can
think of "recover scripts" that could be written to restore some
tags, in case of directory renaming, for example.
> There are many other issues of the same sort, which I don't
> believe have been thought through.
I don´ t think so. It looks plain straightforward for me.
I have worked with many web systems that reference filesystem paths
for images, for example, and never had a maintanance problem due to
that.
Besides, yes, gimp would need some kind of scanning through resource
folders, and possibly group all resopurces tehre under an "all" flag.
That is needed so that one can download resources and add then to
GIMP through the filesystem.
>
> The bottom line is that introducing tag-based resource
> organization is like setting up a virtual, non-hierarchical
> file system. The ordinary file system may be weak in
> comparison, but it is extremely robust, and users know
> how to manipulate it. A new tag-based file system can't
> possibly be robust until it has had an extensive testing
> period, and therefore exposes a user to the worst of all
> disasters: a corrupted file system.
>
> The solution I favor is to build a tag-based system *on
> top of* a filesystem-based system. That way:
>
> 1) The tag-based system can be built gradually, instead
> of being imposed all at once on a flat set of files.
A "flat set of files" become a "flat set under one tag" in teh worst
case scenario.
>
> 2) The user can manipulate files using ordinary filesystem
> operations without fear of wrecking gimp.
Yes, that need to happen therefore the folders where resources are
expected to be, as they are today should remain, IMHO.
>
> 3) A naive user who doesn't understand tags will still be
> able to use Gimp without having to learn about tags at
> the very beginning.
This one is for Peter. In short: yes, there should be resources
visible in a default GIMP install, first use. Maybe we could name
a "Basic" tag for these start-up resources. A drop down for the most
used tags could be fine as well.
>
> 4) A corrupted tags database will still be very bad, but won't
> make Gimp completely unusable.
Indeed. As I said, the scanning should be made at gimp-load, and any
resources found should be mapped to a "default" tag. Using something
as simple as a hash of the entire file data could preserve all tags
even when resources where moved across directories (rescanning
hashest might need an explicit action)
regards,
js
-><-
>
> -- Bill
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
