This post introduces the Streaming Profiler SDK, provides a description of what it does, how it works and how it can be a useful tool for managing your Application Streaming profiles.  The Profiler SDK has been around since the 1.1 release of the Streaming Client (PS 4.5 HRP 1) and the 1.2 update that accompanies XenApp 5.0 was recently announced.

Here's a link to the download site and the official documentation.

For a moment, put your programmer hat on and consider that the Streaming Profiler (the guts of it) have more than one client.  The "back end" supports the Streaming Profiler GUI (pkgr.exe), the Streaming Client itself (radesvc.exe) and the Citrix publishing system, aka the Access Management Console. 

Architecturally, the Streaming Profiler "back end" is the ONLY thing that is allowed to touch the .profile content.  Sure, others can and we haven't exactly HIDDEN the content, but in theory, the ONLY thing that knows the internals of how a .profile and .CAB are formatted is the profiler back end.  Notice that the backward / foreward compatibility stuff is at the API layer - not the disk content. 

Here's a picture...

This was the original layout of Application Streaming.  The separation of function said the GUI talented people do GUIs, the publishing people do publishing and the guts of how the streaming client works people do the back end and the service.   I was in this last group, had development responsibility for the back end and the above is rough description of how it all plugs together.  We decided on C++ as the interface between the pieces; shared header files loosly modeled on COM so it could be consumed.  It seemed to be a good balance at the time and we pushed on and built it.   There were some issues.  Being based on shared headers, the API is "per-build" dependent.  CPP doesn't meld well for portability.  C wasn't the right answer; too much state.  We let the header dependence go since - afterall - we are all building in the same build tree and it was a foregone given that all of the pieces would be updated every time we update the Streaming Client/Profiler.

Along came the real world

Customers, partners, ISVs also want to manage profiles and they want to do it from PROGRAM CODE.  The API is broke and the wisdom of the original developer who laid out the internal API rightly had rocks thrown at it.  I should have stuck with vanilla 'C' and all would be good - but that too had its own pitfalls.

The solution was a conversion of the private API from "something like COM" to "really COM" and this is the profiler SDK.  Picture below.

A vision to the future

Standard disclaimers and no promises, but the logical next step is to convert the internal components to use the external SDK.  The benefits are that we can be SURE that the SDK is a complete reflection of the internal API and that ... it works.  It will take some to get there - lots of time - but this is where I want it to go.

Joe Nord
Product Architect Application Streaming
Citrix Systems, Fort Lauderdale, FL