Posts: 8
Joined: Jul 2012
Reputation:
0
2013-04-15, 09:38
(This post was last modified: 2013-04-15, 09:41 by otzy_007.)
Regarding the Focus on a distributed model project. Is someone assigned to it?
Can we discuss about it?
I've been thinking of something like a sync service.
For example: you mark a movie as watched on your tablet and if the same movie is also on your htpc it will be marked too as watched during the sync process.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
I suggest starting with:
1. Take a quick look through the PRs that went in in April. Hint: There was one related to your idea.
2. Outline your idea here in detail. Highlight which bits XBMC is missing and detail your ideas as to how you might go about adding/fixing them.
Posts: 8
Joined: Jul 2012
Reputation:
0
It's kind of the same thing what I've proposed, only that he is sending the information on a central server. I was thinking of storing the information on the machine, making it something like a server and the others getting the migrations from it.
My way every machine will be a server for the others and a client searching for migrations in the network.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
The above PR stores the watched information at the source. i.e. if it comes from a upnp server, then you mark it as watched or in progress on the server, so that all clients of that server get that information. If you're playing something on the server, then marking something as watched there will also show as watched on the clients.
Your idea has some sort of common library/database on each machine, with messages being passed between machines to update when any one of them updates?
Posts: 8
Joined: Jul 2012
Reputation:
0
Something like that. The machines have their own databases. The databases don't need to have the same data.
When something in the database of machine 1 (M1) is modified a file containing that database query is generated and stored into a file , let's call it migration-date-time. (Something like migrations into Rails, only that our migrations will change the data, not the db structure).
All those migrations are stored into a shared folder.
Machine 2 (M2) will get the migrations from M1's shared folder and merge the relevant one.
We can implement also a message passing (MPI like) migration system, but only the online machines will change the database. M2 will apply the migration from M1 but if we start a third machine M3 after the message has been passed it will not receive the migration.
We still need a way to apply the migrations for those machines.
Having a shared folder on M1 and M2, M3 will access those folders and apply all the migrations newer than the last merged migration.
Even the shared folder model has it's down sides. M2 and M3 will not know when M1 generated a migration, unless M1 will broadcast a message to tell them that there's a new migration available.
Maybe the best way is to combine message passing and shared folder, message passing for the online machines and shared folder for the ones that will come online later.
Posts: 17,859
Joined: Jul 2011
Reputation:
371
to be honest i as user would rather have the databases talking directly with each other than through separate generated files
