Bug#88486: libapt-pkg: Accessor methods for OpProgress, threadsafety
[Removed deity@l.d.o from the CC list, as the BTS will automatically copy
the list]
On Mon, 5 Mar 2001, Jason Gunthorpe wrote:
> > extending my wish to pkgAcquireStatus, as I will also need to query this
> > progress indicator remotely. Are there any plans to merge these classes
> > into one, so people will have to pass fewer pointers around?
> Really, these are all ment to be event driven interfaces, not polled. You
> are using them wrong.
Then these classes need a notification registry as well. :-)
What I'm trying to do is a daemon that runs in the background but can be
queried about the current status. Registering for status updates (via a
notification system) was planned for later, when the daemon works. This
works fine when I only use my extended interface, which allows for
queries.
I'd like to have this interface in the superclass, so the other OpProgress
implementations will inherit it. This would make "foreground mode" for my
daemon rather easy, I just take an OpTextProgress as the progress
indicator.
Thinking about this, I could also implement a notification system for my
OpProgress class and, if the daemon is in foreground mode, attach an
OpTextProgress to it.
Okay, so the questions remaining are:
1. Should OpProgress get a notification system, or should I do that in my
classes only?
2. Will OpProgress and pkgAcquireStatus eventually get merged (makes
writing multithreaded apps easier, plus its gets us an ETA on
reading the package lists)?
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Reply to: