Hi Rodney,

As of last night's commit (svn revision 2612), the Facebook publishing
plug-in is built and packaged as a separate, dynamically-loadable .so.
The Facebook plug-in is our reference implementation for both the
plug-in packaging scheme and the new API that publishing plug-ins use
to connect to Shotwell. You can see the source and make files for the
Facebook plug-in by browsing the files in
${SHOTWELL_ROOT}/plugins/shotwell-publishing/. When browsing these and
other plug-in related files in the Shotwell source tree, there are a
few things to keep in mind.

One is that writing a publishing plug-in is actually a three-step
process. First, you have to write the plug-in infrastructure.
Regardless of whether you're writing a plug-in for web publishing or
for slideshow transitions, the Shotwell Pluggable Interface Technology
(SPIT) controls the mechanics of entry points, API version
negotiation, and interface discovery. The SPIT architecture is
documented on our wiki at
http://trac.yorba.org/wiki/ShotwellArchWritingPlugins.

Next, you have to write the core functionality of the plug-in itself.
This is where the plug-in actually does what it does. In the case of
publishing plug-ins, this where you actually write code to send
network messages, parse XML responses, etc. There is a new
publishing-specific API for publishing plugins, written on top of
SPIT, that we are finalizing the details of right now. Some
preliminary documentation for this API is available at
http://trac.yorba.org/wiki/ShotwellPrelimPublishingAPIDoc. The code
that actually defines the new publishing API lives in
${SHOTWELL_ROOT}/src/plugins/PublishingInterfaces.vala. The reference
Facebook plug-in in trunk is written against this API.

Last, you have to decide on a mechanism to build and package your
publishing .so. In the case of the reference Facebook plug-in, it's
built via a recursive make invoked from the main Shotwell Makefile.
Essentially, the Facebook plug-in is built as part of Shotwell itself.
This makes sense for a reference plug-in that -- even if packaged as a
separate .so -- constitutes a core part of Shotwell. Of course, this
makes less sense for a third-party publishing plug-in like Ubuntu One.
That said, a good way to get started working is to check out Shotwell
trunk and then, in your own sandbox, edit the Shotwell makefiles so
that your plug-in is built alongside Shotwell itself. You can then
decide on a build system and packaging mechanism later.

Another thing to keep in mind is that the new, plug-in based Shotwell
publishing API exists alongside the old legacy publishing API in which
publishing connectors were actually baked into the Shotwell
executable. For this reason, we have quite a lot of code dedicated to
bridging the old and the new APIs. All of this code lives in
${SHOTWELL_ROOT}/src/publishing/APIGlue.vala. At least until we rip
out all of the old publishing code, getting your publishing plug-in to
tie into Shotwell probably involves modifying three or four lines of
driver code this file.

Lastly, keep in mind that the new publishing API is still in flux, and
while it's pleasantly chilled, it hasn't exactly been frozen yet. As I
said, some preliminary documentation is available at
http://trac.yorba.org/wiki/ShotwellPrelimPublishingAPIDoc. As of right
now, it describes the two core interfaces in the new publishing API:
the Publisher interface, which your plug-in must implement to be
discovered as a publishing service, and the PublishingInteractor
interface, which your plug-in uses to communicate with Shotwell to
query the list of items to publish, ask Shotwell to set up the
publishing interface, etc.

If you need any more information, or if you think it'd be helpful to
talk by phone, just reply to this message and we'll set something up.
We're here for you guys.

Regards,
Lucas
_______________________________________________
Shotwell mailing list
[email protected]
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Reply via email to