[ghns] Renewed collaboration among data sharing frameworks
spillner at kde.org
Mon Apr 16 22:53:01 PDT 2007
Am Montag, 16. April 2007 16:10 schrieb Sebastian Pösterl:
> In addition, I have some questions to clarify that I understand the
> concept correctly. On the server runs a Webservice and the client
> connects to it. Is the client a desktop application (KNewStuff I guess)
> or a webpage? Does the Webservice also handle up/downloading or does it
> just present data? And what do I need to do to setup such a service?
There doesn't have to be a web service running - in fact most of the time we
use simple XML files, auto-generated or not. There can be a web service in
addition so that a back channel can be opened for users to contribute ratings
and comments, which could only awfully be handled through file uploads.
KNewStuff is a library which is used by applications. There are also other
clients to access GHNS repositories. If you want access through the web, you
can try out the popular kde-look.org et. al. sites (non-free but good
design), or the Cocodrilo template engine (free but no good templates
available yet), e.g.:
> I dont' know if D-Bus makes sense in your case, because the goals GHNS
> and NSM want to achieve are quite different. GHNS wants to provide a
> platform that makes it easy to share documents (e.g. wallpapers,
> pictures, PDFs). Therefore, it's aimed to make a end-user's life easier.
This observation is fully correct.
> On the other hand, NSM is aimed to be used by developers. The idea is
> that many applications have plugins but only some have a mechanism to
> update or download additional plugins easily. Therefore, I want to
> provide a framework to make it easy for developers to equip their
> application with a plugin update mechanism.
That's also the goal of GHNS. We already distribute extensions to e.g. the
Quanta+ web editor through GHNS. In KDE 4, we'll have the Kross framework for
embeddable scripts, and expect a lot more applications to distribute
extensions through GHNS.
It's not just data files for the "end user".
> The NSM daemon runs on the
> user's computer. Whereas the developer has to upload a XML file that
> contains a list of plugins to a server. In this context using D-Bus
> makes perfectly sense, because the developer should be free to choice a
> language. All in all, the end-user should not even recognize that NSM
> even exists.
I see. So the design choice to use D-Bus has been made to accomodate the high
number of programming languages. We don't use D-Bus in KNewStuff2, but the
API only has two main entry points, namely a method for upload and one for
download. Wrapping those for other languages or D-Bus should be possible.
> I think you're project is really cool and fits perfectly in the web 2.0
> world, but I hope that I could make it clear that the only common
> property is that both download stuff. Therefore, I don't think it would
> be that easy to merge both projects or adjust one to another.
Upload, versioning etc. is not on your roadmap at all?
I could make our engine (which runs beneath the dialogs) persistent and write
a proof-of-concept D-Bus integration. Most of the engine's work relies on
cache files, thus turning it into a long-running daemon would be possible and
could probably help you understanding the similarities.
P.S. There is a point of irony in the web 2.0 statement from a computer
science perspective :-)
Web services are RPC, while D-Bus is IPC, so both are the same thing just on
More information about the ghns