Is there an update to the SDK docs that explains LrPublishedCollectionInfo? There are several functions that refer to this type as params, but they are all broken links and it is unclear to me if it refers to LrPublishedCollection or not. Example code seems to suggest this is not the case.

Some SDK examples [e.g., the stubs for publishServiceProvider.shouldReverseSequenceForPublishedCollection()] just deepen the confusion.

I'd really like to know what I can do with publishServiceProvider.goToPublishedCollection() and the passed in "info.publishedCollectionInfo" param.

Its not this is it? ( I'm just taking a wild stab - I've never worked with publish services):

pubCollection:getCollectionInfoSummary()

Retrieves an information summary about this published collection.

This function must be called from within an asynchronous task started using LrTasks.

First supported in version 3.0 of the Lightroom SDK.

Return value

table with the following information:

name: Name of the published collection

localIdentifier: Internal ID number of the collection (the local identifier).

remoteId: The ID of the collection on the remote service.

remoteUrl: URL of the collection (if applicable) as published.

isDefaultCollection: (Boolean) True if this is the default collection.

parents: (array of tables) Information about any published collection sets that contain this collection. An array of tables, each containing name, localCollectionId, remoteCollectionId, and publishedUrl.

collectionSettings: (table) Any collection-specific settings that have been stored by the plug-in.

Clearly, I need to come back to this once I get a good feeling for how the Lr env is and isn't standalone Lua I'm used to, and wrap my head around namespaces-which-are-not-modules vs. not-quite-classes. This is the first time I've seriously looked at the SDK, other than reading the API docs and poking at the examples.

Debug tools are welcome, of course, and your hint actually keeps me from posting another question about available debugging techniques.

Clearly, I need to come back to this once I get a good feeling for how the Lr env is and isn't standalone Lua I'm used to, and wrap my head around namespaces-which-are-not-modules vs. not-quite-classes. This is the first time I've seriously looked at the SDK, other than reading the API docs and poking at the examples.

Debug tools are welcome, of course, and your hint actually keeps me from posting another question about available debugging techniques.

For now I'm using simple LrLogger tracing but that will get old fast.

Yeah, there is a bit of a learning curve...

No true debugger for it, ala IDE or anything - no single stepping..., at least not when running in Lightroom environment... John's debugger is next best thing I think.

I tail the log file with an editor, but the logger can also output messages direct to a debugger, if that would help (its all in the docs...)

I wonder if it would be possible to write a true debug module for an IDE, hmmm...

PS - I completed the integration of John's debugger with the framework.

I wonder if it would be possible to write a true debug module for an IDE, hmmm...

I think it would be very impractical, given that Adobe disabled most of the functions of the "debug" module (e.g. debug.sethook, debug.getlocal, etc.).

I briefly considered a debugger implementation that would parse the Lua source and rewrite it with "hook calls" into a debugger API. I got as far as finding a Lua parser (in Lua) before deciding that would take much, much longer than I was willing to invest.

If Adobe were to enable the full "debug" functionality, then a full debugger would be much more practical.