2013-04-10, 21:05
Ok, some refinements:
Local Folder Structure
Every source folder will have a unique local folder. This local folder will automatically be set to sth. like (and stored in the db):
LocalPath: special://userdata/cache/{HASH_OF_THE_SOURCE_FOLDER_PATH}/
That way we can still keep the remote folder structure, we can deal with two source folders having the same file(-name) inside and we don't complicate the setup with an additional wizard or anything.
Now I could expose a context menu in the Source management window with a "set local folder path". So, if someone cares, he can still control it.
Sync Policies
As mentioned earlier, sync policies will be normal service plugins that listen to events. (I probably need to expose a few new events? E.g. is a service script notified when a item gets added to favourites?).
Now some pseudo code, on what such a plugin would do:
Also xbmc should store which policies wanted what file locally, so we only remove a local copy, if there isn't any policie left who wants it.
As an alternative, Sync policies could be a new kind of addon, that have to return a bool (true indicating, it wants the file locally) and the above if/else logic could be handled in core. Preferences?
@juxta: So yes, a sync policy would also be responsible for removing local copies. In your case "DoWeWantItLocally" would just need to return true, if the file is unwatched
@Oxyg3n: So you basically want to "push" items to a mobile device. My idea was that the mobile device "pulls" them. I don't see a big issue why this could not be supported as well. Doesn't the UPNP server now have a feature like "play to"? Perhaps that could be extended to also allow "copy to".
Local Folder Structure
Every source folder will have a unique local folder. This local folder will automatically be set to sth. like (and stored in the db):
LocalPath: special://userdata/cache/{HASH_OF_THE_SOURCE_FOLDER_PATH}/
That way we can still keep the remote folder structure, we can deal with two source folders having the same file(-name) inside and we don't complicate the setup with an additional wizard or anything.
Now I could expose a context menu in the Source management window with a "set local folder path". So, if someone cares, he can still control it.
Sync Policies
As mentioned earlier, sync policies will be normal service plugins that listen to events. (I probably need to expose a few new events? E.g. is a service script notified when a item gets added to favourites?).
Now some pseudo code, on what such a plugin would do:
Code:
bool DoWeWantItLocally(item)
{
//TODO: sync policie related
}
OnEvent(item)
{
if(DoWeWantItLocally(item))
xbmc.MakeLocalCopy(item)
else
if(xbmc.IsLocallyAvailable(item))
xbmc.RemoveLocalCopy(item)
}
As an alternative, Sync policies could be a new kind of addon, that have to return a bool (true indicating, it wants the file locally) and the above if/else logic could be handled in core. Preferences?
@juxta: So yes, a sync policy would also be responsible for removing local copies. In your case "DoWeWantItLocally" would just need to return true, if the file is unwatched
@Oxyg3n: So you basically want to "push" items to a mobile device. My idea was that the mobile device "pulls" them. I don't see a big issue why this could not be supported as well. Doesn't the UPNP server now have a feature like "play to"? Perhaps that could be extended to also allow "copy to".