The Phone Sherpa platform enables partners to build custom mobile content solutions quickly and with low operational overhead. Central to the platform is the content itself; files provided by the end user or partner for editing, conversion, and delivery to a device. Most of the API methods and Flash perform operations on content files in some manner. This section introduces the internal source file concept used within the Phone Sherpa platform.

All file actions take place on Phone Sherpa servers at the request of the host application. Conversion, editing, delivery, and end user file publishing are server side operations. Minimizing file transfer between the end user, host application, and Phone Sherpa is paramount in providing good response time and minimizing bandwidth usage. Keeping this goal in mind, the platform is designed with minimal need to transfer source and output content files over the wire.

A content file must be first transferred into the Phone Sherpa system before performing any operations via the web service API. This can be done a variety of ways. Files originating on an end user’s desktop or browser are often sent as HTTP file POSTS to Phone Sherpa. Partners with existing source files on their servers may chose to have Phone Sherpa do an HTTP GET to sideload the files from their servers directly. The Flash editor component has facilities to both post user files and sideload partner files into the Phone Sherpa system automatically. Developers building their own transfer mechanism can use one of the following web service API’s:

1. LoadFileFromURL(…) – asks Phone Sherpa to sideload a file via HTTP GET from a public URL. Content is cached so that requests to sideload the same file use the internal copy (flush after 24 hours of non use).
2. GetPostFileInfo(…) – returns a URL in which to HTTP form POST a file to and gives the internal source file name to pass to that page.

The result of transferring a file to Phone Sherpa is an internal source file handle which is a unique file name representing the content within the Phone Sherpa system. Functions that take the SourceFile parameter are expecting a file handle that has been transferred into the system. Some functions, such as EditAudioContent(…), return file handles in their result objects. The output of functions that emit file handles can then become the SourceFile parameters of other functions. Many functions can be chained in this manner, keeping all the input and output files within the context of the Phone Sherpa servers.

Once a file is inside the Phone Sherpa system, actions such as editing, conversion to phone supported formats, and content delivery can operate on the internal source file. As stated above, functions taking the SourceFile parameter are expecting an internal file handle. All operations take place server side and do not put the source or output files over the wire.

After the requested operations are performed, the developer will likely want the converted files to be sent to the user or transferred back into the host application’s environment. There are 4 ways to get files out of the Phone Sherpa system:

1. Flash billing client delivers content to the end user automatically. It gathers the user phone information and sends the content to the phone.
2. SendContentToPhone(…) method to programmatically send a SourceFile to a particular user’s phone.
3. PublishContent(…) method to programmatically publish the content for download by a user. Does not send content to the phone, but makes it available at a public URL for either the end user or host application to retrieve. Puts the content into “phone download ready” state. See API reference for more details on this function.
4. ResolveContentHandle(…) method to programmatically take any internal source file handle and publishes it to a public pickup directory. The host application can then sideload it via an HTTP GET back into their host application. This provides a great deal of flexibility since the host app can retrieve a file from Phone Sherpa at any point in the process.

Note that the above 3 functions incur a usage charge when called. These are the only charge inducing methods within the Phone Sherpa API.