2007/5/21, Joe Shaw <<a href="mailto:joe@joeshaw.org">joe@joeshaw.org</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey,<br><br>On 5/20/07, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote:<br>> Right. That was not entirely thought through. I must admit that I find<br>>
<a href="http://beagle-project.org/Writing_clients">http://beagle-project.org/Writing_clients</a> a bit confusing<br>> though.<br><br>Ah, I hadn't actually read that page.<br><br>> As far as I can tell from your words here I gather that Beagles
<br>> HitType means "this-is-a" and that the FileType means "this-comes-from", but<br>> that's not how I read that site (fx. Document is a FileType whereas I would<br>> expect it to be a HitType with FileType=File).
<br><br>No, you're getting them backward. HitType is basically "this comes<br>from" -- hence "File", "Email", "WebHistory" but nothing more specific<br>than that. FileType is "this is a". You can think of it basically as
<br>more general but in the same idea as a MIME type. That is,<br>application/pdf and application/msword are both "document".<br>image/jpeg, image/gif, and image/png are all "image".</blockquote><div>
<br><br>Yes, I realised that I got it backwards right after clicking "send" - where is that spec for the all-encompassing-undo-button? :-)<br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> The Category is what Beagle calls HitType.<br><br>(You mean FileType here.) What is the purpose of having a hierarchy<br>for Category? What would "File" have that would trickle down to all<br>of "Video", "Document", "Archive", etc. You had better not say
<br>"filename", because email attachments often don't have them. :)</blockquote><div><br><br>Right, it might very well be overkill to have a tree structure on the sources. I just figured that since we already have tree structures for defining fields and categories it would only be natural that sources where defined in a tree too. So this was mostly in the name of coherency than inspired by actual needs :-) Just brainstorming...
<br><br>Evgeny suggested on IRC that the source could be specified in the Category field of an object. The cat field would have to be multivalued so that you could set the cats of an image in a zip-ball to "cat:Image" and "src:Archive". This coupled with a flat structure on the source spec might be what we are after...
<br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> The Source is where the object originates from, a more general<br>> thing than Beagles FileType.
<br><br>(You mean HitType here.) This seems reasonable, although "Source" in<br>Beagle means the specific backend which generated it. But that's just<br>a terminology issue.<br><br>> Fields are "properties" that are available according to the spec of the
<br>> category and the source.<br><br>Yeah, that makes sense.<br><br>> Then fx there could be a SourceURI field so that you could determine that a<br>> given image with source=Archive was from a zip file attached to and email...
<br><br>Yep, in Beagle this is called the ParentUri, and that's what gets<br>opened by the UIs.</blockquote><div><br>Good, I was also trying to keep a bit in the spirit of beagle.<br><br></div>Cheers,<br>
Mikkel</div><br>