the new sync framework

[Maximilian Kossick]

On Fri, Jan 22, 2010 at 7:01 PM, Casey Link <unnamedrambler at gmail.com> wrote:
>> UnionJob: as the result of this job both collections contain the union
>> of the tracks in both collections, i.e. it adds tracks that are in
>> collection A but not in collection B to B and tracks that are in B but
>> not in A to A. It does not remove tracks from either A or B.
>>
>> OneWaySynchronizationJob: it ensures that all tracks that are in the
>> source collection are present in the target collection as well, i.e.
>> it adds tracks that are in source but not in target to target. It does
>> not remove any tracks from target. It is one half of UnionJob.
>>
>> MasterSlaveSynchronizationJob: ensures that the slave collection
>> contains exactly the same tracks as the master collection, i.e. it
>> adds tracks that are in master but not in slave to slave and removes
>> tracks that are in slave but not in master from slave.
>>
>>
>> You might want to add this as comments to the header files.
> Done.
>
> I understand the way the sync jobs are supposed to work, however there
> is a missing bit.. check out the use cases below.
>
> Use Case 1:
> User wants their ipod to have all their local tracks
> Solution:  Use Master/Slave syncjob with local=master and ipod=slave. Done.
>
> Use Case 2:
> User wants to sync only a subset of their local tracks to their ipod.
> Solution: ?
>
> How (and where) should this filtering been done. Perhaps a generic
> ProxyCollection should be created (similar to a proxymodel) that could
> be passed a Collection and a filter, then pass the ProxyCollection to
> the Master/Slave sync job.

Well, depending if you want to have just the subset on the ipod or
more tracks on the ipod from other sources but sync the subset
nevertheless you'd have to use Master/Slave syncjob or OneWayJob.

SynchronizationBaseJob::setFilter is supposed to take the same filter
syntax as is used in the collection browser, and then apply that
filter to each querymaker that it uses. That way you can easily define
the subset to use (and reuse the filter creation dialog that the
collection browser has if you want). I think I did not implement
setFilter because one would have to extract the code from
CollectionTreeItemModelBase::addFilter first.