RuDI Mindmap
Submitted by martin konold on Wed, 08/31/2005 - 10:58
|
KDE Developer's Journals
|
RuDI Mindmap
Submitted by martin konold on Wed, 08/31/2005 - 10:58
|
SearchRecent blog posts
User loginNavigationPollWho's onlineThere are currently 0 users and 66 guests online.
Syndicate |
RuDI->services->databases?
Cool, however I believe RuDI->services->databases is missing here. I mean, relational/object-relational database connectivity provided as a platform-wide service (wooh what a description), something diferent than ioslaves. A building block, available when you're rather dealing with relational data structures in your application.
RuDI->services->databases?
Yeah, I agree with you!
Which features do you think shall a desktop database service provide?
Will GNOME also be able to provide such a service? Which applications might want to use it?
The list of services is not meant to be finite. It is currently only a collection of the most obvious and of course open for discussion.
Cornelius Schumacher also mentioned that it might be possible to provide a configuration service so that 3rd party applications can read/write desktop configuration options.
I have not made up my mind about that though.
Sharing DB features
Martin, thx for your opinion.
Among other more sophisticated use cases:
I don't know about their plans, but the fact is that GNOME already provides GNOME-DB framework quite largely used by GNOME apps.
About reusing KDE/GNOME db services provided by frameworks: at KexiDB level it may be possible to write a db driver wrappers to connect via GNOME DB, but as long both frameworks are able to utilize many database backends, the question is "why to wrap the stuff each-other".
OTOH, DB-related dialogs, (see 2. above) could be easier turned into a service...
Talking about sharing standards not being services in strict meaning, it my be easy to share connection data (see 3. above).
Any application that can define data structures and take advantage of making some of its data easier shareable and secured using database engine, so most obvious choice is: Office and Kontact apps and any apps doing dataprocessing. Having that, users can build a vertical (automated) solutions on top of the applications - chances are that KDE may be able to break into vertical applications area as well.