Asyncronous life helper (Was: EggDBus)

["Freddie Unpenstein" <fredderic excite com>]

This is a side-topic, raised by developments in handling DBus, but something I feel is worth asking...  Is 
there any mechanism for making working with asynchronous stuff easier?

Quite often I've had a situation where I've needed to collect several pieces of information from various 
asynchronous sources, and then act on them as a group only once some portion of that information is 
available.  This is becoming increasingly important as we start working with more and more remote DBus 
services, web services, Corba/Orb/whatever-its-presently-called services, and the list goes on.  Data life 
cycle and flow management keeps being a problem.

You need to:
- use a signal to catch data when it becomes available
- store that data somewhere
- distribute that data to other places when it becomes available
- clean up the data when it's no longer needed
- safely handle data sources failing or disappearing
- manage re-try timeouts, age invalidation timeouts, etc.

I sort of feel that what's needed, is a GWish which is a higher-level GBoxed embodying the whole data life 
cycle management, and I'm wondering whether there are any plans or similar ideas in the works, or even just 
whether anyone else has a working example of tackling a similar situation.

My starter concept is this; GWish will
- hold a piece of data, when it's available
- can be asked to obtain its data if it doesn't have it
- can be dependant on other GWish's (dependant data)
- ask any depedant GWishes for theirs when it is asked
- invoke a callback when ALL dependant data is available
- can be given the data to hold at any time (usually by the callback)
- signal when its data is ready (ie. when its data is set)
- only ask dependant GWish's when it itself is asked
- provide a helper function to perform the ask, and then wait
- allow the data to be invalidated without destroying the GWish
- be used internally (or at least faked externally) by async properties
- propagate data invalidation (unless blocked by a flag or ignored)
- allow some dependant data to be flagged as optional
- allow the data set callback to "fail" after requesting more data
- optionally count a dependency as a reference on that GWish
- use weak references to clean up non-referencing dependencies
- support relevant timeouts with automatic timeout cleanup
- optionally destroy itself if a dependancy gets destroyed

An application can then tie together various pieces of required data from any source (either GWish-compatible 
or wrapped in an external GWish), even user interaction, by having the final GWish dependant on other 
GWishes, some representing other intermediate shared data, and others representing source data, or simply 
stages of processing to ensure certain events occur in order regardless of what order their data becomes 
available.

I'm not sure whether GWish should be a GBoxed, or whether it should contain a GBoxed...  That would depend on 
how much overhead there is in maintaining all the signals and associated control data.  If it ends up being a 
large structure, then the data should be able to outlive it.  In either case the data should always be 
provided as a GBoxed, or a hash/keyed-list/other of GBoxed's (in the case of dependant data being handed to 
the data set callback for processing, for example).

I know this can already be done, but its fiddly and error-prone at present, and having it built into GLib and 
supported *correctly* through the property mechanism, I believe, would be of great benefit, with natural data 
life cycle handling, and take asynchronous event driven programming one huge step further towards being easy 
to do properly.


Fredderic


------------------------------------------------------------
Fashion Design Education
Career Problems? Get a Fashion Design Education. Click Now.
http://tagline.excite.com/fc/BK72PcZbqeXJW54UoWT2TpJ9AYP7lCEQjsxHtqLq0AcWua9zpgb9rF/