On 26 Jun 2013, at 23:15, Jay Balunas <jbalunas(a)redhat.com&gt; 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_ We call this a showcase example.

> > 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… The definition of a quickstart we are using for JBoss products, and recommend for upstream as well, would include this kind of thing as a quickstart (with a level of Advanced :-). We've said that the defining characteristic of a quickstart is that it shows off a single use case, or a single API - IOW it is really focused on showing the user how to achieve that one thing. The code and set up can be as complex as you like.

> > 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… Please help us update our definitions and requirements for native mobile :-) At least we should start to flag general requirements from tech/platform specific requirements.

> > 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. For product quickstarts, we've gone for a flat structure, with no hierarchy. This has worked well for us, and it's only as we approach 100 quickstarts that we've needed to introduce a hierarchy. So IMO I would start simple (flat structure) and do a restructure once you've got feedback from both the authors and the users of quickstarts about what isn't and is working.

> > 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. We call this type of example a "demo" - something that shows of functionality, but won't necessarily be maintained etc.

> > _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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 27, 2013 at 11:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Thu, Jun 27, 2013 at 12:15 AM, Jay Balunas <jbalunas(a)redhat.com&gt;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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 27, 2013 at 12:15 AM, Jay Balunas <jbalunas(a)redhat.com&gt; 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" ---------- 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: > > On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: > >> >> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. > > Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml.

It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the demo files are. >> 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. > > +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) > >>> >>> _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. > > That is a good point, and something we should do for the showcase app for sure. > > It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. > >>> >>> _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. > > Can you break this down in hypotedical directory/repo structure? > > /foo > /bar > etc... I'll respond here later as I am on my phone right now :) > >>> >>> 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. > > Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. > >>> >>> * 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. > > This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. > >>> ---------- >>> >>> 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Some "Polyglot" toughts on "topic demos" and/or the show-case I'd like to see at least one "topic example", written in something else than Java(EE). This makes it easier for us promoting the mobile libraries to native iOS developers (or JS guys), since a JavaEE based backend is not something they would prefer using (most of them). For us the point is really "promoting" our MOBILE efforts, and we know our mobile lib's don't care about the backends. (E.g. take the integration tests we have for Android, iOS or JS - they go against Reddit or Github API - we have no clue (perhaps a guess) what they use for implementing these "services") Ok, now this ProDoctor is based on Forge/JavaEE, which is fine with me, since that's IMO the classical JBoss target. Also, if I understood Luke's comments from Summit, these guys are looking into "mobile" (Android, JS, iOS), so that's a good spot for them. However, the other platforms are also important (especially when talking to JS/iOS hackers). I'd say, yes - why not build another topic-example, based on a different "backend technology". I'd prefer Node.js over Ruby/Sinatra... (I can't read Clojure, so I am not proposing that :-)) I mean another topic demo, not a rewrite (aka "ProDoctor.js" ;-)) Or maybe even the "Show-Case" in some other language?? Take JRuby/Sinatra for example: But I am not 100% sure what that means if the "show-case" should/would also demonstrate our java libs (e.g. AG-Security). I *think* with TorqueBox/JRuby we can use most of our "java libs", but does require JRuby (and TB), right? So I am not 100% sure on that.... Greetings, Matthias On Fri, Jun 28, 2013 at 8:00 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: >> >> >> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: >> >>> >>> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: >>> >>>> >>>> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. >>> >>> Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? >> >> I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml. > > I agree > >> It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the >> demo files are. >> >>>> 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. >>> >>> +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) >>> >>>>> >>>>> _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. >>> >>> That is a good point, and something we should do for the showcase app for sure. >>> >>> It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. >>> >>>>> >>>>> _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. >>> >>> Can you break this down in hypotedical directory/repo structure? >>> >>> /foo >>> /bar >>> etc... >> >> I'll respond here later as I am on my phone right now :) >>> >>>>> >>>>> 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. >>> >>> Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. >>> >>>>> >>>>> * 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. >>> >>> This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. >>> >>>>> ---------- >>>>> >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

+1 for node.js/nodej instead of Ruby/Sinatra

