I don't quite understand.

Can you be more concrete? Which fields would be in file vs. "object"? Which
fields currently in file do you feel are too specific?

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?

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"?





On Sat, Aug 6, 2016 at 9:35 AM, Aleksa Sarai <[email protected]> wrote:

> Hi all,
>
> One thing that slightly worries me about the camlistore schema is that
> generic objects (like an image or a video or my tax return) are very
> tightly bound to the file representation they had when I stuffed them
> into Camlistore. Now, this is all well-and-good for if you wanted to
> store a database or something which is very clearly a file and nothing
> more. But for me, images and videos are clearly quite different from
> just "a file". Sure, you can store them as files but they should be
> considered an object of their own.
>
> All of this droning on brings me to my point, I propose that we add
> another layer of indirection to the camlistore file schema. So rather
> than a file directly pointing at the contents like this:
>
> [permanode ->] file -> parts (contents)
>
> We would do something like this:
>
> [permanode ->] file -> object -> parts (contents)
>
> I couldn't think of a better name than "object" (I was going to call
> it "type" but that's even worse). The point of all of this being that
> you can now tag an image as an abstract object without having to tag
> the file description of that image. IMO the cool thing about this is
> that then you could create higher level objects in camlistore that
> reference an image without necessarily referencing a particular file
> that the image existed as at one point. Personally, I think this is a
> much more aesthetic way of abstracting a file representation of an
> object from the object itself. But maybe I'm just a purist. ;)
>
> Now, this obviously breaks the schema. But we could make the old way
> of doing it (file -> parts) as a legacy mode that implies an
> intermediate object of type "raw" (or something like that, where
> there's no object data attached to the contents of the file).
>
> What do you all think?
>
> --
> 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.

Reply via email to