Re: Option #6: Using POST for uploading associated resources

[Janne Jalkanen <Janne.Jalkanen@xxxxxxxxx>]

> Here's the basic use case I've been keeping in mind when evaluating 
> these options.  I'd love to see other use cases worked out in detail 
> as well so that we could see how solutions meet or don't meet their 
> needs.

Here's a draft of a second use case, which is a bit more complicated, 
but it should highlight what I have in mind.  I'm using now "image" for 
"general multimedia object", and "location" as a generic term for any 
other metadata that might be added to the images.

Jill is on a week-long trip to Italy.  On this wonderful, sunny day she 
has snapped several photographs along the day, and as she returns to the 
quaint little hotel during the evening, she rests her feet in a relaxing 
bath, and checks the pictures she took.  Her GPS-enabled cell phone has 
tagged each picture and video with the location where it was taken, as 
well as the time.

She chooses three of the pictures (and one video clip of a juggler, to 
which she adds a comment "nice hat") to share with her friends.  She 
chooses "Blog these" from the menu of the cell phone, types in a quick 
"hello, this is Milano calling", and chooses "Send".  Whirr-click, and 
the images go away (or are sent in the background, more likely).

The server receives the images along with a blog entry, and checking the 
location, uses a GIS to find those places; tagging them as "Milano, 
Italy", and posts them on her weblog.

Four years later, she wants to see the images she took while she was in 
Italy, remembering that she would like to have exactly the same kind of 
hat as the juggler, but she does not quite remember the color.  So she 
opens her blog, and types in "Milano hat" and finds the piece of video 
she was looking for.

Technically, what happens (or what I wish to happen) is as  follows:

1) Cell phone tags each multimedia object with location/time data
2) A batch upload is started:
   a) First, each of the objects is uploaded with the attached metadata 
(=GPS co-ordinates and comments (think "captions"))
   b) Server looks at each object, and adds more metadata to them (= 
textual description of the GPS coordinates)
   c) Server returns URI for the image back to the client
   d) Client notes it, and rewrites the entry accordingly.
   e) Repeat
3) Finally, the entry itself is uploaded
4) The server looks at the objects and the entry, and associates them 
together.  This needs to be a two-way association, otherwise finding the 
image does not help in finding other images that might be related to 
them - the relation may be something else than location.
5) The server constructs the final entry, and puts it on the weblog.
6) User search occurs in some unfathomable way of the future.

For 2a), it would be good to have a simple upload that would 1) not use 
base64, and 2) would post the image data together with the metadata (you 
can't use EXIF - that assumes too much of the data format: a WAV file 
would not support EXIF.  Most data formats have their own way of 
including metadata, so either you have to have a really smart server, or 
just externalise the metadata somehow).

The current Typepad image upload API essentially does all the necessary 
API bits already, but it unfortunately uses base64, adding 30% to Jill's 
already huge GPRS bill, which makes Jill very unhappy :)

/Janne