[aerogear-dev] AeroGear project demo planning

Tue Aug 20 04:12:26 EDT 2013

I guess we still need to 'define' what we want to do, for a 'Showcase Demo';

Is this something we want already for the next (1.2.0 umbrella) release? Or
later ?

-Matthias

On Thu, Jun 27, 2013 at 12:15 AM, Jay Balunas <jbalunas at redhat.com> wrote:

> Hi All,
>
> As discussed in the team meeting I wanted to restart discussions around
> the demos for the project.  I know it is long but it is also very important
> that we agree on our example strategy because it is one of the primary ways
> that people will learn about AeroGear - especially just starting out.  We
> also need to balance this with the fact that maintenance of multiple
> examples can be time consuming (src, docs, tests, etc...).
>
> Let me state what I think would be a good model for us at a high level,
> and then when we come to a consensus about this we can dig into the
> individual example ideas, specifically around the "showcase" demo (likely
> in another thread).
>
> All of this is my opinion, not law ;-)
>
> _Showcase Demo_
>
> One larger scale demo that we can cover all (or nearly all) of the planned
> functionality up to 2.0.  There has been several ideas tossed around from
> stock broker, prodoctor, etc...  I don't want to focus on the specific app
> at this point.  Functionality would be additive as we completed it, so the
> idea would need to be easily "upgraded" as we go.
>
> The app should include all client types as examples (iOS, Android, Hybrid,
> Web), have a central backend, be deployable to OpenShift, and run on
> Wildfly/EAP.  It would require documentation to discuss complexities and
> usage for an advanced application, but would not need to cover the bread
> and butter imo (that is what the quickstart tutorials are for).  We would
> have to commit to long term maintenance of this as well.
>
> There are pros and cons for this type of application.  The maintenance and
> development burden is high.  Also we need to be careful not to devote so
> much time to the application that it takes on a life of its own.  I.e. we
> are not really trying to make a fully competitive stock broker app.
>
> We also want to consider if/how this application would be deployed to an
> appstore.  Depending on the application it may be very appropriate for it
> to be there, but we'll need to discuss.
>
> Does this sounds acceptable as the scope and starting point for a showcase
> demo?
>
> _Topic Demos_
>
> I'm not sure about this category of demo yet, but wanted to bring it up.
>  There are use-cases, and functionality that by their definition are beyond
> the scope of quickstart, and yet we would likely not want to have the
> showcase demo be the only location we demo the functionality.
>
> The best example of this I can think of is Unified Push.  I think we all
> agree, just the basic setup and requirements around push make it more than
> a quickstart.  With the various servers, configuration, certs, etc...  At
> the same time, we need a demo (both sooner, and simpler) than the showcase
> demo for the related tutorials, docs, etc...
>
> So this category would be for this type of "topic" - I could see the
> possibility of some security functionality falling into this too, but I'm
> not 100% on that.
>
> It would have the same type of requirements as the other demos - docs,
> tests, maintenance, etc...
>
> Pros would be a more focused demo for specific functionality, cons are
> another non-trivial demo to maintain.
>
> My personal opinion here would be take it on a case by case basis.
>
> _Quickstarts_
>
> This category sounds like it might be the simplest, but as a whole I think
> it represents a fairly large amount of work.  Imo a quickstart is a focused
> demo, that highlights 1-2 specific use-cases.  JDF has a lot of good
> definitions and requirements for quick starts that we should consider as
> well, where they don't conflict.  For example build tools, deployment
> options, etc...
>
> The trick here comes with how to manage and handle all of our different
> "parts".  Do we group by client type, by functionality, etc...  So for
> example, take a security related quickstart.  It should show how to
> integration security across the various client types.  Is that 1 quickstart
> for security, or 3 by client type.
>
> Related to this is the cookbook idea that the Android team is using.  Imo
> I think it is VERY important that all of our client types share a similar
> approach (cookbook or not).  We don't want completely different approaches
> by client type.  If we do group quickstarts (some or all) by client how
> will we handle common server-side functionality such as that security
> example above.
>
> All of these items get complicated quickly, but I think we need to nail
> this down asap because we should start thinking about our quickstart
> libraries soon imo.
>
> _One off examples_
>
> Another type of example was mentioned in the ML, and that is of one-off
> examples for presentations, blogs, etc...  Imo these are useful, and likely
> needed some of the time.
>
> I think we should re-use our other examples when possible, but I also know
> that will not alway work for various reasons.  These examples carry no
> maintenance expectations, and should not be in the AeroGear repositories
> either imo.
>
> I also think it is possible for one-off examples to "become" quickstarts,
> but would have to meet the standards for a quickstart as we describe them.
>
> _Repositories_
>
> This is a related topic that I think will likely become its own thread or
> document, and that is about repository usage for the example types above.
>  In general we need a better policy imo around this topic in general.
>
> * Showcase example: I believe it should have a single repository with
> /server, /client, and /docs directories as needed.  I believe having
> separate repositories is confusing and leads to clutter.  The intent of the
> showcase app is to demo how everything integrates in one place, and should
> be easily accessed.
>
> * Topic examples: I believe these should have a similar requirement as the
> showcase example.  The point of the topic example is to cover a specific
> topic, not specific individual clients.
>
> * Quickstart examples:  This again gets complicated, and may depend on the
> way we choose  to group them.  However we group them, I think we should
> have a limited number of *-quickstart repositories, we should not have a
> repo for each quickstart.  We'll need to discuss this as we discuss
> quickstart planning in general.
>
> * One off examples: should not be in AeroGear's repository at all.  Imo,
> if we aren't committing to maintain it we should not have it our repository.
>
> _Forge and JBDS_
>
> We also need to discuss how any of these examples relate to forge and JBDS
> efforts.  At the very least, imo, some of our quickstarts should be based
> on scaffolding, and tooling.  Imo many of the example (where possible)
> should be compatible with forge, and JBDS.
>
> Not all examples would need to be compatible.  Obviously that does not
> apply to iOS, and we would need to balance the effort required on a
> case-by-case basis for others.  It just might not make sense or have a
> different target than forge or JBDS.  That is fine, I don't want to use
> this as a handicap, but we should be considering both of these as we go.
> ----------
>
> Again, I don't want this thread to break down into specific use-case
> discussions, I want us to discuss the example strategies for the project,
> then we can kick off separate thread for break down specific examples, and
> plans for them.
>
> -Jay
> _______________________________________________
> 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/20130820/b857b431/attachment.html 