Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
2008/12/10 Michael Meeks michael.me...@novell.com Hi Philip, On Tue, 2008-12-09 at 19:59 +0100, Philip Van Hoof wrote: http://live.gnome.org/Evolution/Metadata For early visitors of that page, refresh because I have added/changed quite a lot of it already. Looks really good. But I have some comments to attach and some bike sheds to paint :-) Comments on the proposal below. The only thing that I don't quite understand (the perennial problem with asynchronous interfaces), is the memory issue: it seems we need to store all Unset information on deleted mails somewhere [ unless you are a womble like me that keeps ~all mail forever ;-]. Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. That aside here are my comments: * I had personally expected something more like a harvesting API, but what you present is more like a metadata writing API. Much like the set of writing methods in http://xesam.org/main/XesamMetadataAPI. This may just be a matter of taste though. * If we are talking a harvesting metaphor (which we may not be) then it seems wrong to imply in the methods that Evo is writing the data and not just sending it * I thought Tracker needed a service type to select the right table. Of course we know we are dealing with emails here, but the API fails to generalize. * Timestamps are not mandatory in the protocol. The receiver will have to parse the payload to extract a timestamp (which is not guaranteed to be there in the first place). Without a timestamp a payload is meaningless * Is there any form of sorting mandated by the SetMany method? Fx sorting subjects by mtime? * About the Set method. What happens to predicates set on the subject that are not in the 'predicates' arg? Are they kept or deleted? Or to rephrase the question do you overwrite the entire set of metadata for the subject? I have cooked together something that should work as a generic harvesting API here: http://xesam.org/main/Drafts/XesamPMH. It should address all of the points I raise here too. -- Cheers, Mikkel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
2008/12/13 Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com 2008/12/10 Michael Meeks michael.me...@novell.com Hi Philip, On Tue, 2008-12-09 at 19:59 +0100, Philip Van Hoof wrote: http://live.gnome.org/Evolution/Metadata For early visitors of that page, refresh because I have added/changed quite a lot of it already. Looks really good. But I have some comments to attach and some bike sheds to paint :-) Comments on the proposal below. The only thing that I don't quite understand (the perennial problem with asynchronous interfaces), is the memory issue: it seems we need to store all Unset information on deleted mails somewhere [ unless you are a womble like me that keeps ~all mail forever ;-]. Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. That aside here are my comments: * I had personally expected something more like a harvesting API, but what you present is more like a metadata writing API. Much like the set of writing methods in http://xesam.org/main/XesamMetadataAPI. This may just be a matter of taste though. * If we are talking a harvesting metaphor (which we may not be) then it seems wrong to imply in the methods that Evo is writing the data and not just sending it * I thought Tracker needed a service type to select the right table. Of course we know we are dealing with emails here, but the API fails to generalize. * Timestamps are not mandatory in the protocol. The receiver will have to parse the payload to extract a timestamp (which is not guaranteed to be there in the first place). Without a timestamp a payload is meaningless * Is there any form of sorting mandated by the SetMany method? Fx sorting subjects by mtime? * About the Set method. What happens to predicates set on the subject that are not in the 'predicates' arg? Are they kept or deleted? Or to rephrase the question do you overwrite the entire set of metadata for the subject? I have cooked together something that should work as a generic harvesting API here: http://xesam.org/main/Drafts/XesamPMH. It should address all of the points I raise here too. Apart from these items I still find that there are other issues with the proposed API at: http://live.gnome.org/Evolution/Metadata * How is last_checkout calculated by the client? The local system time of the client wont do as there might be a time skew compared to the server (DBus might go over tcp). This means that the timestamp must be extracted from the received emails, this is not guaranteed to be there by the spec though. * If each mail is not guaranteed to have a timestamp how can the registrar resume an update if it was shut down when it was 90% through 100,000 emails? Ofcourse if each email _must_ have nmo:receivedDate (or some other timestamp) then these two items are non-issues. I would have prefered such crucial information to be in the API though... That said I think the idea with the CleanUp method is great! :-) -- Cheers, Mikkel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
Hi Mikkel, On Sat, 2008-12-13 at 00:18 +0100, Mikkel Kamstrup Erlandsen wrote: Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. Well, true - it's not that much data I suppose - but without an agreed lifecycle mechanism it grows without bound as you delete mail, and since we have to do a lookup prune for every new UUID we generate [ or arguably emit ], there are potential size performance issues prolly worth addressing (in some simple way) in the design. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
