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. Niall. > > Dave