On Fri, Jun 28, 2013 at 10:47 PM, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: On Jun 28, 2013, at 5:15 AM, Matthias Wessendorf wrote: > Some "Polyglot" toughts on "topic demos" and/or the show-case > > > I'd like to see at least one "topic example", written in something > else than Java(EE). This makes it easier for us promoting the mobile > libraries to native iOS developers (or JS guys), since a JavaEE based > backend is not something they would prefer using (most of them). > > For us the point is really "promoting" our MOBILE efforts, and we know > our mobile lib's don't care about the backends. (E.g. take the > integration tests we have for Android, iOS or JS - they go against > Reddit or Github API - we have no clue (perhaps a guess) what they use > for implementing these "services") > > Ok, now this ProDoctor is based on Forge/JavaEE, which is fine with > me, since that's IMO the classical JBoss target. Also, if I understood > Luke's comments from Summit, these guys > are looking into "mobile" (Android, JS, iOS), so that's a good spot for them. > > However, the other platforms are also important (especially when > talking to JS/iOS hackers). +1 > > I'd say, yes - why not build another topic-example, based on a > different "backend technology". > I'd prefer Node.js over Ruby/Sinatra... (I can't read Clojure, so I am > not proposing that :-)) +1 for node.js/nodej instead of Ruby/Sinatra. > > I mean another topic demo, not a rewrite (aka "ProDoctor.js" ;-)) I'm not against a new topic demo, but at the same time why not reuse the ProDoctor clients? /clients /ios /android /etc.. /servers /nodejs /wildfliy README.md If go with something completely separate we would need to commit to maintenance of it in the same way as the others. true :-) Also the ProDoctor "backend" is not that complicated yet. > > Or maybe even the "Show-Case" in some other language?? > Take JRuby/Sinatra for example: But I am not 100% sure what that means > if the "show-case" should/would also demonstrate our java libs (e.g. > AG-Security). I'm -1 to this for the first iteration of the showcase example, although as I mentioned we could certainly talk about multiple backend support yeah, the multiple backend is not wrong :)

> > I *think* with TorqueBox/JRuby we can use most of our "java libs", but > does require JRuby (and TB), right? So I am not 100% sure on that.... > > > Greetings, > Matthias > > > > > On Fri, Jun 28, 2013 at 8:00 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: >>> >>> >>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: >>> >>>> >>>> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: >>>> >>>>> >>>>> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. >>>> >>>> Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? >>> >>> I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml. >> >> I agree >> >>> It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the >>> demo files are. >>> >>>>> 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. >>>> >>>> +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) >>>> >>>>>> >>>>>> _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. >>>> >>>> That is a good point, and something we should do for the showcase app for sure. >>>> >>>> It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. >>>> >>>>>> >>>>>> _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. >>>> >>>> Can you break this down in hypotedical directory/repo structure? >>>> >>>> /foo >>>> /bar >>>> etc... >>> >>> I'll respond here later as I am on my phone right now :) >>>> >>>>>> >>>>>> 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. >>>> >>>> Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. >>>> >>>>>> >>>>>> * 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. >>>> >>>> This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. >>>> >>>>>> ---------- >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> indeed ! I think I could port the prodoctor backend to Grails in a half day. (just an indication , not actually doing it now ;) ) http://nooooooooooooooo.com/

