"Rinat" wrote:
Maybe I couldn’t understand you, but I don’t wish to imply any of AI at all. Assuming you have not only the file URI stored in your DB, but also the unique hash (i.e. MD5)

no we don’t, and this is most definitely not gonna change.
Calculating an MD5 hash, storing it into the db and checking it would totally kill the performance of Tabbles…
it’s our precise goal to keep the db as light as possible in order to have as many files as possible to fit in it, while keeping performances to a reasonable level.

To give you an exemple, I work with 10k files db on my Netbook (it uses 100-180MB RAM), and Maurizio with a 40k files db on his Laptop (there it sucks 150-300MB of RAM) and in both cases Tabbles runs decently fast…

"Rinat" wrote: You can implement a kind of brutforce synchronization 😀 Analyze in a previous manner the structure of the first storage and make the same structure on the second, making only new folders and using the files already present on the second drive. All the files which are not in the same set are ignored and untouched.

I get your point: we didn’t really look into that, but it is something that for sure we’ll be asked to deliver at some point. We believe anyway that with the shared-tabbles feature the problem will become much lighter if not neglectable, as sharing the dbs the way we’re planning to do it will already help in finding out what files has to be moved and what not…

"Rinat" wrote: This is the thing I wanted to avoid – to have the same structure.

I see… as said we’re aware of your pain, and we’ll look at what it takes to solve it at some point… it’s just not very high on our priority list. What we’re aiming to right now is having small teams of people sharing their categorizating smoothly on a LAN and browsing through their colleagues tabbles.

"Rinat" wrote:
Well, I will wait for the nested tabbles.

The nested Tabbles are there already, check the beta section of the forum! 😈

"Rinat" wrote: Oh! Just a little idea – to have predefined Tabble Types: Data (dd/mm/yyyy), Volume N, Issue M – where you should only fill the gaps when tabbling. For example if I want to organize my collection of science articles (this is exactly what I’m trying to do) I also want to set the data of the issue, volume number and issue number – it is enough to make some sortings and selections. BUT also must be the feature to combine those tabbles by selecting the range of numbers (a kind of temporary tabbles, for example – "Volume 10-15" + "Data 10/04/1985-10/02/2000"). I think adding some wildcarding to the combining of tabbles will be very useful. Well… To involve the feature of enumerated tabbles!! This includes all the cases I’ve described before.

Dude, this is a lot of stuff!!! 😀
Let’s try to elaborate it and organize it:
1) the data: a 100% automatical tagging based on data is in the pipeline already… expect it in 2-3 months or something (read on for a workaround).
2) Volume N, Issue M: in case you’re asking for a generic solution, well this is TOUGH STUFF! 🙂 Anyway we can work-around this using the auto-tagging rules: you can create rules to auto-tag a file based on position and/or filename (actually a part of the filename) and/or extension. This way, given that the Volume N is probably always between 1 and 12, if the files are named consistently (i.e.: they’re always named like: magazine.vol._N.blah_blah.pdf) than you can create 12 auto-tagging rules and get all your articles sorted automatically. If the month/year appears in the filename, you can do the same for the data….
3) "Volume 10-15" + "data 1985 to 2000": you’re asking for a logical OR here, and even a pretty complex one. What we have in a pipeline (coming hopefully soon) is a logical OR allowing you to compose queries like "10 or 11 or 12 or 13 or 14 or 15". With this principle you could basically do everything…but it’s not so practical for your purposes.
Consider anyway that once things are categorized properly, you can easily get your files grouped and/or sorted per data, issue n. + other stuff like subject and so on…

The bottom line is: we get your point, but creating an archive of articles is not really the main purpose of Tabbles. The main purpose is instead to allow users to arrange eterogenous kind of files (e.g.: cad + ppt + xls + jpg, or .doc + pdf + tiff, or .avi + txt + psd + mp3) where a search engine would fail cause the files don’t contain much text and when they do, the text is not expressive enough to allow the search engine to understand that they’re connected.
To my eyes, you’re looking for a specific solution crafted to solve a precise problem… this is just not where we’re heading to right now. Still you’re very welcome to hang around on the forum and give hints/comments/insults, and you can even do it pa russki in the russian section of the forum! 😀 :ugeek:

Ok, time to sleep now… I hope I answered more questions than those I raised 🙂

Andrea