而且情况应当只会随着时间而改善。如果当前实现像我期待的那样流行，那么厂商，包括发行打包商，都会有兴趣维护和更新Portland，尤其会使用特定于操作系统的方式来适应它们。同时，Portland团队保证不会修改编程接口。Intel的Tom Whipple准备的测试套件应当有助于保证这种稳定性。
围绕Portland有几个公开的问题。打包标准这个问题仍然需要协商。Portland的设计者们很明智地对他们的架构设计进行最大程度地解耦；目前来说，打包问题已经被隔离，甚至还不知道最终的解决方案会是否是Portland、Linux Standard Base（LSB）或其他工作的一部分。目前，Portland仍只局限在编程访问典型窗口管理器的图标和其他组件。一旦发布了KDE 4，编程接口可能会扩展到包含图标命名和共享的MIME数据库规范。
请记住，如果愿意，可以用称为DAPI的C绑定进行窗口管理器级别的进程间访问。尽管XdgUtils更加成熟，还可以从项目的CVS库中获得DAPI的早期发行版：
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/portland \
co portland/dapi
有效的DAPI编码可以是模块化的，也可以是面向事件的。面向事件的情况下，应用程序连接到DAPI，然后用select() 方法侦听活动。模块化调用的示例是清单2中打开资源的函数（对发行版文档中的函数稍微做了修改）。
清单2. 打开URL的DAPI C代码示例
/* Initialize with dapi_connectAndInit(). */
static DapiConnection* my_dapi_connection;
int openURL(const char *url)
{
/* DAPI wants to know about toplevel_widget so
it can properly handle focus, layering, ... */
if (dapi_OpenUrl_window(my_dapi_connection, url,
XWINDOW_HANDLE(toplevel_widget)))
return 1;
/* Handle failure here ... */
}
结束语
如果应用程序，特别是应用程序的安装程序，直接处理桌面环境，那么Portland能提供一种实现相同功能的更好途径。
只要对源代码做最少的修改，以及最少的许可影响或最少的编程困难，并且不会牺牲任何功能，就能够使用Portland，获得多于自己所能数倍的移植性。而且从此还能利用未来Portland具备的任何增强和扩展。