- abstractj On Jun 29, 2013, 5:29 AM, Sébastien Blanc wrote: > > > Envoyé de mon iPhone > > Le Jun 29, 2013 à 9:46, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : > >> >> >> >> On Fri, Jun 28, 2013 at 10:47 PM, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: >> >> >>> On Jun 28, 2013, at 5:15 AM, Matthias Wessendorf wrote: >> >> >>> > Some "Polyglot" toughts on "topic demos" and/or the show-case >> >>> > >> >>> > >> >>> > I'd like to see at least one "topic example", written in something >> >>> > else than Java(EE). This makes it easier for us promoting the mobile >> >>> > libraries to native iOS developers (or JS guys), since a JavaEE based >> >>> > backend is not something they would prefer using (most of them). >> >>> > >> >>> > For us the point is really "promoting" our MOBILE efforts, and we know >> >>> > our mobile lib's don't care about the backends. (E.g. take the >> >>> > integration tests we have for Android, iOS or JS - they go against >> >>> > Reddit or Github API - we have no clue (perhaps a guess) what they use >> >>> > for implementing these "services") >> >>> > >> >>> > Ok, now this ProDoctor is based on Forge/JavaEE, which is fine with >> >>> > me, since that's IMO the classical JBoss target. Also, if I understood >> >>> > Luke's comments from Summit, these guys >> >>> > are looking into "mobile" (Android, JS, iOS), so that's a good spot for them. >> >>> > >> >>> > However, the other platforms are also important (especially when >> >>> > talking to JS/iOS hackers). >> >> +1 >> >> >>> > >> >>> > I'd say, yes - why not build another topic-example, based on a >> >>> > different "backend technology". >> >>> > I'd prefer Node.js over Ruby/Sinatra... (I can't read Clojure, so I am >> >>> > not proposing that :-)) >> >> +1 for node.js/nodej instead of Ruby/Sinatra. >> >> >>> > >> >>> > I mean another topic demo, not a rewrite (aka "ProDoctor.js" ;-)) >> >> I'm not against a new topic demo, but at the same time why not reuse the ProDoctor clients? >> >> >>> /clients >> >>> /ios >> >>> /android >> >>> /etc.. >> >>> /servers >> >>> /nodejs >> >>> /wildfliy >> >>> README.md >> >> >>> If go with something completely separate we would need to commit to maintenance of it in the same way as the others. >> >> true :-) Also the ProDoctor "backend" is not that complicated yet. >> >> >> >> >>> > >> >>> > Or maybe even the "Show-Case" in some other language?? >> >>> > Take JRuby/Sinatra for example: But I am not 100% sure what that means >> >>> > if the "show-case" should/would also demonstrate our java libs (e.g. >> >>> > AG-Security). >> >> I'm -1 to this for the first iteration of the showcase example, although as I mentioned we could certainly talk about multiple backend support >> >> yeah, the multiple backend is not wrong :) > indeed ! I think I could port the prodoctor backend to Grails in a half day. (just an indication , not actually doing it now ;) ) >> >> >> >>> > >> >>> > I *think* with TorqueBox/JRuby we can use most of our "java libs", but >> >>> > does require JRuby (and TB), right? So I am not 100% sure on that.... >> >>> > >> >>> > >> >>> > Greetings, >> >>> > Matthias >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > On Fri, Jun 28, 2013 at 8:00 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >> On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: >> >>> >>> >> >>> >>> >> >>> >>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: >> >>> >>> >> >>> >>>> >> >>> >>>> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: >> >>> >>>> >> >>> >>>>> >> >>> >>>>> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. >> >>> >>>> >> >>> >>>> Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? >> >>> >>> >>> >> >>> >>> I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml. >> >>> >> >> >>> >> I agree >> >>> >> >> >>> >>> It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the >> >>> >>> >>> demo files are. >> >>> >>> >> >>> >>>>> 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. >> >>> >>> >>>> >> >>> >>>> +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) >> >>> >>> >>>> >> >>> >>>>>> >> >>> >>>>>> _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. >> >>> >>> >>>> >> >>> >>>> That is a good point, and something we should do for the showcase app for sure. >> >>> >>>> >> >>> >>>> It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. >> >>> >>>> >> >>> >>>>>> >> >>> >>>>>> _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. >> >>> >>> >>>> >> >>> >>>> Can you break this down in hypotedical directory/repo structure? >> >>> >>>> >> >>> >>>> /foo >> >>> >>>> /bar >> >>> >>>> etc... >> >>> >>> >> >>> >>> I'll respond here later as I am on my phone right now :) >> >>> >>>> >> >>> >>>>>> >> >>> >>>>>> 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. >> >>> >>> >>>> >> >>> >>>> Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. >> >>> >>> >>>> >> >>> >>>>>> >> >>> >>>>>> * 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. >> >>> >>> >>>> >> >>> >>>> This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. >> >>> >>> >>>> >> >>> >>>>>> ---------- >> >>> >>>>>> >> >>> >>>>>> 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 >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> _______________________________________________ >> >>> >>>>> aerogear-dev mailing list >> >>> >>>>> aerogear-dev(a)lists.jboss.org >> >>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >>>> >> >>> >>>> >> >>> >>>> _______________________________________________ >> >>> >>>> aerogear-dev mailing list >> >>> >>>> aerogear-dev(a)lists.jboss.org >> >>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >>> >> >>> >>> _______________________________________________ >> >>> >>> aerogear-dev mailing list >> >>> >>> aerogear-dev(a)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 >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Matthias Wessendorf >> >>> > >> >>> > blog: http://matthiaswessendorf.wordpress.com/ >> >>> > sessions: http://www.slideshare.net/mwessendorf >> >>> > twitter: http://twitter.com/mwessendorf >> >>> > >> >>> > _______________________________________________ >> >>> > aerogear-dev mailing list >> >>> > aerogear-dev(a)lists.jboss.org >> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

