[Owncloud] Re: GSoC 2011 ownCloud Sync Client , drop-box survey

[Riccardo Iaconelli]

Hi!

On Thursday 05 May 2011 23:28:44 kunal ghosh wrote:
> Hi,
> Today i had a look at what Drop Box(DB) has to offer, since my proposed work
> is to bring a bropbox-like sync functionality.

Thanks for this, it is insanely useful. :)
 
> I will list out the features of the DB sync-Client I noticed:
> 
> 1. Selective sync of *folders.*

I have ideas on how to do this one

> 2. LAN Sync.

I have not many ideas on how to do that, and I think it's a pretty complex 
feature. Certainly out of scope for this GSoC, but let's keep it in mind for 
the future.

> 3. files in the *Public Folder* get standalone links.

This is a must-have.

> 4. Proxy configurations.
> 5. Bandwidth shaping.

This is for the client side: i don't really know how to do that, but 
libfunambol uses libcurl, so we might be able to do that. However, i don't 
think it's too much of a high priority for now.

> 6. Shows storage space remaining in the Cloud Server.

Yes, and also we need to integrate SyncML and webinterface storages.

> 7. *Doesn't resolve merge conflicts (User Decides Model)
> *8. Sharing files/folder with friends , *All must have dropbox accounts :(

Let's see how this can work, also with the other GSoC guys.

> *9. Uses Deltas for large file syncs. (Syncs only the changes)

This is already pretty much implemented in SyncML, we can work a little bit on 
the client, but it's definitely doable

> 10. Locks file when sync commences.
> 11. Uses Inotify in linux to monitor filesystem changes.

Very doable indeed. :)
 
> All that DB does, is syncs folders, and most people seem to be happy with
> it. After all contact sync , calender sync are all semantics on top
> of a simple file sync.

I'm not overly convinced about that: if we can sync data besides files it's 
much better: you will be able to transparently sync your address book with as 
many devices as you want, without having to rely on a single representation of 
contacts, and other PIM data.
If you then add (for example) bookmark syncing, or metadata syncing... they're 
not really files (even if they can be stored as such). :)

And you will be able to perform more optimized synchronizations too, if you 
know how the data is.

> After our interaction over IRC I had a look at what funambol has to offer.
> Its an amazing project and has a lot of apps (android , iphone etc) so its
> definitely worth
> a look. But a small caveat is that the server portion is written in java,
> and the goal of ownCloud is to support php based , "el-cheapo" web hosting
> services as well.

I agree, the point is that we wouldn't use the "Funambol" protocol, but 
SyncML, which is a standard! The funambol server is written in Java, but there 
are PHP libraries that implement the same protocol (even if they don't seem to 
be very reliable) which we can improve, or go for a self-implemented solution, 
or... something else!

I'm convinced that SyncML is the way to go here, because it would mean that we 
would already have a library for the client, and several possibilities for the 
server. I think that the first thing to do is decide what server we are going 
to use and what options we have on that one.

> So we have to look at a fall-back strategy, where in , if people are hosting
> ownCloud server on their personal infrastructure / Amazon Web Services then
> they should
> have an option of using the more feature rich Funambol server + ownCloud.

My /idea/ would be to fall back on PHP and only do a more basic sync (maybe 
PIM only?) in this case.

However, I think we should just do some research and see what are the options 
on the table, and then build up a plan.

> Questions:
> 
> 1. Funambol server uses a database to store all files right ? Photo albums ,
> contacts etc are stored in the database.

I *guess* so. Fortunately they have a mailing list 
(users at core.forge.funambol.org) where they seem to be very responsive - we 
should probably just ask them in case of doubts. :)

There is also the #funambol IRC channel but that one seems a little less 
active...

> 2. As a first step how about, we work on the php backend, and the
> sync-client (opensync python API based ) ? We could use the funambol
> as a starting point to look at how to approach the server-side (php backend)
> sync.

So, proposed steps of action:

1) Gather documentation about existing solutions and how we could integrate 
them into ownCloud
2) Discuss it with everyone else on ownCloud ML
3) Arrive to a definitive plan and document it in the wiki

I think that if we manage to complete this we're already at a very good point. 
:)

What do you think?

Bye,
-Riccardo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20110506/0abc1a47/attachment.sig>