GSoC application review - reimplementing personal metadata importers

[Matěj Laitl]

On 24. 4. 2013 Konrad Zemek wrote:
> On 22.04.2013 14:56, Matěj Laitl wrote:
> > I see, good luck with your exams! The deadline for proposals is May 3, so
> > maybe you'll manage to at least submit a small change by then.
> 
> I've just submitted a small patch which just "happened" as I was working
> on some other things. What I'm worried about is that every GSoC resource
> states in bold letters that application should be submitted early rather
> than late.

Yes, but you should be able to edit the submitted application (please check, I 
may not recall correctly).

> > Good. Note that "added to collection" is currently not part of
> > synchronization. (you could add it, but maybe it isn't worth the effort)
> 
> I removed it from the description. Rating, playcount and last time
> played are already enough, and I think "time added to collection" is
> actually a bit of a shady thing to synchronize (i.e. I'm not sure if
> it's even correct to synchronize it).

Right, my thinking is very similar.

> > Also note that current iTunes import matches tracks by just filenames. I
> > secretly hope that one can get metadata (at least: artist, album, title;
> > better also: track number, disc number, album artist) out of iTunes db,
> > but please check - inability to do so would be a show-stopper for iTunes
> > provider.
> 
> Are you certain about that?

No, but the current iTunes importer doesn't offer option "match by meta tags" 
and from quick glance at the code it doesn't do such matching. (I may be 
wrong)

> I reviewed iTunes importer, and it reads
> information from an XML file. iTunes maintains an "iTunes Library.XML"
> file for the purpose of compatibility with other applications, and
> although I couldn't find an official specification for it, I found some
> example databases which contained all of the metadata you mention (and
> some more).

Good then.

> > Sounds good, except for the renaming. StatSyncing::ITunesProvider sounds
> > well for both cases.
> 
> I actually had a conception to leave importers where they are, or in a
> directory called simply importers.

Well, for class names I'd stick to nomenclature of the "parent" framework - we 
loosely name implementations after ABCs, like Collection -> MtpCollection, 
Track -> SqlTrack etc. Notice that the statsyncing framework supports equally 
read-write providers (CollectionProvider) and read-only ones (Last.fm).

For code location I'd stick to src/statsyncing/* and set fire on 
src/databaseimporter - no need to keep historic cruft.

> After implementing two-way
> synchronization, importing would be only one of capabilities (the other
> being of course exporting), so that name would no longer be appropriate.

This is my point + there is no strict separation between "import" and "export" 
in the StatSyncing framework.

> I removed the mention about renaming because it's too insignificant to
> even mention there, and especially considering how much explanation is
> needed for it to make sense.

Right, take the above comments as my suggestions for actual implementation 
rather than the proposal.

Cheers,
	Matěj