2011/4/7 Dr. Robert Marmorstein <robert@narnia.homeunix.com>
The "right" solution is to integrate basket with Akonadi so that the storage
of notes, baskets, tags, and so forth can be done using any of the modules
Akonadi supports (an IMAP server, flat files, etc).

We've had different people start looking at that, including one GSoC proposal
(that didn't get accepted -- it would have if kdepim got one more slot...),
but it's a difficult task.  The way the source code is organized right now makes
it hard to get all the pieces (tags, emblems, etc) together in one place and
represent them as items and collections.

It's something I've been meaning to play with for a long time, but I haven't
had much development time recently -- and most of the time I've had, I am
spending fixing bugs on the software I use on a daily basis (such as  koffice)
rather than basket (which my wife uses).

Robert

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
> 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

------------------------------------------------------------------------------
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

Yeah, this is a feature I would very appreciate too :)

I have been thinking on such things for personal projects by the past, I see two kind of models :

o First, we can consider the basket as being static.
I mean, we need to commit changes once (when the user saves or when he closes the app for example). In this case, the proper way to get things done is -I think- to adopt the versionning approach (SVN or git for example) : we push changes to a remote repo.
+ : this way we can easily manage conflicts, multiple files, asynchronous access on different files : "synchronized-basket" is finally only a frontend for an underlying techno (git/ssh/hg/...) to easily handle commit conflicts.
- : we lose the encrypted functionality

o We can consider a basket as a moving object
Typically, http://piratepad.net/rxnwDk9tll
, a place where multiple users can write at the same time, it's the "Google Docs" paradigm, see ref1
+ : there is no more conflict, plus the encrypted functionnality can be kept (SSL + a real time decoding/encoding layer)
- : how to make it real ?! → sounds huge
One response is the wave protocol : http://www.waveprotocol.org/
This protocol defines such a real time editing approach
Problems are :
- : for now it's only a draft (just try to built it and run locally... :(  )
- : the server part is written in java, it's like maintaining two different projects for you :(
- : waveprotocol is meant to grow fast, keeping it compatible with basket could be a killing task

In parallel to that, we have to consider the server side : what's easier btw a svn server, a wave server or a personal ftp server ?
Unquestionably it's the FTP one... and FTP is just not compatible with any two approachs I described before without reinventing the wheel (= moving the remote code for managing commits, asynchronous access, conflicts directly in the basket app)

So the solution of this big equation is somewhere between
- the flexibility we want
- how many developers are there
- what the user has as a server


If we eliminate the asynchronous access, a ftp server with folders, textfiles and lockfiles is far enough to me :)
plus, this would be compatible with a dropbox server with nearly no more effort, and it's very a good point at a time where people don't care about those strange F,T and P letters, and anyway don't want to.

That was my two cents :)

Romain.

def1: http://en.wikipedia.org/wiki/Collaborative_real-time_editor