Niall Power wrote: > On Thu, 2007-03-29 at 11:32 -0400, Dave Miner wrote: >> Niall Power wrote: >>>>>> om_getDiskPartitionInfo: why not just take a DiskInfo as the first >>>>>> argument? And what is meant by "A failure will be fatal in this case"? >>>>> The DiskInfo structure returned from om_getDiskInfo is a linked list of >>>>> DiskInfo. Why the whole structure needs to be passed back when diskName >>>>> is enough to get the partitions. >>>>> >>>> If this were the long-term design I'd be pushing strongly to have the >>>> callers not directly referencing structure members but instead using >>>> accessor functions, because that gives us much more flexibility in >>>> evolving the design, so generally I'm suggesting that callers not have >>>> to grovel around in the structures to use results from one call to make >>>> another call. >>> +1 on the accessor functions suggestion. I'm even considering writing my >>> own wrapper functions in the GUI rather than randomly poking at data >>> structures. >> That would be a bad answer from my point of view. If you're finding >> need for them, others will too, so let's put them in the right layer - >> doesn't mean you can't write them, though that's something you and Sarah >> can work out. > > Arguably yes, that would be a bad answer. What I am aiming for is to > minimise the amount of code rewriting in the GUI as orchestrator > interfaces evolve. The best way for me to do that right now is to write > some wrappers, even very light ones, so I only have to make the changes > in one place - and only have to break the gnome coding style in one > place :) > If it's presumed that the only realistic consumer of the orchestrator's > target discovery interfaces is an installer UI type of application then > I think the interfaces should be moved into the orchestrator layer also. > I'll post the set of wrappers I've written soon - right now I'm at the > beginning of trying to populate the partitioning UI using dummy data I > created based on the current design. As I progress I should get a better > understanding of how the API can be better refined to suit the GUI.
I am not sure that it is presumed that the only consumer of the orchestrator's target discovery interfaces is install UI type of application. However, that said, Sundar and I are working on a new set of interfaces that do include some of the 'getters' that you are looking for. We should have a new document out soon. Send us your wrapper functions however and we can take a look. Thanks for all your input. sarah
