View Single Post
  #18  
Old 05-07-2012, 10:47 AM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
Then, of course, you'll have the problem of list width. In my case, the with of the name attribute of files is just 1 or 2 cm, since I adopted that mnemonic file naming system consisting of 1 to 5 characters only (each character having a mnemonic systematic "virtual subfolders" meaning and with the latest character only to be the first character of the item's / file's " virtual individual title" (= which as such doesn't even exist), plus possible prefixes, but then, if I've got a cloned file "abc.xyz.ao" file, and only the characters "abc.xyz" are visible, very well for me, and even if only the characters "abc.xy" are visible, that's okay with me, since in every instance, within the "comment" attribute, I RESOLVE that cryptic, mnemonic title, and as said, I choose my files from there, except for some standard files I open again and again and whose cryptic names I've since long memorized. Example: File name is cfb.ao, entry within the - rather broad - "comment" field will be the resulution of that code, i.e. "C IM Backup, Recovery, etc." ("C" stands for "Computer" and "IM" stands for "Information Management", since I've got these denominations dozens of times within my system, but other terms are generally resolved in full characters).

Which is to say, an imported, long file name, with a short prefix, will still be a rather long file name, that's not easily squeezed into such 1-2 cm column width! And so, there's two solutions to this problem, mentioned above: Either your system (= natively, or by your own scripting capabilities) will put the "resolution" for the prefix, and then the original file name, into the comment attribute of the file, and by this, at least a good part of the complete file name of your imported file will be readable within the attribute column of your system - or you do TWO such file lists, side by side, the first one being your above-described main file system, and the one farther to the right of your (wide) screen being a "parallel" such file (and folder) system for imported, third-party files.

You could even hold these two bunches of differently treated / displayed files within the same folder / the folder / subfolders system, by filtering, within list one, by your own suffixes (.ao, .xls, etc.), and within list two, by EXLUDING exactly these suffixes of your own files, both lists being sorted alphabetically, but with list 1 having a narrow name column but a large comment column, list 2 having a broad name column and perhaps an invisible comment column (but which you'll need anyway in order to store (but not necessarily to display!) ToDo codes like #, , the yen sign, or combinations such as 1, 2, #a, #z, or whatever).

Re interaction main program / outlining program and file commander / file management, it should of course be possible to do renaming of an original file that propagates to any clones of it, and renaming of clones that propagate to the original and any other clone, and the same goes for propagation of text changes within the comment field of any such an element, be it the clone, one of several clones or the original; in part, these problems and theirs solutions depend on the kind of your individual cloning technology (which depends both on the outlining program you use, and on the Windows version you rely upon. These problems could be resolved by scripting, instead of manual maintenance, but the main problem (addressable by scripting also if necessary in the end) is to avoid to perpetuate the current need for "having to think about it" any time you do any changes whatsoever to any of your files (and be it just additional cloning, let alone renaming a clone, i.e. the prefix part of it, which should indeed be perfectly devoid of problems but isn't for now).

Off-topic and re physical storage of sentences: Underlying global and double problem is both to assure scalability into spheres of amounts of data comparing to Google's db's, and to finally get rid with that conceptional data storage chaos that at this time every developer solutions in his own, perfectly chaotic way, i.e. up to now, there's no standardized concept for (mainly) text data storage but in most applications, there's the text storage in its "natural way" from your writing, and then there's nothing but superposed on that a second overlayed system for referencing, but only for recencing various parts of these "naturally stored" text chunks, i.e. text is mainly stored in "text files" (of various technical realizations, e.g. record fields within records of a UR db) where various text bits are stored consecutively but which could as "naturally" belong into various / multiple / myriads of other contexts, whilst only some of these are, but then by various forms of referential realizations, also put within some of those possible other contexts (e.g. cloned items, cloned paragraphs, cloned paragraphs / items you later on wish they were just copies not clones (!) or even aggregates of a "cloned part" and an "info part" showing which way the cloning mechanism (by way of changing the original) affects these clones (but which would be used in their original form, besides that information need, etc., etc., and, the other way round, "further developed clones" where the original part would be recognizable but which would allow for variations, and variations not propagated backwards to the original (which is a big risk with UR's clones, by the way).

As a third, again different mechanism, such a heteroclite system is often overlayed by a "real reference" mechanism, for outbound links, or for internal links but to items, whilst the second system described above is only for paragraphs - and so on and on and on, making a chaos for text storage, most texts stored in a physical sequential order as you wrote them, having bits of text in link bodies and whatever, spread out over the whole data heaps. The same often applies to db's storing pictures, pdf's and even other (html or whatever) data into the db itself, instead of just linking to the original files stored within any folder external to the db file, or to special auxiliary folders / db's / parts of the main db in which such a systems stores non-textual data.

Hence the interest of separation, and and for all, of text storage and text presentation, and with today's pc's, there's no need whatsoever anymore to not deciding to store a text chunk presented within an item's text field, and consisting of perhaps 100 sentences, within 100 different records of a monster db, from which your application routine, by reading no text file / text record but a list of (in this example) 100 reference addresses, will restore the connected text: each item record would then contain a bunch of links only, be they to sentences, pictures, jpg's, web addresses, mails (!), or whatever.

Specialists and people a little bit interested in technology will know what delta copying is, and whilst for web synching services (like Dropbox and many more) this dividing of monster files (of perhaps 4 GB) into (perhaps 1,000) chunks (of perhaps 4 MB each) and then copying (and integrating into the target file) of just those parts of the monster files that have been altered in any way, all but one (?) of the "consumer" sync programs (and including the overpriced SyncBack Prof and ViceVersa Prof) do NOT do this delta copying; MS Outlook does create such monster files, these ".pst" files, and many of them get corrupted, here and then, and it's not by coincidence that tools that promise to repair such corrupted .pst files, are sold for (often much) more money than the Outlook program is sold itself (even if you buy it separately from MS "Office"). But then, most experts agree that the MS programming style (cf. Word's outlining function, being so bad it nourished a whole outlining industry) is certainly not to be imitated, so it cannot reasonably be put forward that creating monster files containing data, instead of just reference addresses, is of any value - whereas the sheer multiplication of (possibly as standardized as possible) files is industry standard today and will be there forever.
Reply With Quote