[aerogear-dev] AeroGear project demo planning

Thu Jun 27 05:23:44 EDT 2013

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

>
>
>
> On Thu, Jun 27, 2013 at 11:14 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>>
>>
>>
>> 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 .
>>
>
>
> Would that mean, I get a "Eclipse view" for the xcode tools? (like AppCode
> does)
> I think that for native iOS development, Xcode is the way to go. Perhaps
> AppCode as well (we haven't looked at AppCode regarding "template" or
> "plugins").
>

Well, yes sorry, forgot to mention that,  I was more thinking about  the
cordova stuff, the Aerogear JDBS plugin could discover where our "xcode"
runtime is and trigger an build for instance, Gorkem correct me if I'm
wrong.

>
> -Matthias
>
>
>
>
>>
>>>
>>>> ----------
>>>>
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/3af2b113/attachment-0001.html 