[aerogear-dev] nested path - testbed

[Matthias Wessendorf]

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 at 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 at gmail.com <mailto:cvasilak at 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 at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130423/181c5a69/attachment.html