outdated

docs/TODO.txt

@@ -1,91 +0,0 @@
-/* new todo file for BTstack */
-
-2009-11-08: Release 0.1
-2010-06-20: Release 0.2 - SDP + iOS 4 support
-2010-11-2x: Release 0.2 - revsion 973 for WeBe++
-- Fix for regression bug in 0.2-899 that prevented automatic disabling of Apple Bluetooth stack, less crashes
-- Startup: send kill signal to BlueTool and BTServer, if necessary
-- Connection setup: don't close baseband during authentication
-- Remote Device DB: automatic link key handling in BTdaemon, provide cached remote names during inquiry
-- SDP: use 1000 bytes MTU, fix partial responses, fix an incompatibility with Windows native statck
-- Cocoa run_loop: added timeouts, include in libBTstack.dylib build
-2010-xxxx: Release 0.2 - revions xxx
-- limit size of /tmp/hci_dump.pklg to 1000 packets (max 1 MB)
-- set SpringBoard icon after respring if active
-- power handling: handle power changes in all states, receive and handle power notifications, keep track of individual clients
-- automate scan enable management: hci_set_discoverable(bool) sets inquiry scan, page scan is always active
-- fixed bugs in cocoa run loop implementation
-- removed link key and name caching from BTstackManager, honor BTSTACK_EVENT_REMOTE_NAME_CACHED
-- Retina icons!
-
-2011-03-xx: Release 0.3 - RFCOMM for Celeste and others
-- use posix run loop for daemon again - fixes issues with lost bytes on Bluetooth UART
-- fixes for cocoa run loop implemenation
-- move RFCOMM code into BTdaemon
-- Darwin notification on BTdaemon start/stop
-
-AFTER:  
-- bug: if hci disconnect fails, l2cap channels are never discarded (only fails on old Ericsson module)
-- verify: TestBTstackManager can do an inquiry, with 0 or more devices in the list
-- get rid of BTInquireViewController
-  - update WiiMoteExample to use BTstackManager
-  - Update/rewrite BTstack Keyboard
-  - delete BTInquireViewController
-
-- clean up components
-  - consolidate iOS code in port_ios.m (bt_control_iphone.m, platform_iphone.m)
-  - consolidate cocoa/corefoundation code in port_corefoundation.c (remote_device_db)
-  - rename bt_control.h -> power_management.h
-  - add control of status bar icon to bt_control.h, too.
-  - decide on configure flags
-  - dynamic link BTdaemon against libBTstack.dylist
-
-- HCI CMD packet is limited to 1024 bytes payload. SDP records could be larger than that. Options:
-  - provide a way to transfer SDP records in segments
-  - ignore HCI command lenght on socket connection and directly stream data without buffer
-- L2CAP 
-  - segmentation
-- extend SpringBoard feedback
-  - show alerts/messages using SpringBoardAcccess, e.g. Bluetooth disconnected by remote device
-  - add code to notify about remote disconnets
-- configuration: /etc/btstack
-  - single Bluetooth module supported
-  - transport type: H4, H5, USB
-  - h4/h5: UART path
-  - usb: product/vendor ID
-  - logging mode: text, bluez, packetlogger
-- create <btstack/errors.h>
-
-== USB Support ==
-- Store array of data sources to be able to remove them on usb_close
-- create little "reserve Bluetooth module on Mac OS X" tool
-
-== Objective-C Interface ==
-- have a look at External Accessory interface by Apple - it's quite similar
-- decide what to do with the CocoaTouch code. Options:
-  - do nothing (potential problem with multiple dylibs in same process)
-  - add it to libBTstack.dylib
-  - provide a libBTstackCocoaTouch.dylib (less memory usage)
-- move connection methods to BTdevice (get more object oriented)
-  - initWithAddress:(bd_addr_t)addr
-  - setters private
-- implement l2cap code
-- implement rfcomm code
-- animate discovery dialog:
-  * use indexPathsForVisibleRows and cellForRowAtIndexPath: when you want to refresh just the cells that are on the screen
-  * use insertRowsAtIndexPaths:withRowAnimation: to add rows
-  * use deleteRowsAtIndexPaths:withRowAnimation: to remove them-
-
-== Refactor/Improve Architecture ==
-- add linked_list_iterator that can remove elements (used by l2cap_close_connection and sdp_unregister_services_for_connection)
-- clean up control flow
-  - l2cap directly sends data over socket: good/bad?
-  - split daemon into stack parts
-  - should there be STACK API/interface?
-- unify packet generation
-  - btstack events
-  - cmd packets
-  - l2cap commands
-- auto-generate code for sending commands from structured text input file
-- devise concept for access to event data
-  - auto-generate event struct getter? STRUCTURE_get_FIELD