#46 ✓resolved
Martin S.

libiphone 1.0 API cleanup

Reported by Martin S. | May 23rd, 2009 @ 12:00 PM | in 1.0 Release

As the usbmuxd integration is moving forward greatly I'd like to add this bug to remind of doing a final API cleanup of libiphone for the 1.0 release after we ripped things apart.


I'd propose to follow what we discussed in the architecture talks (See Figure 3) and cleanup the namespaces per device service as the iphone_* prefix is not really required (just look at the libiphone.h and notice the "grouping" of functions).

We should introduce headers purely for one service and keep this scheme for new yet unimplemented services.

This means "iphone_afc_*" becomes pure "afc_*" and one needs to use "libiphone/afc.h". "iphone_lckd_*" for instance becomes "lockdownd_*" and one uses "libiphone/lockdownd.h".


Lockdownd has a defined request interface (like a webservice) which we should expose in the API, although that can happen past 1.0 as simple API additions. However it might be feasable to already adjust the GetValue requests to fit more into such an interface (generic_get_value stuff).

lockdownd API (request method to call for value of Request node) is:



After talking with Nikias, as he was adding new symlink functionality for OS 3.0, it became evident that some refactoring should take place here.

Primarily things like get_file_attr() do not reflect the AFC protocol and are rather further abstraction/helper functionality on top of it. The AFC API should reflect the protocol (like get_file_info() should actually be exposed and it is enough to return a uint64_t as file handle, ...). This also gives more benefits like better portability (no struct stat) and focusing on the real protocol. Everything else is a matter of the implementation using AFC like the file attribute "conversion" which should take place on the consumer side of the API. Patches for this in the works.


As talked about with Nikias, the public API should only expose a callback way to grab notifications which makes the whole thing more elegant. Internally, a pull thread is still required and might be changed to an event based data retrieval in the future (as with libusb 1.0+).


We should remove the get_all_contacts test method until a correct interface is worked out from the ongoing synchronization research (like python-iphonesync). The remaining connect/send/recv looks ready.


Thus libiphone becomes a package of higher level service client API implementations to use programatically or through a set of exposed tools (iphone_id, iphoneinfo, iphonesyslog, ...).

That should be the last change, allow us to keep a stable API and finally a 1.0 could be released.

Feedback welcome as the more people "think" through this, the better the API becomes.

Comments and changes to this ticket

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

A project around supporting the iPhone in Linux.

See http://libimobiledevice.org

Referenced by