> Can you be more concrete? Which fields would be in file vs. "object"? > Which fields currently in file do you feel are too specific? >
See below. Also, it's the permanode that gets tagged, not the file, yet in your second > scenario you still have the permanode at the top referencing the same file. > What does that get you? > Right, so I've become more familiar with the schema since I posted my proposal. Currently, we tag the permanode not the file. But that doesn't change my point (though it changes what I'm proposing). Currently have this as the structure of any "image": permanode -> file -> parts (content) My concern is that we are tightly binding the abstract concept of an "image" to the file-based representation. For example, the twitter importer creates fake files to import images -- why is that necessary? A filesystem is just one method of representing structure, and since that particular image didn't come from a local filesystem then pretending that it should be treated like a filesystem doesn't make sense IMO. So, here's what I would suggest: permanode -> file -> permanode [this is the "object"] -> parts (content) The point being that now you could create a new node that references the "object" that is the image without referencing a file-based representation. In addition, tagging would be done _on the image, not on the file-based representation of the image. Also, RE: the tagging of the permanode, does the indexer correctly deal with having two images with the *same content* but different file structure being tagged? Do you have to double-tag the images because the files (and thus the permanodes) are different? IMO this is something that could be solved inside the *schema* (not in the indexer) by abstracting the file-based representation > > Do you know that we have the "bytes" schema type, for referencing just a > series of bytes, without permissions, filename, etc? Is that what you meant > by "object"? > > Yes, I saw that. And in fact, that means we could just make it like this (reducing the amount of work): permanode -> file -> permanode [this is the "object"] -> bytes -> parts (content) The only obvious concern would be that you'd have to make the indexer deal with tags of the "object" propogating to the file-based representation (thus meaning that tags are transitive). But maybe that wouldn't be necessary (we could just display the images without pretending that they're files in the webui, and the file-based view would only be useful for FUSE or things like that). Does that make more sense? -- Aleksa Sarai https://www.cyphar.com/ -- You received this message because you are subscribed to the Google Groups "Camlistore" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
