3:06 p.m.
Hey everyone,
So we've been doing continuous improvements to the website. Corinne and
Erik have been making some awesome progress shaping up the new
documentation section (roadmap here:
http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/) according
to the mockups
(https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...).
We've split stuff up into "Setup Howtos", "Examples", "API
Documentation" and "Guides". I don't think there was much controversy
here and there's been made some headway already in unifying some of the
documentation.
The most important change in the website mockups was that instead of
focusing on platform branding, the focus is on solving use cases that
"we happen to support on these platforms". So Core/Push/Security are the
main players over iOS/Android/JS, although these are still referenced
everywhere and presented in a graphic on top of the home page.
Before we can work on the project homepage sections and download areas
of the website we should have a discussion about how the AeroGear
project itself is structured. The project seems to have grown
organically and new modules have been added here and there. There are
some of these that make the structure of the project more complicated
that it needs to be (in my opinion) to present it in a simple way to
developers visiting the website.
I've done some research on the project structure and have written down
the findings, as well as points where there's room for improvement and
possible solutions, here: http://oksoclap.com/p/AeroGearModuleUntangling
TL;DR: The most important questions that we need to answer are these:
- "If I download a library on one platform, what must I download to use
the same features on an other platform?"
-"Is this a part I use on the client, or on the server side?"
-"What do we mean when talking about different AeroGear
subprojects/modules?"
One solution might be:
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
I've made a lot of assumptions here, and it might not work, but I'd like
to hear your thoughts on it.
It would clarify a lot if we could harmonise the different downloads
across platforms, either by providing single download solutions or
splitting everything up and naming all the parts consistently. I'm
interested in what the technical issues might be, as I wasn't around
when most of these decisions were made, or I simply missed them.
Thoughts or other ideas? :)
Thanks,
Hylke
6:06 p.m.
Hylke amazing work, I can’t wait to see it in production.
--
abstractj
On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons(a)redhat.com) wrote:
TL;DR: The most important questions that we need to answer are
these:
- "If I download a library on one platform, what must I download
to use
the same features on an other platform?"
-"Is this a part I use on the client, or on the server side?”
Not sure if I understood your question correctly, but to get the full solution, you need
to download both
-"What do we mean when talking about different AeroGear
subprojects/modules?”
By subprojects I understand as exactly like you did
at https://raw2.github.com/hbons/aerogear-design/master/website-restructu....
One solution might be:
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
I've made a lot of assumptions here, and it might not work, but
I'd like
to hear your thoughts on it.
It would clarify a lot if we could harmonise the different downloads
across platforms, either by providing single download solutions
or
splitting everything up and naming all the parts consistently.
I'm
interested in what the technical issues might be, as I wasn't
around
when most of these decisions were made, or I simply missed them.
Thoughts or other ideas? :)
I don’t have any idea, because I liked the way how it was organized. No disagreement
here.
Thanks,
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:16 p.m.
On Feb 20, 2014, at 12:06 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hylke amazing work, I can’t wait to see it in production.
+1 Hylke - good stuff, and a lot to get through!
--
abstractj
On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons(a)redhat.com) wrote:
>
> TL;DR: The most important questions that we need to answer are
> these:
> - "If I download a library on one platform, what must I download
> to use
> the same features on an other platform?"
I like this approach. I'd rather be feature driven than library driven. I think most
yours will be looking for what we can do for them before looking at what native libs we
provide.
Lets get this breakdown together for Hylke - using the eitherpad or a gist seems the best
approach here.
> -"Is this a part I use on the client, or on the server
side?”
Not sure if I understood your question correctly, but to get the full solution, you need
to download both
I think he means for each feature is there a client and a server part and if so how do we
offer them. Then we can get the info and links for the solution in one place. Hylke - is
that it or something else?
> -"What do we mean when talking about different AeroGear
> subprojects/modules?”
By subprojects I understand as exactly like you did at
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/....
>
> One solution might be:
>
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
> I've made a lot of assumptions here, and it might not work, but
> I'd like
> to hear your thoughts on it.
>
> It would clarify a lot if we could harmonise the different downloads
> across platforms, either by providing single download solutions
> or
> splitting everything up and naming all the parts consistently.
> I'm
> interested in what the technical issues might be, as I wasn't
> around
> when most of these decisions were made, or I simply missed them.
>
> Thoughts or other ideas? :)
I don’t have any idea, because I liked the way how it was organized. No disagreement
here.
+1 keep up the good work!
>
> Thanks,
>
> Hylke
> _______________________________________________
> 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
3:50 p.m.
----- Original Message -----
From: "Jay Balunas" <tech4j(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Cc: "Matt Carrano" <mcarrano(a)redhat.com>
Sent: Monday, February 24, 2014 9:16:38 AM
Subject: Re: [aerogear-dev] AeroGear project structure and the website
On Feb 20, 2014, at 12:06 PM, Bruno Oliveira < bruno(a)abstractj.org
> wrote:
> Hylke amazing work, I can’t wait to see it in production.
+1 Hylke - good stuff, and a lot to get through!
+1 this is great!
> --
> abstractj
> On February 20, 2014 at 11:06:34 AM, Hylke Bons (
hbons(a)redhat.com ) wrote:
> > TL;DR: The most important questions that we need to answer
are
>
> > these:
>
> > - "If I download a library on one platform, what must I download
>
> > to use
>
> > the same features on an other platform?"
>
I like this approach. I'd rather be feature driven than library
driven. I
think most yours will be looking for what we can do for them before looking
at what native libs we provide.
Lets get this breakdown together for Hylke - using the eitherpad or a
gist
seems the best approach here.
As the noob to the group... perhaps another way to think of this could be by platform
-> type of resource needed -> then desired feature?
So If I'm a Cordova developer and I want to learn how-to setup UnifiedPush Server and
integrate Push within my hybrid app I don't care about the native Android & iOS
libraries, guides, etc.. I just want everything that is relevant to hybrid apps. I
actually ran into this exact issue this last weekend when I created my first push
notification app. Its hard to keep track of what guides and sample code I needed. This may
solve that. I kind of like the way http://devcenter.kinvey.com/ does this. When I first go
there it allows me to select my dev platform and it sets a cookie so when I come back its
still on that platform. I can swap at any time, but as a developer I really liked the
Kinvey experience because I could find what I needed. Nothing more nothing less.
> > -"Is this a part I use on the client, or on the server
side?”
>
> Not sure if I understood your question correctly, but to get the
full
> solution, you need to download both
I think he means for each feature is there a client and a server part
and if
so how do we offer them. Then we can get the info and links for the solution
in one place. Hylke - is that it or something else?
> > -"What do we mean when talking about different
AeroGear
>
> > subprojects/modules?”
>
> By subprojects I understand as exactly like you did at
>
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
> .
> > One solution might be:
>
> >
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
>
> > I've made a lot of assumptions here, and it might not work, but
>
> > I'd like
>
> > to hear your thoughts on it.
>
> > It would clarify a lot if we could harmonise the different
downloads
>
> > across platforms, either by providing single download solutions
>
> > or
>
> > splitting everything up and naming all the parts consistently.
>
> > I'm
>
> > interested in what the technical issues might be, as I wasn't
>
> > around
>
> > when most of these decisions were made, or I simply missed them.
>
> > Thoughts or other ideas? :)
>
> I don’t have any idea, because I liked the way how it was
organized. No
> disagreement here.
+1 keep up the good work!
> > Thanks,
>
> > Hylke
>
> > _______________________________________________
>
> > 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
6:43 p.m.
On 24/02/2014 14:50, Lee Graham wrote:
So If I'm a Cordova developer and I want to learn how-to setup
UnifiedPush Server and integrate Push within my hybrid app I don't
care about the native Android & iOS libraries, guides, etc.. I just
want everything that is relevant to hybrid apps. I actually ran into
this exact issue this last weekend when I created my first push
notification app. Its hard to keep track of what guides and sample
code I needed. This may solve that. I kind of like the way
http://devcenter.kinvey.com/ does this. When I first go there it
allows me to select my dev platform and it sets a cookie so when I
come back its still on that platform. I can swap at any time, but as a
developer I really liked the Kinvey experience because I could find
what I needed. Nothing more nothing less.
Cordova is a bit of a special case. Apart from a mention that Cordova is
a supported platform on the front page, I'm not quite if we should have
it as a mention for every feature, as we already have Javascript there.
We need to find out how Corodova developers normally go about picking
libraries that they want to use. I assume they can use any Javascript
library? Perhaps we just add a note to the download page that for use
with Cordova you case use the Javascript library and download a native
plugin if needed.
Hylke
4:29 p.m.
----- Original Message -----
From: "Hylke Bons" <hbons(a)redhat.com>
To: aerogear-dev(a)lists.jboss.org
Sent: Tuesday, February 25, 2014 12:43:27 PM
Subject: Re: [aerogear-dev] AeroGear project structure and the website
On 24/02/2014 14:50, Lee Graham wrote:
> So If I'm a Cordova developer and I want to learn how-to setup
> UnifiedPush Server and integrate Push within my hybrid app I don't
> care about the native Android & iOS libraries, guides, etc.. I just
> want everything that is relevant to hybrid apps. I actually ran into
> this exact issue this last weekend when I created my first push
> notification app. Its hard to keep track of what guides and sample
> code I needed. This may solve that. I kind of like the way
> http://devcenter.kinvey.com/ does this. When I first go there it
> allows me to select my dev platform and it sets a cookie so when I
> come back its still on that platform. I can swap at any time, but as a
> developer I really liked the Kinvey experience because I could find
> what I needed. Nothing more nothing less.
Cordova is a bit of a special case. Apart from a mention that Cordova
is
a supported platform on the front page, I'm not quite if we should have
it as a mention for every feature, as we already have Javascript there.
We need to find out how Corodova developers normally go about
picking
libraries that they want to use. I assume they can use any Javascript
library? Perhaps we just add a note to the download page that for use
with Cordova you case use the Javascript library and download a native
plugin if needed.
Makes sense to me. I think the current site does confuse me a
bit... what's the difference between Web/JavaScript and Hybrid/Cordova. If we are
using the same exact code (aerogear.js) then my first thought is just to combine that
under JavaScript (which I think is your suggestion?). If the code is similar, but
different between Web and Hybrid then it may be useful to clearly define the differences.
As a Cordova developer, I'm not a hardcore Java or Objective-C developer. So my first
thought is to find a plugin. If that doesn't exist, I'm looking for JavaScript. I
want the fastest route (aka the least amount of coding) to integrating 3rd party tools and
making it work for both Android and iOS apps.
Example 1: AeroGear push notification, I used the plugin.
Example 2: Count.ly mobile analytics, I use the community Countly SDK JS because there is
no plugin: https://github.com/Countly/countly-sdk-js
I hope this helps. I do really love the new look and feel of the mockups. Very clean!
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:47 p.m.
Makes sense to me. I think the current site does confuse me a bit...
what's the difference between Web/JavaScript and Hybrid/Cordova. If we are using the
same exact code (aerogear.js) then my first thought is just to combine that under
JavaScript (which I think is your suggestion?). If the code is similar, but different
between Web and Hybrid then it may be useful to clearly define the differences.
It’s a bit complex to explain and on the current site it’s not clear I agree. Not all
functionality that is in the Javascript project is available in Cordova and the
functionality that is has a different api. So a developer that will target Cordova will
probably end up using both.
The reason that only some parts of the Javascript have been put into Cordova is that for
those parts it makes sense to use native hardware because of security, speed or
integration, in other cases it doesn’t bring enough benefit.
Because of the way Cordova plugins work it has not always been possible to have the same
API although they are close most of the time.
Hope this helps explain things a bit more.
Erik Jan
4:56 p.m.
----- Original Message -----
From: "Erik Jan de Wit" <edewit(a)redhat.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Tuesday, March 4, 2014 10:47:12 AM
Subject: Re: [aerogear-dev] AeroGear project structure and the website
> Makes sense to me. I think the current site does confuse me a
bit... what's
> the difference between Web/JavaScript and Hybrid/Cordova. If we are using
> the same exact code (aerogear.js) then my first thought is just to combine
> that under JavaScript (which I think is your suggestion?). If the code is
> similar, but different between Web and Hybrid then it may be useful to
> clearly define the differences.
It’s a bit complex to explain and on the current site it’s not clear
I agree.
Not all functionality that is in the Javascript project is available in
Cordova and the functionality that is has a different api. So a developer
that will target Cordova will probably end up using both.
The reason that only some parts of the Javascript have been put into
Cordova
is that for those parts it makes sense to use native hardware because of
security, speed or integration, in other cases it doesn’t bring enough
benefit.
Because of the way Cordova plugins work it has not always been
possible to
have the same API although they are close most of the time.
Hope this helps explain things a bit more.
Thanks. This does
help alot
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:34 p.m.
On 04/03/2014 16:29, Lee Graham wrote:
------------------------------------------------------------------------
*From: *"Hylke Bons" <hbons(a)redhat.com>
*To: *aerogear-dev(a)lists.jboss.org
*Sent: *Tuesday, February 25, 2014 12:43:27 PM
*Subject: *Re: [aerogear-dev] AeroGear project structure and the
website
On 24/02/2014 14:50, Lee Graham wrote:
> So If I'm a Cordova developer and I want to learn how-to setup
> UnifiedPush Server and integrate Push within my hybrid app I don't
> care about the native Android & iOS libraries, guides, etc.. I just
> want everything that is relevant to hybrid apps. I actually ran
into
> this exact issue this last weekend when I created my first push
> notification app. Its hard to keep track of what guides and sample
> code I needed. This may solve that. I kind of like the way
> http://devcenter.kinvey.com/ does this. When I first go there it
> allows me to select my dev platform and it sets a cookie so when I
> come back its still on that platform. I can swap at any time,
but as a
> developer I really liked the Kinvey experience because I could find
> what I needed. Nothing more nothing less.
Cordova is a bit of a special case. Apart from a mention that
Cordova is
a supported platform on the front page, I'm not quite if we should
have
it as a mention for every feature, as we already have Javascript
there.
We need to find out how Corodova developers normally go about picking
libraries that they want to use. I assume they can use any Javascript
library? Perhaps we just add a note to the download page that for use
with Cordova you case use the Javascript library and download a
native
plugin if needed.
Makes sense to me. I think the current site does confuse me a bit...
what's the difference between Web/JavaScript and Hybrid/Cordova. If we
are using the same exact code (aerogear.js) then my first thought is
just to combine that under JavaScript (which I think is your
suggestion?). If the code is similar, but different between Web and
Hybrid then it may be useful to clearly define the differences.
As a Cordova developer, I'm not a hardcore Java or Objective-C
developer. So my first thought is to find a plugin. If that doesn't
exist, I'm looking for JavaScript. I want the fastest route (aka the
least amount of coding) to integrating 3rd party tools and making it
work for both Android and iOS apps.
Example 1: AeroGear push notification, I used the plugin.
Example 2: Count.ly mobile analytics, I use the community Countly SDK
JS because there is no plugin: https://github.com/Countly/countly-sdk-js
I hope this helps. I do really love the new look and feel of the
mockups. Very clean!
Thanks Lee, that's a useful feedback. I'll have a look at more sites
that have a Cordova offering.
Hylke
Hylke
_______________________________________________
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
6:38 p.m.
On 24/02/2014 14:16, Jay Balunas wrote:
>>
>> TL;DR: The most important questions that we need to answer are
>> these:
>> - "If I download a library on one platform, what must I download
>> to use
>> the same features on an other platform?"
I like this approach. I'd rather be feature driven than library
driven. I think most yours will be looking for what we can do for
them before looking at what native libs we provide.
Lets get this breakdown together for Hylke - using the eitherpad or a
gist seems the best approach here.
Yep, please feel free to edit the document:
http://oksoclap.com/p/AeroGearModuleUntangling
The solutions part of it is mostly brainstorming on my side. I'd love to
hear which bits are ok and which aren't and why (technical reasons, or
something constraints).
I saw in the "Small libs" thread started by Corinne that one of the
reasons why most libraries were split up was because of space savings
when building the mobile app. This could drive the decision on this as
well. The most important thing is that we get more consistency around
the downloads whichever solution we might pick.
>> -"Is this a part I use on the client, or on the server
side?”
>
> Not sure if I understood your question correctly, but to get the full
> solution, you need to download both
I think he means for each feature is there a client and a server part
and if so how do we offer them. Then we can get the info and links
for the solution in one place. Hylke - is that it or something else?
Yes, exactly. We should make it instantly clear which part of the
project a developer is dealing (Core/Push/Security/Sync and
Client/Server) with just by looking the component name. I've provided
some examples in the above document on how this could be done.
Thanks, and good to know that it's a step in the right direction!
Hylke
3:33 p.m.
On Feb 20, 2014, at 12:06 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hylke amazing work, I can’t wait to see it in production.
+1 Hylke - good stuff, and a lot to get through!
--
abstractj
On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons(a)redhat.com) wrote:
>
> TL;DR: The most important questions that we need to answer are
> these:
> - "If I download a library on one platform, what must I download
> to use
> the same features on an other platform?"
I like this approach. I'd rather be feature driven than library driven. I think most
yours will be looking for what we can do for them before looking at what native libs we
provide.
Lets get this breakdown together for Hylke - using the eitherpad or a gist seems the best
approach here.
> -"Is this a part I use on the client, or on the server
side?”
Not sure if I understood your question correctly, but to get the full solution, you need
to download both
I think he means for each feature is there a client and a server part and if so how do we
offer them. Then we can get the info and links for the solution in one place. Hylke - is
that it or something else?
> -"What do we mean when talking about different AeroGear
> subprojects/modules?”
By subprojects I understand as exactly like you did at
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/....
>
> One solution might be:
>
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
> I've made a lot of assumptions here, and it might not work, but
> I'd like
> to hear your thoughts on it.
>
> It would clarify a lot if we could harmonise the different downloads
> across platforms, either by providing single download solutions
> or
> splitting everything up and naming all the parts consistently.
> I'm
> interested in what the technical issues might be, as I wasn't
> around
> when most of these decisions were made, or I simply missed them.
>
> Thoughts or other ideas? :)
I don’t have any idea, because I liked the way how it was organized. No disagreement
here.
+1 keep up the good work!
>
> Thanks,
>
> Hylke
> _______________________________________________
> 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
3:51 p.m.
On Mon, Feb 24, 2014 at 3:33 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
On Feb 20, 2014, at 12:06 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hylke amazing work, I can't wait to see it in production.
+1 Hylke - good stuff, and a lot to get through!
it looks brilliant!
--
abstractj
On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons(a)redhat.com) wrote:
TL;DR: The most important questions that we need to answer are
these:
- "If I download a library on one platform, what must I download
to use
the same features on an other platform?"
I like this approach. I'd rather be feature driven than library driven.
I think most yours will be looking for what we can do for them before
looking at what native libs we provide.
Not sure - I guess both;
If I need a sync client, I ususally have a client platform already in mind,
rather than just looking for sync.
I'd be looking for "iOS sync"
Lets get this breakdown together for Hylke - using the eitherpad or a gist
seems the best approach here.
-"Is this a part I use on the client, or on the server side?"
Not sure if I understood your question correctly, but to get the full
solution, you need to download both
I think he means for each feature is there a client and a server part and
if so how do we offer them. Then we can get the info and links for the
solution in one place. Hylke - is that it or something else?
-"What do we mean when talking about different AeroGear
subprojects/modules?"
By subprojects I understand as exactly like you did at
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
.
One solution might be:
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
I've made a lot of assumptions here, and it might not work, but
I'd like
to hear your thoughts on it.
It would clarify a lot if we could harmonise the different downloads
across platforms, either by providing single download solutions
or
splitting everything up and naming all the parts consistently.
I'm
interested in what the technical issues might be, as I wasn't
around
when most of these decisions were made, or I simply missed them.
Thoughts or other ideas? :)
I don't have any idea, because I liked the way how it was organized. No
disagreement here.
+1 keep up the good work!
Thanks,
Hylke
_______________________________________________
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
6:48 p.m.
On 24/02/2014 14:51, Matthias Wessendorf wrote:
I like this approach. I'd rather be feature driven than library
driven. I think most yours will be looking for what we can do for
them before looking at what native libs we provide.
Not sure - I guess both;
If I need a sync client, I ususally have a client platform already in
mind, rather than just looking for sync.
I'd be looking for "iOS sync"
I can see what you mean, but the main reason you're on the website is
that you want to sync, you don't want "to iOS". :)
In the full website mockup we have platform pictures just above the use
case list that I linked to, so that visitors will know that these
features apply to Android/iOS/JS/Cordova similar to the current site
(just more pretty :), it's not like we're completely leaving the
platforms out of the picture.
Hylke
3702
days inactive
3717
days old
12 comments
7 participants
participants (7)
-
Bruno Oliveira -
Erik Jan de Wit -
Hylke Bons -
Jay Balunas -
Jay Balunas -
Lee Graham -
Matthias Wessendorf