what are the details of the data structures and access api from the kde point of view?
On Thu Mar 15 14:47 , Kevin Krammer <[EMAIL PROTECTED]> sent: >Hello GNUmed developers, > > > >I'm sorry it took so long to prepare a reply to Karsten's info about > >integration requirements, I'll try to also address some of the issues you > >have according to the mailinglist archives. > > > >Basically I approached Karsten at a German Linux event and mentioned that an > >integration/interaction with KOrganizer might qualify as a student project > >for Google's Summer of Code, where KDE will once again be a mentoring > >organisation. > > > >Just doing KOrganizer interaction is unlikely enough for this purpose, since > >the students should have enough work for about three months "full time". > > > >However, depending on your needs and goals, it might be an option to extend > >this into a more generic PIM (personal information management) integration, > >i.e. appointments, contacts, possibly syncing with PDAs, etc. > > > >For any such integration there are basically two options: > > > >1) GNUmed being the data source and KDE applications being used to handle > >visualization/input > > > >2) KDE being the data source and the front end and GNUmed delegating tasks to > >KDE's PIM applications > > > >ad 1) > >KDE's PIM applications, e.g. addressbook, organizer, can have plugin based > >data sources (called resources) and if you already have the respective PIM > >data in your postgres database, handling this data through KDE applications > >should be doable by providing KDE PIM resource plugins which access your > >database. > > > >ad 2) > >this approach is closer to Karsten's suggestion of "remote" controlling > >KOrganizer through the DCOP inter-process-communication interface. > >From KDE's point of view this would be interesting in the sense of GNUmed > >being an ISV (independent software vendor) integrating with our platform, > >something we want to emphasise and encourage in the upcoming KDE4 era. > > > >Option (1) has the advantage that you stay in control of the data, i.e. a user > >can always switch to a different front end, option (2) has the advantage that > >the respective PIM framework can usually handle a variety of storage options, > >e.g. local files, groupware server, etc. > > > >Some of the questions I saw in the archives: > > > >- can KOrganizer run without "full KDE": one does not need to run a KDE > >desktop session in order to use KDE applications, for example it is quite > >common that usersof other desktop environments use K3b for CD burning or > >Amarok for music playing > > > >- what if KOrganizer isn't installed: as Karsten already mentioned, this can > >be detected at runtime. > > > >- what to do on proprietary platforms, e.g. Windows: neither KDE nor > >KOrganizer are currently available on Windows (only available as X11 > >applications on Mac OSX). This will be an option once KDE4.0 is released, but > >this is likely too far in the future for your needs (depends on your > >timeframe for this kind of features) > > > >Cheers, > >Kevin > > > >-- > >Kevin Krammer, KDE developer, xdg-utils developer > >KDE user support, developer mentoring > _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
