On 08/31/2010 02:26 PM, Phil Dibowitz wrote: > On 08/31/2010 06:08 AM, Stephen Warren wrote: >> So, perhaps: >> >> // Returns TLOConnectivity, TLOUpdateConfiguration, TLOUpdateFirmware >> TopLevelOperation *gen_op_from_website_file(remote, filename); >> // Always returns TLOBackupFirwmare >> TopLevelOperation *gen_backup_firmware_op(remote, filename)\ >> // ... >> TopLevelOperation *gen_restore_firmware_op(remote, filename) >> TopLevelOperation *gen_backup_configuration_op(remote, filename) >> TopLevelOperation *gen_restore_configuration_op(remote, filename) >> // or one function per operation type: >> Status tlo_execute(tlo, callback, ...) > > I guess I just don't see the advantage here over just making our existing > API more top-level-oriented, ala: > > update_configuration(pof) > backup_configuration(filename) > update_firmware(pof) > backup_firmware(filename) > set_time() > get_time() > reset()
The primary advantage is having a unified way for an application to query which steps are involved in an operation ahead of time. Without a single TopLevelOperation object that can be queried for all the steps, in order to support libconcord defining operation steps instead of hard-coding them in an application, there would need to be some API per operation type for querying this information. Instead of: tlo_get_step_count(tlo) tlo_get_step_type(tlo, step_id) tlo_get_... You'd have something like: update_config_get_step_count(?) update_config_get_step_type(?, step_id) update_config_get_... backup_firmware_get_step_count(?) backup_firmware_get_step_type(?, step_id) backup_firmware_get_... ... .. an explosion of functions. The unified TopLevelObject also gives a good place to store operation-specific state; e.g. a TLO created for an 880 config update might include the set-time step, but one of a 700 config wouldn't, and having some specific object other than global variables in libconcord.cpp would be a good idea. > I totally buy your argument that update_configuration should reset and set > time. > >> In practice, users can press CTRL-C while running any application, or >> click the cancel button in congruity (which will abort between >> libconcord API calls right now), or just unplug their remote. In this >> case, the worst that should happen is the remote booting into safe mode >> and needing another firmware or configuration update attempt. > > Sure, but then you KNOW your breaking out of a program in the middle, as > opposed to a nice "cancel" button that implies a nicer cancel. No? I'm not sure if the distinction is that obvious to end-users? congruity has had a cancel option since the beginning IIRC (personally I find apps that can't cancel very annoying), and I don't recall any reports of users screwing themselves with it; ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