So is it the conclusion that this sort of structure is acceptable for showcase & topic demos at least? > /clients > /ios > /android > /etc.. > /servers > /nodejs > /wildfliy > README.md > Any strong objections to this? I would say quickstarts are more case-by-case.

On Jun 29, 2013, at 3:46 AM, Matthias Wessendorf wrote: > > > > On Fri, Jun 28, 2013 at 10:47 PM, Jay Balunas <jbalunas(a)redhat.com > <mailto:jbalunas@redhat.com>> wrote: > > > On Jun 28, 2013, at 5:15 AM, Matthias Wessendorf wrote: > > > Some "Polyglot" toughts on "topic demos" and/or the show-case > > > > > > I'd like to see at least one "topic example", written in something > > else than Java(EE). This makes it easier for us promoting the > mobile > > libraries to native iOS developers (or JS guys), since a JavaEE > based > > backend is not something they would prefer using (most of them). > > > > For us the point is really "promoting" our MOBILE efforts, and > we know > > our mobile lib's don't care about the backends. (E.g. take the > > integration tests we have for Android, iOS or JS - they go against > > Reddit or Github API - we have no clue (perhaps a guess) what > they use > > for implementing these "services") > > > > Ok, now this ProDoctor is based on Forge/JavaEE, which is fine with > > me, since that's IMO the classical JBoss target. Also, if I > understood > > Luke's comments from Summit, these guys > > are looking into "mobile" (Android, JS, iOS), so that's a good > spot for them. > > > > However, the other platforms are also important (especially when > > talking to JS/iOS hackers). > > +1 > > > > > I'd say, yes - why not build another topic-example, based on a > > different "backend technology". > > I'd prefer Node.js over Ruby/Sinatra... (I can't read Clojure, > so I am > > not proposing that :-)) > > +1 for node.js/nodej instead of Ruby/Sinatra. > > > > > I mean another topic demo, not a rewrite (aka "ProDoctor.js" ;-)) > > I'm not against a new topic demo, but at the same time why not > reuse the ProDoctor clients? > > /clients > /ios > /android > /etc.. > /servers > /nodejs > /wildfliy > README.md > > If go with something completely separate we would need to commit > to maintenance of it in the same way as the others. > > > true :-) Also the ProDoctor "backend" is not that complicated yet. > > > > > > Or maybe even the "Show-Case" in some other language?? > > Take JRuby/Sinatra for example: But I am not 100% sure what > that means > > if the "show-case" should/would also demonstrate our java libs > (e.g. > > AG-Security). > > I'm -1 to this for the first iteration of the showcase example, > although as I mentioned we could certainly talk about multiple > backend support > > > yeah, the multiple backend is not wrong :) > > > > > > I *think* with TorqueBox/JRuby we can use most of our "java > libs", but > > does require JRuby (and TB), right? So I am not 100% sure on > that.... > > > > > > Greetings, > > Matthias > > > > > > > > > > On Fri, Jun 28, 2013 at 8:00 AM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > >> On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers > <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: > >>> > >>> > >>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com > <mailto:jbalunas@redhat.com>> wrote: > >>> > >>>> > >>>> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: > >>>> > >>>>> > >>>>> On Jun 26, 2013, at 5:15 PM, Jay Balunas > <jbalunas(a)redhat.com <mailto:jbalunas@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. > >>>> > >>>> Not sure what difference is between having it be possible > and having it be a requirement. You mean it might not be able to > deploy to these, or just that it would be just one of the > options? From the comments below I think you mean the latter - right? > >>> > >>> I mean for a JS demo for example, I would prefer it not be in > a maven based file structure with a pom.xml. > >> > >> I agree > >> > >>> It would be better to just be an HTML app that someone could > drop in a maven project I'd that's what they wanted to use but > they shouldn't have to be familiar with that setup to understand > where the > >>> demo files are. > >>> > >>>>> 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. > >>>> > >>>> +1 I would like to see that too. We've talked from time to > time about vert.x, torquebox, node.js, ruby, etc... I think > these are optional, at least at this point, but would certainly > be nice to have in place. I'd love to see a /servers directory > right next to the /clients directory :-) > >>>> > >>>>>> > >>>>>> _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. > >>>> > >>>> That is a good point, and something we should do for the > showcase app for sure. > >>>> > >>>> It actually sounds like from Pete and JDFs definition of > quickstarts that the "topic examples" might really still fit that > classification anyway. > >>>> > >>>>>> > >>>>>> _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. > >>>> > >>>> Can you break this down in hypotedical directory/repo structure? > >>>> > >>>> /foo > >>>> /bar > >>>> etc... > >>> > >>> I'll respond here later as I am on my phone right now :) > >>>> > >>>>>> > >>>>>> 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. > >>>> > >>>> Agreed on holding back the conversation while we discuss the > examples, but with as complex a project as this I really believe > we need to have and maintain standards for things like this, or > we'll end up with spaghetti. > >>>> > >>>>>> > >>>>>> * 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. > >>>> > >>>> This is another standard is needed imo, or at least updated > and used. Coding standards for the various languages, IDE config > files where possible. There is one in the repos now, but it has > not been updated, review, or maybe even used in a long time. > >>>> > >>>>>> ---------- > >>>>>> > >>>>>> 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 > <mailto:aerogear-dev@lists.jboss.org> > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org> > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org> > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: > On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: > >> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. > Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml. It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the demo files are.

