2:39 p.m.
On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)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?
Yes, this sounds good to me. One comment - I would say that being deployable to OpenShift
and run on Wildfly/EAP should be "possible" but not a requirement. IMO, if
possible, this backend should be flexible enough to deploy to multiple backends, in fact,
at some point it might be nice to provide a choice of backend. I agree that our central
backend should have those requirements and by default the clients would point there but it
should be clear that the clients aren't tied to one backend as well.
_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.
I think this is where multiple uses out of a single showcase could come in handy. We could
write tutorials around a single portion of the larger showcase demo, highlighting the
topic at hand (unified push for example). I think that could be useful both for
highlighting a single piece of functionality and for breaking that large app down into
digestible pieces.
_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.
So I would say there is no single solution here. My thought would be that if this is a
server side quickstart (demoing a new feature in security for example), it would be a
single quickstart with 3 (or 4 with hybrid) very simple clients included. For client
quickstarts, an idea I had would be that they could be there own quickstart so there would
be 3 or 4 of them and to solve the single backend, we have one more repo for the backend
and it can be included as a git submodule to each quickstart. I'll wait for qmx to
object here :) as I am also not a huge fan of submodules but I think they could solve a
problem here and with appropriate instructions in the README could be handled properly.
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.
I am a fan of the cookbook idea and I think my comment above addresses that concern.
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.
+1 we need to start on quickstarts ASAP
_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.
+1
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.
Sure
_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.
I don't think we need a spelled out document for this but agree that this should
probably be its own thread. I would prefer that this be discussed after we figure out our
demo strategy, then we'll have a better idea of repo needs and can plan from there.
* 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.
I agree that we need some forge and tooling specific examples, quickstarts, what ever. My
only concern is that unless we can get the code generated by forge prettier (proper white
space being one of my biggest pet peeves) so that someone looking at the generated code
doesn't struggle to read it, I don't want the demo code scaffolded. Not sure how
possible this is but IMO is very important for the usability of our demos as learning
tools.
----------
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev