Toru Marumoto wrote:
> I just released an APP client. You can download alpha at
> http://www.witha.jp/eXeries/en/
> I haven't really tested on the English version of Windows, but it
> should work ;-)
> If you find a bug, please let me know.
>
Excellent!
> Questions:
> *What can be posted to a collection?
> eg. (1)If member-type is "entry", can I post an Atom Feed document?
> It would be nice if I could create multiple entries with
> one request.)
Undefined. A client can pretty much post whatever they want. It's up
to the server to decide what it will accept. If an entry collection
accepts a post, an Entry should be created. Whether or not posting a
feed to an entry collection results in multiple entries created is an
undefined behavior (aka it's not supported)
> (2)Please define "media". Is a flash file media? What about a
> java applet?
> Let's change "media" to "binary" or even "file"!
>
Anything that has a media type.
> *Do I really need to supply content-type when posting media files?
> There are so many file extensions out there. It's kind of difficult to
> get
> the right content-type. Why not let the server decide?
>
APP currently doesn't *require* that a media type be specified, but it's
hard to imagine how it could work without it.
> *What happens if I issue GET request to a member uri which belongs
> to a media
> collection? Do I get Binary or an Atom entry document?
>
Binary. The member MAY have an associated atom entry accessible via
some other URI as specified in the edit link in the members entry in the
collection feed.
> *Multiple collections in the same workspace that has the same
> entry-type allowed?
> eg. Let's say, there are one entry collection and two media
> collections. How do
> I know which media collection to upload an image for an entry?
>
Yes. The first collection of each type is considered the "preferred" or
"default" collection of that type in the workspace. Beyond that, you
have to guess.
> *If I PUT to Member URI, status code 201 is returned. Fine. What
> about the body?
> Does the response body always have an Atom entry document or not?
>
Undefined. APP does not dictate what (if any) response entity
must/should accompany post/put responses.
> Feature Request:
> *Client Sync (query entries undated since yyyy/mm/ddThh:nn:ssZ ,
> or HTTP HEAD to a member uri to find out if entry is modified, etc)
The first was in the spec for a while, then removed. Preferably,
someone will come up with a fairly standard way of expressing queries as
an extension to the protocol.
The second is already possible. There's no reason to define that in the
spec.
> *Add a new collection's member-type "category".
This has been discussed and is a possibility. The whole story around
categories is still being worked out.
> *CGI Auth
>
This is also still being worked out.
- James
