I've not had much use for pics.livejournal.com so far because it doesn't work with the way I deal with photos in my journal. More often than not, when I post an image on LiveJournal somewhere, its URL (currently on my own site) reflects the journal it was posted in (usually “mart”) and the itemid of the entry. This means I can tell later which images belong to which entries and so on. I'm not really all that fussed about the URLs, but I think it'd be cool if pics.livejournal.com could magically associate a gallery with an entry. Ideally, this would allow me to “attach” an image from my LiveJournal client and have either the client or the server (or perhaps a combination of the two) automatically create an initially invisible gallery to put the images for that entry in and fix up the image URLs to point at the right places.
There are a couple of approaches to this, each doing different parts of the process in different places. This can be almost entirely done client-side, but some co-operation from the LiveJournal server code makes it easier. At the moment my thinking is that the stored entry should have metadata specifying which gallery ID is assocated with it. This can be submitted just like any other logprop. The submission process from the client is as follows:
- Client creates gallery and notes the galleryid returned
- Client then uploads all of the attached pictures to that gallery and notes the returned picids
- Client submits entry to LiveJournal with the gallery ID in a logprop and the picids specified using a special URL style in the IMG elements (eg
At render time, the HTML cleaner (which will hopefully have been passed the gallery id and any other necessary information) can expand that URL. An alternative is to use a new element, perhaps
lj-img, which has a
picid attribute in place of
src (but all other attributes are copied verbatim), the advantage being that the chosen width and height can then be used as scale parameters in the URL to automatically select the appropriate scaled image.
However, there are a couple of issues with this client-heavy approach:
- It violates the traditional “server clever, client dumb” principle and forces the client to know about FotoBilder as well as LiveJournal. The only way around this is to allow clients to somehow upload to LiveJournal and then have LiveJournal copy the submitted image to FotoBilder.
- The server must be able to tell the client where to find the FotoBilder upload interface along with the FotoBilder protocol version. This can be addressed as part of login, though.
- In non-WYSIWYG clients, the user must either know the picid ahead of time to write the image element or the client must rewrite it at post time from some other form — possibly an image index. Clients shouldn't be parsing HTML as a normal operating procedure. The alternative here is to just submit per-entry image indexes along with a list of index-to-picid mappings which LiveJournal must then store and use to create the URLs at display time.
As for client UI, WYSIWYG clients can theoretically just do all this behind the scenes when the user embeds an image — although the uploading should not be done until the entry is submitted. Non-WYSIWYG clients can present an “attached images” list with some kind of identifier for each image so that the user can see how to identify each image in the image element. As a convenience, clicking the items in this list could insert a simple image element at the current cursor position for the user to edit.
I'd be interested to hear any other thoughts people have about how to implement this. If FotoBilder's going to integrate with LiveJournal, let's do it properly! ;)