Mediasock / PictureSync (Lightroom, Aperture, etc.)

[theturninggate]

Seems there's an easy way to get PixelPost working together with Adobe Lightroom, Aperture, iPhoto, iView MediaPro and a number of other popular photo management applications. We just need someone who knows how to implement it in either an official PixelPost release or in an addon.

That solution is MediaSock (http://mediasock.org/) support in PixelPost. Users could then use PictureSync (http://picturesync.net/) to update their photoblogs.

I contacted the maker of PictureSync about it, and he said this:

"Your best bet is to ask the developers to add support for MediaSock
(http://mediasock.org/), you could then add a MediaSock account in
PictureSync and simply point it to your Pixel Post blog.

"If the developers themselves aren't interested, you could post it to
a bounty site and try and get others interested in adding support
(adding support should not be hard though)."

This would be a godsend for me, and I'm sure for others as well. Presently, PixelPost doesn't fit very well into my workflow, and that's one of the primary reasons my photoblog, Project Seoul (http://www.projectseoul.com), isn't more up-to-date. If I could update from within Lightroom using PictureSync ... well, let me put it this way: Presently I like PixelPost pretty well. But if I could do that, I'd be singing PixelPost's praises to the heavens.

I'd be willing to contribute to a ransom for such an addon. Anyone else?

Anyone out there who thinks they might be able to implement this?

Cheers,
theturninggate

[Dennis]

"funny, if the developers are not interested." Well, they might be if the protocol is better defined, more examples are presented and we can code it in an addon.

You mentioned in an earlier thread that you haven't got any response here. I was trying to figure this thing out and I can't get it to work.

I still don't get anything that it does. What I do gather is that it needs to replace the loginpage of some sort and server adjustments have to be made for redirection.

[jacob]

MediaSock is in a manner simply a set of rules for naming and placement of [HTML] 'forms' to enable an automated application (process) to interact with the site (and its pages) as a web service.

There are two elements to the specification.

1. Endpoint discovery, which I doubt applies here as a PixelPost installation presumably has no standard location nor necessarily has access to the root directory of its installation domain. Instead of using discovery a user may input the specific URL for a PixelPost login page in the client application.

2. The methods (or 'forms'). The naming and behaviour of these should follow the specification (field names, and responses), either the existing page output could be modified, or you could write new pages. You should only need to implement login and upload, other MediaSock methods are probably superfluous for use with PixelPost.

For the most basic implementation you do the following.
The login page would accept the defined form fields and values (username and password), printing:

<!--
<mediasock value="com.example" title="Example Service" version="1.4">
<handshake>
<stat value="1" message="" resource=""/>
<apis value="mediasock.media.append:http://example.com/pixelpost/upload.php"/>
<sock value="auth.hsc;type.img;type.image/jpeg"/>
</handshake>
</mediasock>
-->

stat= must be 0 once logged in

The upload page would accept the defined form fields and value, printing:

<!--
<media.append>
<stat value="0"/>
<item value="" resource=""/>
</media.append>
-->

Ideally you'd return an id in the item value, and url in the resource attributes, but if you don't this simple static response is enough.

That's it. If PixelPost supports (or requires) it, you could add support for 'taxa' (albums, categories, sets...).

Please send any questions to me directly.

[jaywilliams]

If i could download and see the code for a simple real-life demo, that would be perfect.
Nothing beats seeing something in action.

[jacob]

You don't have to think about MediaSock as a [complex] web service API, that's its function, but its implementation can simply be the inclusion of some [XML] tags in existing page output (notwithstanding the need for standardised naming of form fields).

Sorry no public server-side examples, in any case no single implementation is ever likely to be the same, but you really shouldn't need source—as mentioned a minimal implementation would require only 1 single variable in the printed output. If you have not done so check the quick start (http://mediasock.org/?sock/implement) which includes a sample HTTP conversation.

You first decision should be, whether or not to use your existing pages or create new pages thus maintaining a distinct set of pages/codebase for 'API' functionality.

If you let me know what kind of architectural constraints PixelPost has (I'm not familiar with it, so e.g. do uploaded photos need to belong to categories?) I can indicate what additional methods/declarations should be used. You can IM me should you need to talk through it point by point; drop me a PM for my IDs.

[theturninggate]

Out of curiosity, is anyone pursuing this, or is the idea dead as it stands?

[Dennis]

We will have a stab at it, but Jacob hasn't responded yet. In the mean time there is a new site which is about to get released. :D

[theturninggate]

Strange he hasn't responded. He's answered all of my emails within 24 hours.

I'm looking forward to the new site, though.