On 10/31/2012 05:53 PM, Scott Talbert wrote: > I've got a proposed libconcord API change to better allow Congruity to keep > its current usability (see attached patch). Basically, I added a get_stages() > method that will allow Congruity to find out what stages will be executed for > a given remote and operation file. Since there are really only 2 variations > (zwave and not) and we only support firmware updates for non-zwave right now, > I don't think this is a big deal to maintain, especially since it shouldn't > really change much, if it all. > > Let me know if you think this is reasonable. I have a Congruity implemented > around this that seems to work well.
num_stages seems unnecessary, we already provide num_stages on the very first callback by passing a stage_id of LC_CB_STAGE_NUM_STAGES. AFAIK, this is implemented in every entry point of libconcord. This patch hard-codes it a second time, and also doesn't take into account things like no-reset which the existing code does. The only piece is that *which* stages there are. What if... hmm. What if we alter the API slightly to say that on LC_CB_STAGE_NUM_STAGES, 'arg' is not an opague object, but instead a pointer to the list of stages? -- Phil Dibowitz p...@ipom.com Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
