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

List:       koffice
Subject:    Re: [kplato] Fwd: Re: [kproject] Planning and Analysis 101
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-06-20 6:57:31
[Download RAW message or body]

On Wed, Jun 20, 2001 at 07:53:11PM +1000, Brad Hards wrote:
> Thomas Zander wrote:
> > 
> <snip>
> > > On Tuesday 19 June 2001 10:20 pm, Brad Hards wrote:
> <snip>
> > > > It should be supported at a KOffice level, rather than a kplato level or a
> > > > task/subproject level.
> > 
> > Maybe you missed my email on resources available without effort, it answers
> > this and other questions for you.
> > 
> > http://lists.kde.org/?l=kplato&m=99283927317049&w=2
> > 
> > In short:
> >  - don't worry about revision management.
> >  - don't worry about database support either.
> > 
> > At this time of the development cycle it is not at all interesting where or
> > how you are going to save or share your data. How to represent your data
> > internally should be the first step.
> I think I did actual see that one (half drowning in the volume and
> sophistication of the discussion :)
> 
> The question was about whether there was anything that the kio-slave would end
> up connecting to, that could handle the revision tracking, and whether there
> was a KDE front end to control a revision tracking / CM basis.

Well, as the kio-slave is not done, I can't really tell. But there will probably
be an interface via the url, which means the frond-end would have to represent
in a usable manner. 
Then again, that would be the same for everyone using it, so I would not be
surprised to see a dialog in kdelibs for that..

The coupling would be to use the kdelibs classes designed for kio-connectivity
and to stream the data in there..

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

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