Skip to content
This repository was archived by the owner on Aug 5, 2022. It is now read-only.

Home

Jump to bottom
Patrick McCarty edited this page Jan 21, 2014 · 12 revisions

Welcome to the buxton wiki!

Other pages on this wiki include:

So this is turning into my scratch page for ideas. Things I'm thinking about:

  • Rework internal structure. Having two convenience libraries, libserver and libshared (names can be changed of course =P) with libshared being a short of catchall and libserver being daemon and buxtonctl --direct specific. The files in libshared should be buxtonlist, buxtonarray, buxtonhashmap, configurator, protocol, serialize and util. The files in libserver should be backend, direct (to be created but all the buxton_direct_* functions should move there) and security. I don't really care about the directory structure of the repo for this. libshared should be linked with (staticish magic via libtool) libserver and libbuxton. libserver should be linked with bt-daemon and buxtonctl. This means buxtonctl gets two copies of libshared and we must always keep that in mind for which copy gets used when executing a call chain (ala configurator dealing with configuration options from the command line, buxtonctl needed to be able to set both the libbuxton and libserver static configurator in case it is being used as client or direct).

    • After thinking about this more, I'm not sure it's worth reorganizing the convenience libraries. The original motivation for splitting libbuxton-security out of libbuxton-shared was to avoid using the duplicate Smack rule hashmap from libbuxton back when bt-daemon linked with libbuxton. Now that bt-daemon no longer links with libbuxton, and more code moved into shared/backend.c, libbuxton-security is not needed. I think we should instead consolidate and use one convenience library, which should work okay for now. (comment from @phmccarty)

  • Client API changes. Make opaque BuxtonResponse typedef over a BuxtonArray. Extend API so that the client isn't concerned about response structure and so changing the order of data in BuxtonArray doesn't break clients. This would be done through helper functions to ala get_response_status, get_response_key, get_response_value, get_response_list, get_response_old_value.

  • Notifications fully implemented. Best idea so far is to add the type of the request (BuxtonControlMessage) as an item in the notify_value struct. It gets put in the struct by send_message, then in buxton_wire_handle_response, once the struct is obtained from the hashmap the control message type is checked. This allows us to be able to hook in extra per type handling later but for now only checks for notify and unnotify. The check then looks at status, if the response is OK then we insert the handler to the notify hashmap exactly as it came from the general hashmap. If the response is negative we call the handler if it was any other type of request. This means the client needs their handler to support a negative response type but it also means less work overall without the client needing to register in the notifications hashmap themselves through one callback and having another seperate callback for handling notification messages.

    • This should be working now, ended up needing to have the daemon send the notification message id back to the client on unregister_notification as well as adding support for unsigned integer types as BuxtonData (comment from @bryteise)
Clone this wiki locally