<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/01/2013 02:49 PM, Jay Balunas
wrote:<br>
</div>
<blockquote
cite="mid:BEA2D4A5-DBFE-4970-935D-11DA67C409ED@redhat.com"
type="cite">So is it the conclusion that this sort of structure is
acceptable for showcase & topic demos at least?
<div><br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin-top: 0px;
margin-right: 0px; margin-bottom: 0px; margin-left:
0.8ex; border-left-width: 1px; border-left-color:
rgb(204, 204, 204); border-left-style: solid;
padding-left: 1ex; position: static; z-index: auto; ">/clients<br>
/ios<br>
/android<br>
/etc..<br>
/servers<br>
/nodejs<br>
/wildfliy<br>
README.md</blockquote>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Any strong objections to this? I would say quickstarts are
more case-by-case.</div>
<div><br>
</div>
</div>
</blockquote>
No objections to this.<br>
<br>
Somehow I feel like quick starts aren't really case by case but more
platform oriented<br>
<br>
IE<br>
<br>
----repo areogear-android quickstart<br>
/quickstarts<br>
/auth<br>
/pipe<br>
/paging<br>
/etc...<br>
README.md<br>
<br>
Maybe even (for Android) quickstarts could just be maven archetypes.<br>
<blockquote
cite="mid:BEA2D4A5-DBFE-4970-935D-11DA67C409ED@redhat.com"
type="cite">
<div><br>
<div>
<div>On Jun 29, 2013, at 3:46 AM, Matthias Wessendorf wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jun 28, 2013 at 10:47
PM, Jay Balunas <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jbalunas@redhat.com" target="_blank">jbalunas@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin-top:
0px; margin-right: 0px; margin-bottom: 0px;
margin-left: 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div class="im"><br>
On Jun 28, 2013, at 5:15 AM, Matthias Wessendorf
wrote:<br>
<br>
> Some "Polyglot" toughts on "topic demos"
and/or the show-case<br>
><br>
><br>
> I'd like to see at least one "topic example",
written in something<br>
> else than Java(EE). This makes it easier for
us promoting the mobile<br>
> libraries to native iOS developers (or JS
guys), since a JavaEE based<br>
> backend is not something they would prefer
using (most of them).<br>
><br>
> For us the point is really "promoting" our
MOBILE efforts, and we know<br>
> our mobile lib's don't care about the
backends. (E.g. take the<br>
> integration tests we have for Android, iOS or
JS - they go against<br>
> Reddit or Github API - we have no clue
(perhaps a guess) what they use<br>
> for implementing these "services")<br>
><br>
> Ok, now this ProDoctor is based on
Forge/JavaEE, which is fine with<br>
> me, since that's IMO the classical JBoss
target. Also, if I understood<br>
> Luke's comments from Summit, these guys<br>
> are looking into "mobile" (Android, JS, iOS),
so that's a good spot for them.<br>
><br>
> However, the other platforms are also
important (especially when<br>
> talking to JS/iOS hackers).<br>
<br>
</div>
+1<br>
<div class="im"><br>
><br>
> I'd say, yes - why not build another
topic-example, based on a<br>
> different "backend technology".<br>
> I'd prefer Node.js over Ruby/Sinatra... (I
can't read Clojure, so I am<br>
> not proposing that :-))<br>
<br>
</div>
+1 for node.js/nodej instead of Ruby/Sinatra.<br>
<div class="im"><br>
><br>
> I mean another topic demo, not a rewrite (aka
"ProDoctor.js" ;-))<br>
<br>
</div>
I'm not against a new topic demo, but at the same
time why not reuse the ProDoctor clients?<br>
<br>
/clients<br>
/ios<br>
/android<br>
/etc..<br>
/servers<br>
/nodejs<br>
/wildfliy<br>
README.md<br>
<br>
If go with something completely separate we would
need to commit to maintenance of it in the same way
as the others.<br>
</blockquote>
<div><br>
</div>
<div style="">true :-) Also the ProDoctor "backend"
is not that complicated yet. </div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> Or maybe even the "Show-Case" in some other
language??<br>
> Take JRuby/Sinatra for example: But I am not
100% sure what that means<br>
> if the "show-case" should/would also
demonstrate our java libs (e.g.<br>
> AG-Security).<br>
<br>
</div>
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<br>
</blockquote>
<div><br>
</div>
<div style="">yeah, the multiple backend is not wrong
:)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
><br>
> I *think* with TorqueBox/JRuby we can use
most of our "java libs", but<br>
> does require JRuby (and TB), right? So I am
not 100% sure on that....<br>
><br>
><br>
> Greetings,<br>
> Matthias<br>
><br>
><br>
><br>
><br>
> On Fri, Jun 28, 2013 at 8:00 AM, Matthias
Wessendorf <<a moz-do-not-send="true"
href="mailto:matzew@apache.org">matzew@apache.org</a>>
wrote:<br>
>> On Thu, Jun 27, 2013 at 11:39 PM, Kris
Borchers <<a moz-do-not-send="true"
href="mailto:kborcher@redhat.com">kborcher@redhat.com</a>>
wrote:<br>
>>><br>
>>><br>
>>> On Jun 27, 2013, at 16:04, Jay
Balunas <<a moz-do-not-send="true"
href="mailto:jbalunas@redhat.com">jbalunas@redhat.com</a>>
wrote:<br>
>>><br>
>>>><br>
>>>> On Jun 27, 2013, at 8:39 AM,
Kris Borchers wrote:<br>
>>>><br>
>>>>><br>
>>>>> On Jun 26, 2013, at 5:15
PM, Jay Balunas <<a moz-do-not-send="true"
href="mailto:jbalunas@redhat.com">jbalunas@redhat.com</a>>
wrote:<br>
>>>>><br>
>>>>>> Hi All,<br>
>>>>>><br>
>>>>>> 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...).<br>
>>>>>><br>
>>>>>> 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).<br>
>>>>>><br>
>>>>>> All of this is my
opinion, not law ;-)<br>
>>>>>><br>
>>>>>> _Showcase Demo_<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> Does this sounds
acceptable as the scope and starting point for a
showcase demo?<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> 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?<br>
>>><br>
>>> I mean for a JS demo for example, I
would prefer it not be in a maven based file
structure with a pom.xml.<br>
>><br>
>> I agree<br>
>><br>
>>> 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<br>
>>> demo files are.<br>
>>><br>
>>>>> 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.<br>
>>>><br>
>>>> +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 :-)<br>
>>>><br>
>>>>>><br>
>>>>>> _Topic Demos_<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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...<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> It would have the same
type of requirements as the other demos - docs,
tests, maintenance, etc...<br>
>>>>>><br>
>>>>>> Pros would be a more
focused demo for specific functionality, cons
are another non-trivial demo to maintain.<br>
>>>>>><br>
>>>>>> My personal opinion
here would be take it on a case by case basis.<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> That is a good point, and
something we should do for the showcase app for
sure.<br>
>>>><br>
>>>> It actually sounds like from
Pete and JDFs definition of quickstarts that the
"topic examples" might really still fit that
classification anyway.<br>
>>>><br>
>>>>>><br>
>>>>>> _Quickstarts_<br>
>>>>>><br>
>>>>>> 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...<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> Can you break this down in
hypotedical directory/repo structure?<br>
>>>><br>
>>>> /foo<br>
>>>> /bar<br>
>>>> etc...<br>
>>><br>
>>> I'll respond here later as I am on
my phone right now :)<br>
>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> I am a fan of the cookbook
idea and I think my comment above addresses that
concern.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> +1 we need to start on
quickstarts ASAP<br>
>>>>>><br>
>>>>>> _One off examples_<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> +1<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> Sure<br>
>>>>>><br>
>>>>>> _Repositories_<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>>>><br>
>>>>>> * 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.<br>
>>>>>><br>
>>>>>> * 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.<br>
>>>>>><br>
>>>>>> * 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.<br>
>>>>>><br>
>>>>>> * 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.<br>
>>>>>><br>
>>>>>> _Forge and JBDS_<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>>>> ----------<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> -Jay<br>
>>>>>>
_______________________________________________<br>
>>>>>> aerogear-dev mailing
list<br>
>>>>>> <a
moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>> <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>><br>
>>>>><br>
>>>>>
_______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> aerogear-dev mailing list<br>
>>>> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>>
_______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Matthias Wessendorf<br>
>><br>
>> blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>> sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>> twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf"
target="_blank">http://twitter.com/mwessendorf</a><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf"
target="_blank">http://twitter.com/mwessendorf</a><br>
><br>
>
_______________________________________________<br>
> aerogear-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Matthias Wessendorf <br>
<br>
blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</body>
</html>