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
