<accept> identifies nothing more than the media-types that can be in the HTTP post and put request. No specific server behavior is implied.
Robert Yates wrote: > > Elias Torres wrote: > >> >> Thanks Bill for both the pace and thinking over about instrospections >> and feeds. I believe turning introspection documents into feeds besides >> the suggested advantages, it will also solve the collection management >> (well mostly) problem. If collections are represented as entries, then >> we can re-use APP to manage collections. That would be a beautiful >> thing. > For what it's worth our server does this, although it also has an > introspection document. James wrote up how it does it here > http://www.imc.org/atom-protocol/mail-archive/msg05219.html. That > posting didn't recieve any responses and we are very interested in > hearing if folks think it a viable approach. > >> All we really need is app:accept in collection entries and maybe, >> I say maybe, app:workspace. >> >> > Maybe......, I know that this has also come up before, but the meaning > of app:accept still confuses me a bit. Does it mean that the server > stores posts of the listed types, or "understands" posts of a particular > type. For example we have a server that will store any file type so the > accept element will contain */*. We are also exploring using APP for > Calendaring and that server will accept mime types of "text/calendar". > While the first server will store "text/calendar" and returns it > unaltered, the second server "understands" "text/calendar" maybe fanning > out repeating calendar entries, etc. So how should "store" be > differentiated from "understand"? > > Rob > >
