On Thursday, April 07, 2011 09:01:57 AM Scott Stubbs wrote:
> > 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
> 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
> 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
> 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.
> -- Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> Basket-devel mailing list
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
Basket-devel mailing list