Berin Loritsch wrote:
Filip Defoort wrote:


I haven't completely read all your suggestions yet, but here's already a further description of what I'm working on: I'm working on a system that aggregates information from various sources.. There's different types of information (e.g. hierarchy info, metadata, annotations,...), but all of those types of information can be provided by multiple components at the same time, which need to be aggregated by the app and presented to the user (e.g. if I would ask for notes with a given query string, those notes could come from several components at the same time; they are presented in a single list to the end-user; if I would ask for the children of a node, there's no central server that manages all the possible children, but a set of providers that each can give me a couple of children which I then sort and present).

Hope this makes it a little more clear -- feel free to tell me if not!


So how does the processing work?

It's a combination of things.. For starters there are a list of
providers for each type and they get all the same queries. There's
also some functions where providers of one type can hook up/recommend
providers of another type (there's some intelligence in not always blindly searching all providers)


What does a query look like?

varies for each type of component... Sometimes something like
getMetaData( Item x ): MDInfo, sometimes getChildrenOfType( Item parent, String childType): Item[].



Do you apply the same query string to all the providers, or do you find providers based on the query string?

Another alternative to what I described in the last email is to use
configurations to your advantage.  In other words, your ProviderManager
would still delegate to the individual Providers, but instead of
directly creating and managing the instances, it looks through a
list of Providers that were identified in its configuration.  The
approach looses some of the automatic aspects of managing them all
yourself--but it makes the implementation of the ProviderManager
much simpler.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to