Karl Czajkowski wrote:
Yes, I entirely agree. I guess it is out of scope though, if the RSS result is just a list of candidates rather than some obligation of service. Filtering and ordering should be sufficient, rather than the added difficulty of precise monetized (linear) values.
Getting rid of the obligation simplifies many other things too (e.g. the relationship of resource selection to deployment, which is what prompted the decision in the first place). Pricing models are a topic for some other time; for now, stating that they need to exist and will inform the decisions taken by the agents in the system is probably good enough while we work on the other details of the arch...
Right; as I was trying to describe in response to Dave's question, I think the boundaries of what is to be accomplished must be set pretty specifically, because different protocols will be appropriate depending on the kind of information that can be revealed (and the sizes of the various data for realistic environments).
This sort of thing is why I was pleased to start thinking of things in terms of ordered sets delivered through WS-Enumeration (and I'm told that RSS permits similar stuff, but I don't know the details of that). It means that the "ten thousand candidates" case goes away in practice because you can probably use the first few and have things good enough. Once you no longer have to deal with enormous quantities of data, you can get away with using any description system that works. (Real large data wouldn't get shipped through the brokering system anyway; that'd go by something like GridFTP to the agreed target using agreed network resources, or something like that.) Donal.