>> 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. > +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) > >>> _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. > That is a good point, and something we should do for the showcase app for sure. > > It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. > >>> _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. > Can you break this down in hypotedical directory/repo structure? > > /foo > /bar > etc... I'll respond here later as I am on my phone right now :) >>> 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. > Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. > >>> * 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. > This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. > >>> ---------- >>> >>> 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

None … literally just the files. I don't have to have any project around it to just open an HTML file on my local server or even directly in the browser.

None … literally just the files. I don't have to have any project around it to just open an HTML file on my local server or even directly in the browser.

On 27 Jun 2013, at 22:39, Kris Borchers <kborcher(a)redhat.com&gt; wrote: > > > On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: > >> >> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote: >> >>> >>> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com&gt; 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. >> >> Not sure what difference is between having it be possible and having it be a requirement. You mean it might not be able to deploy to these, or just that it would be just one of the options? From the comments below I think you mean the latter - right? > > I mean for a JS demo for example, I would prefer it not be in a maven based file structure with a pom.xml. It would be better to just be an HTML app that someone could drop in a maven project I'd that's what they wanted to use but they shouldn't have to be familiar with that setup to understand where the demo files are. I would agree this makes sense, and that is why I'm asking you guys help us update guidelines for other environments :-) The ones we have are definitely Java (EE) centric. Maybe, the way to express it is "If the project can be deployed on WildFly or OpenShift, instructions to do so should be included"?

>> >>> 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. >> >> +1 I would like to see that too. We've talked from time to time about vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this point, but would certainly be nice to have in place. I'd love to see a /servers directory right next to the /clients directory :-) >> >>>> >>>> _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. >> >> That is a good point, and something we should do for the showcase app for sure. >> >> It actually sounds like from Pete and JDFs definition of quickstarts that the "topic examples" might really still fit that classification anyway. >> >>>> >>>> _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. >> >> Can you break this down in hypotedical directory/repo structure? >> >> /foo >> /bar >> etc... > > I'll respond here later as I am on my phone right now :) >> >>>> >>>> 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. >> >> Agreed on holding back the conversation while we discuss the examples, but with as complex a project as this I really believe we need to have and maintain standards for things like this, or we'll end up with spaghetti. >> >>>> >>>> * 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. >> >> This is another standard is needed imo, or at least updated and used. Coding standards for the various languages, IDE config files where possible. There is one in the repos now, but it has not been updated, review, or maybe even used in a long time. >> >>>> ---------- >>>> >>>> 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 >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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.

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev