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.
No objections to this.
Somehow I feel like quick starts aren't really case by case but more
platform oriented
IE
----repo areogear-android quickstart
/quickstarts
/auth
/pipe
/paging
/etc...
README.md
Maybe even (for Android) quickstarts could just be maven archetypes.
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