2011/4/7 Dr. Robert Marmorstein <rob...@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
------------------------------------------------------------------------------
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
