> Like any good basket user with multiple boxes in multiple locations, I > religiously 'backup' my baskets, put the gzip file in a location I can get to > it > via rsync or http to copy it to work/etc.. and then 'restore' my basket store > on > multiple machines. It just seems to me that in this day and age, I should be > able to put the basket storage on a server with local and remote access so I > could just read/write to the network basket location without having to > 'backup' > and 'restore' on each box I have basket installed on. > > I don't know how difficult something like this is to implement, but with > fish://, sftp:// or just plain old ftp://, it seems like this should be > doable.
It does seem doable but it's not a straight forward task to do it right. Remember basket isn't set up for having multiple access at the same data store. > Anybody ever looked into something like this? Kelvie has a published basket of what he has. And recently (when I had a lot more time) I was looking into it. I never wrote any code but I was playing around with different designs on paper. My solution feels hackish, even though I've removed the requirement to have it file based (so I didn't do any abstraction). But I like the file aspect. My next step was to discuss on here what we wanted out of it. So I started with the simple common use case where people have 2 machines connected at all times. One desktop and one laptop. Since they only use at a time and they are connected to the net, syncing is straight forward. Whether we want a centralized (at one of the 2 machines, or a third being a server). Next was the fact that thinking into the future, when I get a smart phone I'd really like to have access to my baskets. Not really huge idea change, since for the most part the phone is always connected too. It wouldn't really need a local store even. Although if you get a bad signal you don't have your baskets isn't ideal to me. Next was back to the laptop. It's a laptop so I'm going to disconnect it sometimes. Again, local store is really needed. But then I do some updates on there. And then I might do a change something on the desktop before I resync them again. And that's where the issue comes in: Off line editing. Now Kelvie has mentioned the git model. And I think that is a nice way of going. But I'm not sure how we'd want to implement it. If we just take the idea and not the code (we could use a DB as a backend), I'm concerned that we'll get a huge growing history. I'm not sure what that would do for speed and size, but perhaps we could have a cut off, where all things are to be at a known sync point. Another thing is that at what level would one do the git diffs. I mean is it the entire basket change or would it be each property of the basket (mostly an issue an creation, not in modification). And with encrypted baskets do we really want each iteration in the history? What if we encrypt of decrypt something. We could try to stick with the git code as a back end, lets us use the files we have now. But again the encryption issue, and then merging as well. Which brings me back to merging. What if there is a conflict? Do we give an option to do an easy merge (as in take the note with the most recent time) so to help out new users. Also, I'm not sure how tide in this could be with the undo/redo aspect because of the encrypt/decrypt problem. Also, what if someone wanted to use it across an office, what about locking the notes during edits. Now I'm now sure how serious this issue is, because a wiki may be more useful in that case. But maybe we could have a read only setting, so only one machine can change a basket. I'm just trying to see how flexible if we have to rewrite a lot. Oh and of course we'd need to have encryption on the syncing, especially in the smart phone case. Oh and I'd just like to throw out there that QT with MySql doesn't quite have SSL. There's a patch (I haven't tried it) but it's been around for a while and hasn't been included yet. Oh, and for a key my idea was just to sha the creation time, user, and host name altogether. to ensure uniqueness. I think I wrote all my issues. Everything should be paragraph separated so that it's easier to discuss. When I get time to make a proper sql schema I'll send that out. For a timeline, I'm not thinking soon. A solid beta within 2 years, although that's calculated with me just solely writing code, which I hope won't happen. Scott ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
