[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Introduce of QCloud
From:       Weng Xuetian <wengxt () gmail ! com>
Date:       2012-10-10 12:28:55
Message-ID: 1558948.J0f9I4xUTO () chakra-zenbook
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 10 October 2012 02:30:15，Pau Garcia i Quiles :
> Hi,
> 
> Great initiative, I was missing a cloud API in C++.
> 
> From my 2 min skim-over:
> 
> - Why the dependency on DBus instead of making each application access
> directly the storage?
Since at the very first, I want to have a application that can, easy to talk, 
can do encrptyion and packaging (from the idea that we don't trust the cloud 
provider), with account-application-map management, that's why daemon is 
there.
> 
> - Why use the backend name directly (Dropbox* db = new Dropbox(); )
> instead of taking a string, enumerate or something like that? If
> QCloud is going to offer a common interface (a-la libcloud, jclouds,
> fog, etc), then hardcoding the classname favors code duplication
> 
Ah, this is because all backend currently is being created by QCloud::Factory, 
backend/ is a qplugin for core, from QCloud::Factory you create Backend with 
string.

If you're talking about test/dropbox/, that's where I want to test dropbox 
directly, so it usess new dropbox directly.
> - Examples? (apart from the tests)
> 
Emmm... maybe you want look at kio/, tool/ and daemon/ ?
kio currently list all account in the root, and can be used to browse file 
under that account. (While the dropbox api key is still under dev mode so you 
maybe want to write a different key into data/testapp.

I'd like to state it's still in an early state though..
["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]