The goodness of goodness

[Richard Dale]

Hey, I've been thinking recently how great it would be if the KTrader/KParts
dynamic resource loading mechanism had a versioning system. I worked on a large
trading application which was written in Objective-C, that language has a class
loading feature called NSBundles, like KParts, which allow you to load code
dynamically. The application was broken up into a core, plus lots of dynamically
loaded bundles, each bundle had a version (a table of current versions was held
in a database). We could release code on a bundle by bundle (cf KPart by KPart)
basis and never need to overwrite existing code. If bundle version .17 went
horribly wrong, we just needed to revert to .16 in the database table and the
application would revert to using that one on startup.

To implement versioning to need to increment goodness for each release of a
resource, but keep a current 'best goodness' (not necessarily the
highest) somewhere. I assume KTrader allows you to set a constraint on a
specific goodness.

-- Richard


On Fri, 11 May 2001, you wrote:
> On Fri, 11 May 2001, Richard Dale wrote:
> 
> > > You could
> > > also imagine someone writing a part outside the project as a replacement
> > > for a part we have because he can handle things better with it. Then you
> > > need a simple way to decide which one to use. We could inspect the KDE
> > > mime-type dialog to think about how this can be done similar towards the
> > > user to decide which part in which order to use for which project type.
> > Do KParts have an attribute called 'goodness' or similar, for resolving this
> > sort of problem? Then you would set the goodness to a high value for a new and
> > better part than the standard one, and pick it up automatically. But you might
> > stll want to override 'goodness', so there would still be a need to select
> > parts.
> 
> Yes, there is such a mechanism. It is implemented in KTrader.
> For example, in the new editor interface, I ask the trader for
> an editor, and I pick the one the user likes best.
> 
> To tell what the user likes best, there is a Entry
> 'InitialPreference' in the service .desktop file.
> 
> The only drawback is that this is set on a per-service basis,
> so you would have to define a service type for each part where
> you think that multiple implementations might make sense.
> 
> 
> Bye,
> Matthias.
> 
> 
> 
> -
> to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
> unsubscribe your-email-address

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«