[aerogear-dev] AeroGear project demo planning

Thu Jun 27 05:14:21 EDT 2013

On Thu, Jun 27, 2013 at 11:10 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> 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?
>>
>
>
> yes, makes sense.
>
>
>
>>
>> _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.
>>
>
> Not sure I fully understand the "topic demos". Since you mentioned the
> tutorials. For iOS push we have this:
> http://staging.aerogear.org/docs/guides/aerogear-push-ios/
>
> and for Android we have this:
> https://issues.jboss.org/browse/AGPUSH-21
>
> Both have very simple client applications. cURL is used for triggering a
> push message. The demo itself is very simple, but the getting started
> (especially on iOS/Apple) is covered there as well. Do you mean something
> like that ?
>
> Another topic could be (taking push again), using CDI events: Show how to
> fire CDI-events and a CDI-Observer will just use Java-Sender API to send a
> simple Push message (like the cURL does). For that, we can also reuse the
> client apps.
>
>
>
>>
>> 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.
>>
>
> Like: OTP Quickstart for Android, iOS, JavaScript (and the server part)?
>
>
>>
>> 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).
>
>
> yes, I like that: they are simple and isolated (if I recall correctly). So
> it's not a gigantic app/mess :)
>
>
>
>>  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.
>>
>
> I think that makes sense
>
>
>
>>
>> * 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.
>>
>
>
> "Tooling for iOS": Not sure how our Xcode template falls into that
> "Tooling" category, but it helps a lot when getting started.
>
>
>>
>> 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 think the Xcode template we have is good enough, for "iOS tooling"
>

I know Gorkem has plans for ios (jbds) tooling, We should sync on that .

>
>
>> ----------
>>
>> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130627/213da6cf/attachment.html 