I agree with Summers;

his 1) is a nice demo, while 2/3 are more test and RI. this can be just a bunch of services, that just behave different (for exception handling etc)
So the clients can use 2/3 to test their impl for positive and negative cases; and these "services" don't require a UI (like a demo). Just some endpoints
to pump data against




On Mon, Apr 22, 2013 at 6:45 PM, Summers Pittman <supittma@redhat.com> wrote:
On Mon 22 Apr 2013 12:33:27 PM EDT, Sebastien Blanc wrote:
> And keeping in mind we are going to demo a lot of other features like :
> - Mulitpart support
> - Data synchronisation
> - Push support
> So maybe this thread is also a good way of thinking about a new
> showcase applicattion in which all these featurs could fit ...
>  Ideas ?

The way I feel we have three separate needs.

1) A experience demo which shows off lots of functionality.
2) A very stable set of services for clients to run tests against
(ideally with stable data)
3) A reference implementation of the service which says.  This is what
we want it to do.  This will be the impl we look at when the spec is
unclear on something and need a "right" answer.

2 & 3 can probably be the same app.  I feel like the experience demo
should be something else.  The last thing we want is a test suite
creating 1000 objects and muching up everyone's demos.

>
>
>
> On Mon, Apr 22, 2013 at 6:22 PM, Christos Vasilakis
> <cvasilak@gmail.com <mailto:cvasilak@gmail.com>> wrote:
>
>     Hi team,
>
>     as we discuss in the meeting, we need a testbed app to go against
>     our integration tests for the nested path feature.  For this there
>     are two options:
>
>     a) either enhance our currently TODO app and add support for
>     schemas of "/projects/{id}/tasks/{id}/tags{id}".  Currently
>     ag-controller  supports nested path params.
>
>     b) create a separate and simple app eg. a blog engine with
>     /blog/{id}/comments/id} etc. so that we point our tests there.
>
>     The advantage that a) gives is that we don't need to write and
>     maintain a separate app, but we may need some different behaviour
>     that doesn't cover either TODO or controller's functionality (eg.
>     upload file functionality on the Pipe etc). So I am more in b) so
>     that we can use it as a general testbed for the features we want
>     to implement (now and in the future.)
>
>     Wdyt?
>
>     Thanks,
>     Christos
>
>
>
>
>
>
>     _______________________________________________
>     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
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
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