[aerogear-dev] AeroGear project demo planning

Thu Jun 27 05:17:29 EDT 2013

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").

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130627/3ee3ec07/attachment-0001.html 