OK all, [ Stephen, as the primary user of the libconcord API, I'm particularly looking for input here from you ]
I now have fully functioning 89x support for config updates, connectivity
tests, and web communication. (No work yet on firmware or learn-ir).
The current libconcord API was designed very much around the HID remotes,
and so a config update in 0.22 looks like:
prep_config()
invalidate_flash()
erase_config()
write_config_to_remote()
verify_remote_config()
finish_config()
reset_remote()
[... reconnect]
set_time()
The ZWave remotes don't expose the low levels that the HID remotes do.
There's no flash addresses to worry about, or even manual invalidation and
erasing. It looks like this:
write_config_to_remote()
set_time()
If we're on a zwave remote, write_config_to_remote() calls UpdateConfig()
(instead of WriteFlash()) which only exists on the zwave branch of the class
hierarchy.
Later in this email I'll address the possibility of splitting up
UpdateConfig(), but suffice to say that at best you'd split it into
prep/update/finish, and nothing like what we have for HID.
So the question is - what should the API for libconcord look like? I see a
few possibilities:
OPTION 1
We wrap up what prep_config(), invalidate_flash(), erase_config(),
verify_remote_config(), verify_remote_config(), finish_config(), do into
just three calls:
// send prep 'commands' and invalidate flash?
prep_config()
// erase flash and write new data
update_config() // a rename of write_config_to_remote()
// verify and commands to re-enable flash
finish_config()
// Possibly finish_config() would reset the remote
// or possibly we'd have a reset_remote() that isn't
// required for nonzwave remotes (this data is exported)
This would then align with the zwave remotes.
OPTION 1-B
The same as option 1, but leave those low-level calls still available.
OPTION 2
Just leave the separate call path for updating HID remotes vs. zwave remotes
as they are (outlined above).
OPTION 3
Something new I haven't thought of yet.
Here are some things to think about:
* the 89x remotes are a weird hybrid of the HID and zwave remotes. It is
unclear what API changes may or may not be needed for the 1000/xbox/etc.
remotes.
* Have a simple API is nice, but giving some control to the end-user is
also useful, and I feel like we'd be ripping all that out with option 1
* A few calls are common among config and firmware updates:
invalidate_flash, and reset_remote.
- invalidate_flash is a single command sent to tell the remote not to
use it's flash. This looks, in hindsight, much like the other stuff in
prep_config() and prep_firmware(), and I'm very sure that's actually where
it belongs, regardless of whether we collapse the other calls or not.
- reset_remote *could* be part of post, but I argue it should be it's
own call even if we do do that. So potentially we do #1, but with a
reset_remote you only have to call for some remotes (it works on all though).
* The current HID API provides a flexible way of giving lots of useful
feedback to the user, and simplifying it will remove this. Obviously we
could rework the callback structure to allow the library to provide more
status information to make up for that, if we wanted, but still...
Now, a few words about what the underlying CRemoteZ_HID::UpdateConfig()
function is doing under the hood.
In reality it does a lot of work under the hood:
* Send the UDP-HID command to start a TCP-HID connection
* Do the SYN-ACK handshake for TCP-HID
* Tell the remote want to start the config update (this actually happens
in the SYN-ACK of the SYN, SYN-ACK, ACK handshake).
* Send the header for the update
* Send the data for the update
* Ask for a checksum of the data
* Tell it we're done with the update
* Do an involved ack,ack,fin-ack,ack teardown
I've _thought_ of splitting the first few steps into prep_config(), but
there's no decent place to draw the line. The START_UPDATE command is part
of the TCPHID handshake... breaking it after that is doable, but seems like
we're doing it just to have a prep. I also see no real benefit.
Now, because the status-update callback procedure for the update does it
based on bytes sent, only the "send the data" part is updating the status.
Which would be fine - we have before/after steps in HID that aren't part of
the transfer as well - except that asking the remote to calculate the
checksum takes like 15 seconds, and so that appears as a hang to the user.
Separating that out as finish_config() is possible, but again, it's awkward
because it's all part of the expected order once you've sent START_UPDATE.
I've had times where option 1 seemed clearly the right choice to me, and
other times where it seems totally wrong, and I go back forth a bit. I think
option 2 is probably not right, but I wonder if there's something more
--
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
------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
