TAG is good :) 





On Tue, Jun 18, 2013 at 6:02 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
Yes, the work from the security branch.

Matthias Wessendorf wrote:
>
>
>
> On Tue, Jun 18, 2013 at 5:13 PM, Bruno Oliveira <bruno@abstractj.org
> <mailto:bruno@abstractj.org>> wrote:
>
>     What do you think about tag the current version and merge the security
>     branch? Only if you want to we also can release the version 0.1.0 on
>     maven central.
>
>
> are u talking about the REST API doc (this thread)
> or the (real :-)) work I did for security branch ?
>
>
>     Just let me know.
>
>     Karel Piwko wrote:
>      > On Tue, 18 Jun 2013 16:26:26 +0200
>      > Sebastien Blanc<scm.blanc@gmail.com <mailto:scm.blanc@gmail.com>>
>       wrote:
>      >
>      >> +9006
>      >> And we should check that the integrations tests are always in
>     sync with the
>      >> cookbook (use the same use cases / data) .
>      >
>      > Asciidoc provides a nice feature of including snippets of code
>     from real
>      > files into documentation. Not sure if that would be possible with
>     making groovy
>      > syntax for integration tests nicely fitting cookbook syntax, but
>     might be worth
>      > investigating ;-)
>      >
>      >
>      >> Seb
>      >>
>      >>
>      >>
>      >> On Tue, Jun 18, 2013 at 1:54 PM, Matthias
>     Wessendorf<matzew@apache.org <mailto:matzew@apache.org>>wrote:
>      >>
>      >>>
>      >>>
>      >>> On Tue, Jun 18, 2013 at 1:46 PM, Karel Piwko<kpiwko@redhat.com
>     <mailto:kpiwko@redhat.com>>  wrote:
>      >>>
>      >>>> On Wed, 12 Jun 2013 10:22:10 +0200
>      >>>> Matthias Wessendorf<matzew@apache.org
>     <mailto:matzew@apache.org>>  wrote:
>      >>>>
>      >>>>> Hi,
>      >>>>>
>      >>>>> a little doc about the REST endpoints:
>      >>>>> https://gist.github.com/matzew/73ec38d853863e7bb1dd
>      >>>> Extremely helpful, thanks! I wish I'd found it before I was
>     wondering why
>      >>>> unified push server started returning 201 instead of 200.
>      >>>>
>      >>>>> I _think_ it would be nice IF the above "REST APIs" are also
>     describing
>      >>>> the
>      >>>>> "params" and HTTP headers that are required.
>      >>>>>
>      >>>>> These are currently (at least for sending) described in here:
>      >>>>> http://staging.aerogear.org/docs/specs/aerogear-push-messages/
>      >>>>>
>      >>>>> What do you think?
>      >>>>> Should we merge the "message format" spec with the "Sender
>     REST-API"
>      >>>>> endpoint documentation?
>      >>>> Wouldn't they make a nice cookbook together if merged?
>      >>>>
>      >>> +1000
>      >>>
>      >>> I am currently on some security work, but I plan to merge the
>     "message
>      >>> format + REST API"
>      >>>
>      >>> I think in three different "chapters"
>      >>> * REST Management APIs (for creating PushApplication / Variant)
>     (+ crud
>      >>> workflow ->  basically all used by the (future) Admin UI)
>      >>> * REST Auth Endpoint (Login/Logout and "enroll")
>      >>> * REST Sender (for sending push messages)
>      >>> * REST "Device Registration" (for the MobileVariantInstances (aka
>      >>> Installations))
>      >>>
>      >>> That ensure the doc is not too long.....
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>>> Also, if we do the merge.... I'd update the above gist to
>     include other
>      >>>>> values/headers/params for the
>      >>>>> MobileVariant/PushApplication/Installation(aka
>     MobileVariantInstance) as
>      >>>>> well
>      >>>>>
>      >>>>>   -Matthias
>      >>>>>
>      >>>> _______________________________________________
>      >>>> aerogear-dev mailing list
>      >>>> aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>      >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>      >>>>
>      >>>
>      >>>
>      >>> --
>      >>> Matthias Wessendorf
>      >>>
>      >>> blog: http://matthiaswessendorf.wordpress.com/
>      >>> sessions: http://www.slideshare.net/mwessendorf
>      >>> twitter: http://twitter.com/mwessendorf
>      >>>
>      >>> _______________________________________________
>      >>> aerogear-dev mailing list
>      >>> aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>      >>>
>      >
>      > _______________________________________________
>      > aerogear-dev mailing list
>      > aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>     --
>     abstractj
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
abstractj

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf