[ghns] Renewed collaboration among data sharing frameworks

[Josef Spillner]

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.:
http://new.kstuff.org/~josef/datarepos.png

> 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.

Josef

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 
different distances.