Re: Which collections to upload and post to

["John Panzer" <"JPanzer"@aol.net>]

Joe Gregorio wrote on 6/1/2005, 11:07 AM:

 >
 > On 6/1/05, David M Johnson <Davidm.Johnson@xxxxxxx> wrote:
 > >
 > > For now, I'm making these assumptions:
 > >
 > >     Workspace ==> blog
 > >        1st collection with contents = 'entries' ==> main blog
 > >        1st collection with contents = 'generic' ==> uploaded files
 > >
 > > I'd like to know what other implementors are doing and what the spec
 > > authors intended here.
 >
 >
 > The idea of using the first collection as the default sounds good to me.
 >
 > My thoughts were that the 'title' attribute of each collection element
 > would be presented to the user for them to choose which collection to
 > use.

Remember the cat picture use case [1]:

About my cat...<br/>
<img src="file:photo0006.jpg" align="right"/>
You never feed me.<br/>
Perhaps I'll sleep on your face.<br/>
That will show you.<br/>

The user sees this, of course, in a fancy WYSIWYG editor into which 
they've dragged their latest cat picture and typed their haiku.  Their 
next step is to hit a Publish button.

In this particular use case, the user neither knows nor cares how the 
various bits of their entry get uploaded to the server and published; 
the system (client + server) should do the Right Thing automagically.

In this case, I believe this means that if the server supports linked 
non-entry resources at all, it needs to provide a standard way for any 
client to be able to know where to do an HTTP POST of the data for 
photo0006.jpg.  Without asking the user where it should store the image.

I'm not saying that we shouldn't be able to present the user with 
various more advanced options, but we have to handle the cat picture use 
case well first.

[1] http://www.imc.org/atom-syntax/mail-archive/msg04330.html

 >
 > The list of values for the @contents attribute can be expanded to give
 > more granularity. For example, if we are managing templates, do we
 > want that to be a 'generic' collection, or do create a more specific
 > 'template' type? Here we'll have to do the usual balancing act between
 > generic/flexible and targeted/inflexible. For example, do we have a
 > separate kind of collection for link blogs? book blogs? music blogs?
 > How about separate types of collections for non-entry collections,
 > such as templates?,  photos?

Something I really want to see as well (ability to handle multiple 
collections of content gracefully).  Human readable titles will be 
needed; ability to _optionally_ specify a set of data types will be very 
helpful (I can easily imagine a collection that wants to include both 
images and video, for example, but not text).  But MIME types seem 
insufficient since they wouldn't address things like collections of 
URLs...  How about looking at current usage and trying to come up with a 
set of use cases?

o Blogrolls (collections of URLs, possibly with metadata)
o Images
o Sounds
o Video (or as above, video + images mixed)
o General 'blob' storage for any kind of content (useful for secondary 
content linked to from entries)

...others?

-- 
John Panzer
Sr. Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer