[akunambol] Re: KDE owncloud client

[Riccardo Iaconelli]

Hola!
Sorry for the delay, got caught a bit up with exams.
Replies are inline:

On Thursday 27 January 2011 22:56:21 kunal wrote:
> > Hi! :)
> > I'm glad that you want to contribute to ownCloud. This is my idea of the
> > better way to implement a sync client.
> 
> If i understand correctly , ownCloud aims to be a syncML server
> which can sync with standards complaint syncML clients (on iphone,
> android, desktop (kde client))
> right?

Not too much - ownCloud aims to be a personal cloud server. It should use 
SyncML as a way to synchronize its data to KDE, and synchronization to other 
devices comes as a big bonus. It is not its only scope, just a "communication 
layer" for some (many) of its features.

> > The work would be split in two, and would mostly consist of implementing
> > the SyncML API with it. There is a well tested package which can
> > provide that - it's Funambol, which is AGPL and written in Java.
> 
> Funambol is a syncML server and has clients on all major mobile devices
> (is this necessary ?)

Not necessary, but if ownCloud is not isolated and only used by KDE 
applications, this is a huge plus for usefulness.

> Any syncML compliant client should be able to sync from any syncML
> server right ?)

Yes, at least for standard types (especially PIM). Porting simple clients to 
other platforms shouldn't be too hard, either (e.g. file sync).

> So, Funambol provides the syncML server (lacking audio and video syncing
> capabilities http://en.wikipedia.org/wiki/SyncML#SyncMLservers ) that
> ownCloud aims to be ?

Lacking audio and video is not really a problem. There is a standard "file" 
type, which can be used to sync almost everything. So this is not a big issue, 
and we'll be able to sync everything, leaving the duty of playing the file 
remotely to the webinterface.
 
> > The work would mostly consist in:
> >   - Understanding how much painful it is to ship Funambol directly
> >   with
> 
> Funambol, has a bundled Tomcat instance, so it will run as a separate
> web service
> and owncloud as a separate one. But we can make ownCloud as a wrapper
> around the
> Funambol instance so that, ownCloud uses the Funambol backend, and
> provides
> additional video, audio (sync services that funambol doesn't provide at
> the moment,
> source: wikipedia syncML servers list).

An idea - why don't we let funambol handle the syncronization side, and let 
ownCloud interface itself with the funambol storage? Or even, the other way 
around. I don't know too much of how funambol server works to make an informed 
suggestion here. Hopefully somebody who has that knowledge can fill us in 
here, or we can ask on the list. This way funambol becomes just a "data" 
backend, integrating how the software works.

> > ownCloud, and providing an easy way to install everything togehter.
> 
> hmm, i feel. we could ship a minimalist VM with everything preconfigured.
> This would also include NAT hole punching (as Hasanat kazmi proposed in
> another thread , in the owncloud mailing list).
> 
> This would be the most no - brainer for people hosting ownCloud on home
> servers, with dynamic IP addresses.

This is a good idea!

> But for hosting ownCloud + Funambol on a hosting service.How that can be
> easily done , in one step , i have no idea at the moment. It needs a bit
> more of looking into :)

Probably we can just provide instructions on how to set up ownCloud. For PHP-
only hosts, we can either implement a small subset of the capabilities (e.g. 
PIM only) through one of the several libraries, or disallow desktop 
integration. This is an area that needs exploring.

> >   - Integrating Funambol's storage with ownCloud's, or make ownCloud
> >   read
> > 
> > funambol's storage (eventually for other datatypes too, like contacts,
> > calendar, ...).
> 
> This would be the most wise thing to do , at the moment. Leverage Funambol's
> storage, and keep working on a php ( or python ) backend as you suggested
> in your next point.
>
> I am a member of the belenix dev team (belenix.org) its an OpenSolaris
> based
> distro, and we were hit hard when the oracle-sun merger happened . Suddenly
> our kernel , was closed-sourced by Oracle. So i am a bit skeptical about
> Funambol, but have no problem using it , at the moment.
> 
> Please do share your thoughts on the point above :).

After having collaborated with them for some years, I must say that it's 
usually a pleasure to work with them. They are interested in seeing this 
going, and during the development of akunambol they already provided me much 
assistance.
Also, they are the guys who invented AGPL, to ensure freedom in the clouds - 
so I think that they won't immediately close source everything. It is not 
their business strategy, and in good faith, I don't think it will hapen too 
soon.

> >   - Provide a fallback implementation in PHP (using one of the pletora
> >   of other
> > 
> > libraries available), which either implements all of the specification,
> > or just a subset of it, maybe only files, so that we don't let PHP-only
> > users down.
> 
> Yes, as pointed out above.
> 
> > All of this is just an idea, and we need to evaluate all the option with
> > SyncML solutions first, to see how well they work.
> > 
> > The client itself is already under development, and it's akunambol, of
> > which I'm the maintainer. It is currently in the process of being
> > modularized, and we are creating an API to be able to allow very easily
> > creation of different sync types.
> > 
> > Once that is in place, it would be very easy (I estimate less than 100
> > rows of code) to write the plugin to sync files. The biggest work would
> > then be integrading SyncML in ownCloud. Doing this will also bring the
> > possibility to add many other synchronization types to ownCloud, as I
> > was saying before, PIM data, or other things. Since SyncML is a
> > standard this will also allow other devices (iPhones, blackberries,
> > MeeGo ...) to sync with it.
> 
> I had another idea,
> We could provide a Funambol backend (till our implementation in php /
> python is done)
> for syncing email , contacts , Memos , tasksetc. And provide a webdav
> based interface
> for syncing Documents , music , Videos etc.

What do you mean here? I think this is a good idea, but I don't see how it 
conflicts with the other points. :)

> Also , with limited hard-disk space on netbooks and mobile phones,
> people would just want
> to access ( as in just play ) their songs etc, hosted on their cloud.I
> think a web interface
> (that we currently have) to play songs , and stream videos would be the
> way to go. The web
> interface eliminates the need for native sync clients on mobile phones.

I agree! and thanks to Qt, we are able to build lightweight UIs for that. So, 
we only need a way to get a URL to access a file, with authentication... but 
that is beyond the scope of syncing.

I hope that answers some points! :)

Bye,
-Riccardo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/akunambol/attachments/20110214/89d93e8c/attachment.sig