On 7 August 2016 at 07:03, Aleksa Sarai <[email protected]> wrote: > >> 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
I'm not sure now what you mean by tagging, but I feel obliged to emphasize that in the Camlistore model, the permanode is the representation of your object. It's the only entity that gets (mutable) attributes (through claims), which is why it is the one being tagged. So if you think the two images are different objects then you assign each of them to a different permanode, that you will both tag however you like. If not, then there's nothing to worry about, is there? >> 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. -- 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.
