[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meta-pubs again

To: sh@xxxxxxxxxx
Subject: Re: Meta-pubs again
From: "Sylvain Hellegouarch" <sh@xxxxxxxxxx>
Date: Fri, 27 Jun 2008 08:58:30 +0200 (CEST)
Cc: "Tim Bray" <tim.bray@xxxxxxx>, "Atom Protocol" <atom-protocol@xxxxxxx>
Importance: Normal
In-reply-to: <4864823D.4040204@xxxxxxxxxx>
List-archive: <http://www.imc.org/atom-protocol/mail-archive/>
List-id: <atom-protocol.imc.org>
List-unsubscribe: <mailto:atom-protocol-request@imc.org?body=unsubscribe>
References: <95301D44-2C2F-47ED-AA04-6466CA30BDD9@xxxxxxx> <4864823D.4040204@xxxxxxxxxx>
Reply-to: sh@xxxxxxxxxx
Sender: owner-atom-protocol@xxxxxxxxxxxx
User-agent: SquirrelMail/1.4.8-6.el3

>
> Hi Tim,
>
> Interesting that you ask this question now as I was about to do it
> yesterday and got distracted. Thanks for starting the discussion ;)
>
> One use I was considering is in an application that wants to associate a
> service document dynamically with a resource. For instance a new
> user-account could lead to a service document for that user.
>
> Tim Bray a écrit :
>>
>> Back in January, I posted about the idea of a "meta-publication",
>> something you can do CRUD on publications or collections.  mod_atom
>> needs something like this.   Interestingly, several people wrote back
>> and said yes, but there was disagreement on the mechanics.  Here some of
>> the plausible options that happen when you POST to a meta-pub:
>>
>> - create a new collection in the same workspace
>> - create a new workspace in the same service doc with one or more
>> collections
>> - create a new service doc with one or more workspaces with one or more
>> collections
>
> I'm not quite sure what you describe here. Are those options exclusive
> in your mind? How do you create collections?
>
> The way I had considered it was to have a service document which only
> goal was to support those meta operations, along those lines:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <app:service xmlns:atom="http://www.w3.org/2005/Atom";
> xmlns:app="http://www.w3.org/2007/app"; xml:lang="en"
> xml:base="http://localhost:8080/";>
>    <app:workspace>
>      <atom:title type="text">Meta service creation</atom:title>
>      <app:collection href="meta/service/">
>        <atom:title type="text">Meta service creation</atom:title>
>        <app:accept>application/atom+xml;type=entry</app:accept>
>        <app:accept>application/atomsvc+xml</app:accept>
>      </app:collection>
>    </app:workspace>
>    <app:workspace>
>      <atom:title type="text">Meta workspace creation</atom:title>
>      <app:collection href="meta/workspace/">
>        <atom:title type="text">Meta workspace creation</atom:title>
>        <app:accept>application/atom+xml</app:accept>
>      </app:collection>
>    </app:workspace>
>    <app:workspace>
>      <atom:title type="text">Meta collection creation</atom:title>
>      <app:collection href="meta/collection/">
>        <atom:title type="text">Meta collection creation</atom:title>
>        <app:accept>application/atom+xml</app:accept>
>      </app:collection>
>    </app:workspace>
> </app:service>
>
>
> 1.a. Creating a new service is allowed either by POSTing a new service
> document which can of course would be inspected by the server and
> adapted based on implementation constraints. The client would simply
> then fetch the definitive service document with a subsequent GET. Here
> the POSTed service document is considered as a MLE.
>
> 1.b. Creating a new service could also be achieved by posting an atom
> entry that would describe how the client would like the server to
> initiate the new service (that mechanism is not relaly clear in my mind
> yet).
>
> 2. To create a new workspace one could send an atom entry, the server
> could use the atom:title element as the the title of the workspace. A
> default collection might be created too with the entry category elements
>   as the collection categories. By sending an atom feed several
> workspaces could be generated at once.
>
> 3. Adding a new collection could be done by an atom entry to create a
> single collection or a feed to create several collections at once.
>

Following up on what is described above, I'll take a slightly more
enhanced example using your app:meta attribute as well.


<?xml version="1.0" encoding="UTF-8"?>
<app:service xmlns:atom="http://www.w3.org/2005/Atom";
xmlns:app="http://www.w3.org/2007/app"; xml:lang="en"
xml:base="http://localhost:8080/";>
   <app:workspace>
     <atom:title type="text">Meta service creation</atom:title>
     <app:collection href="meta/service/" app:meta="service">
       <atom:title type="text">Meta service creation</atom:title>
       <app:accept>application/atom+xml;type=entry</app:accept>
       <app:accept>application/atomsvc+xml</app:accept>
     </app:collection>
   </app:workspace>
   <app:workspace>
     <atom:title type="text">Meta workspace creation</atom:title>
     <app:collection href="meta/workspace/" app:meta="workspace">
       <atom:title type="text">Meta workspace creation</atom:title>
       <app:accept>application/atom+xml</app:accept>
     </app:collection>
   </app:workspace>
   <app:workspace>
     <atom:title type="text">Meta collection creation</atom:title>
     <app:collection href="meta/collection/" app:meta="collection">
       <atom:title type="text">Meta collection creation</atom:title>
       <app:accept>application/atom+xml</app:accept>
     </app:collection>
     <app:collection href="meta/collection/restricted" app:meta="collection">
       <atom:title type="text">Meta collection creation</atom:title>
       <app:accept>application/atom+xml</app:accept>
       <app:categories fixed="yes">
          <atom:category scheme="uri://musicgenre/" term="indie" />
       <app:categories>
     </app:collection>
     <app:collection href="meta/collection/extended" app:meta="collection">
       <atom:title type="text">Meta collection creation</atom:title>
       <app:accept>application/atom+xml</app:accept>
       <app:categories fixed="no">
          <atom:category scheme="uri://musicgenre/" term="indie" />
       <app:categories>
     </app:collection>
   </app:workspace>
</app:service>


First I want to highlight that I'm using three different workspaces
because they represent to me three different operations. It's just
convenience not formal.

I'm using the app:meta attribute which Tim suggested so that automated
clients can set discover the supported operations and set their
expectations. That being said, I'm not yet convinced we can't do without.

The usage of the app:categories element is interesting here.

In the collection with @href="meta/collection/restricted", the server
would ensure that any posted atom entry or feed to generate a new
collection would at least have the atom:category listed or reject the
collection creation. Nothing really new here. However on the collection
with @href="meta/collection/extended" I was considering that the newly
created collection would be ensured to have the atom:category listed. I
think that's interesting to allow the client to provide its own
requirements of category elements while giving a way for the server to add
its own metadata.

I'd like to draw a parallel with how XMPP PubSub handles it with a way for
a peer to configure a node for specific behavior. While I don't think we
need such granularity with AtomPub it's certainly interesting to keep it
in mind.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

Follow-Ups:
- Re: Meta-pubs again
  - From: James M Snell

References:
- Meta-pubs again
  - From: Tim Bray
- Re: Meta-pubs again
  - From: Sylvain Hellegouarch

Prev by Date: Re: Google now supports OAuth in addition to AuthSub
Next by Date: Re: Meta-pubs again
Previous by thread: Re: Meta-pubs again
Next by thread: Re: Meta-pubs again
Index(es):
- Date
- Thread