This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
* The Winged Monkey server would register a Twitter account, with protected tweets.
* A user would install and run the Winged Monkey phone app. The first run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
* Thereafter Winged Monkey and the phone app use tweets to communicate over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
* The communications are authenticated, with access permission which can be very quickly revoked by unfollowing an account which is no longer supported.
* The communications are also (moderately) secure, in the sense that tweets from and between protected accounts aren’t generally readable.
* The timelines of the accounts constitute an audit history of events etc.. It would be trivial to scrape that audit history from Twitter if required.
* The principle benefit, though, is that the requirement for the Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
Personally I love the idea you propose and the idea creating a native app obviously is really interesting to me from a design perspective. I don't think it eliminates the need for a mobile-ready web UI, and fortunately, it won't be a huge leap to make what we have now responsive.
What about using SMS? I have no idea what this entails server side, but it would be a natural way to get alerts, or for example, to text STOP to your application. Good ol' email works too. I actually think email would be useful in other situations, like after your app is up, you get an email confirming it is running and with connection and login details, etc. You might also want a reminder email if your app has been running for a month with no activity.
That all said, I think the ability to receive alerts over any internet connection is more important than being able to poll for status or perform operations. Of course, I want both!
Jeremy
On Jan 31, 2013, at 2:23 PM, Angus Thomas athomas@redhat.com wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
The Winged Monkey server would register a Twitter account, with protected tweets.
A user would install and run the Winged Monkey phone app. The first run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
Thereafter Winged Monkey and the phone app use tweets to communicate over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
The communications are authenticated, with access permission which can be very quickly revoked by unfollowing an account which is no longer supported.
The communications are also (moderately) secure, in the sense that tweets from and between protected accounts aren’t generally readable.
The timelines of the accounts constitute an audit history of events etc.. It would be trivial to scrape that audit history from Twitter if required.
The principle benefit, though, is that the requirement for the Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 - http://developer.android.com/google/gcm/index.html 2 - https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Co...
-steve
On Jan 31, 2013, at 3:09 PM, Jeremy Perry jeperry@redhat.com wrote:
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
Personally I love the idea you propose and the idea creating a native app obviously is really interesting to me from a design perspective. I don't think it eliminates the need for a mobile-ready web UI, and fortunately, it won't be a huge leap to make what we have now responsive.
What about using SMS? I have no idea what this entails server side, but it would be a natural way to get alerts, or for example, to text STOP to your application. Good ol' email works too. I actually think email would be useful in other situations, like after your app is up, you get an email confirming it is running and with connection and login details, etc. You might also want a reminder email if your app has been running for a month with no activity.
That all said, I think the ability to receive alerts over any internet connection is more important than being able to poll for status or perform operations. Of course, I want both!
Jeremy
On Jan 31, 2013, at 2:23 PM, Angus Thomas athomas@redhat.com wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
The Winged Monkey server would register a Twitter account, with protected tweets.
A user would install and run the Winged Monkey phone app. The first run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
Thereafter Winged Monkey and the phone app use tweets to communicate over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
The communications are authenticated, with access permission which can be very quickly revoked by unfollowing an account which is no longer supported.
The communications are also (moderately) secure, in the sense that tweets from and between protected accounts aren’t generally readable.
The timelines of the accounts constitute an audit history of events etc.. It would be trivial to scrape that audit history from Twitter if required.
The principle benefit, though, is that the requirement for the Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
On Thu, Jan 31, 2013 at 03:30:51PM -0600, Steve Loranz wrote:
If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 - http://developer.android.com/google/gcm/index.html 2 - https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Co...
-steve
The native platform approach -- using the push mechanism provided by Google and/or Apple seems to be the natural choice to me.
On 01/31/2013 04:30 PM, Steve Loranz wrote:
If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 -http://developer.android.com/google/gcm/index.html 2 -https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Co...
-steve
Thanks Steve,
As the saying goes, Ask a silly question, get a concise, precise, correct answer.
On reflection, it isn't much of a surprise that this is a solved problem with the native toolsets. This would be the way to do it.
Angus
On 01/02/13 02:56 PM, Angus Thomas wrote:
On 01/31/2013 04:30 PM, Steve Loranz wrote:
If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 -http://developer.android.com/google/gcm/index.html 2 -https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Co...
-steve
Thanks Steve,
As the saying goes, Ask a silly question, get a concise, precise, correct answer.
On reflection, it isn't much of a surprise that this is a solved problem with the native toolsets. This would be the way to do it.
Angus
I second the native notification approach. Another alternative to twitter - email. -d
On 1.2.2013 15:56, Angus Thomas wrote:
On 01/31/2013 04:30 PM, Steve Loranz wrote:
If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 -http://developer.android.com/google/gcm/index.html 2 -https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Co...
-steve
Thanks Steve,
As the saying goes, Ask a silly question, get a concise, precise, correct answer.
On reflection, it isn't much of a surprise that this is a solved problem with the native toolsets. This would be the way to do it.
And I also think, that it is not just about push notifications, but also about connectivity and usage of WM outside protected networks. If I got that right, Angus was trying to suggest, that once user gets outside the protected network, whole communication between mobile WM and server, where WM runs, can be managed via tweets.
Angus
-- Jarda
On 01/31/2013 09:09 PM, Jeremy Perry wrote:
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
This sounds awesome. I can envision many mobile applications that consume various services offered by Aeolus. Having something like "mobile-converge-ui" would be really fantastic (proving we choose to go down the html5, css3, js route, which I would recommend).
I wonder how much work converting our current converge-ui to target mobile devices would be.
Regards
Martyn
Personally I love the idea you propose and the idea creating a native app obviously is really interesting to me from a design perspective. I don't think it eliminates the need for a mobile-ready web UI, and fortunately, it won't be a huge leap to make what we have now responsive.
What about using SMS? I have no idea what this entails server side, but it would be a natural way to get alerts, or for example, to text STOP to your application. Good ol' email works too. I actually think email would be useful in other situations, like after your app is up, you get an email confirming it is running and with connection and login details, etc. You might also want a reminder email if your app has been running for a month with no activity.
That all said, I think the ability to receive alerts over any internet connection is more important than being able to poll for status or perform operations. Of course, I want both!
Jeremy
On Jan 31, 2013, at 2:23 PM, Angus Thomas athomas@redhat.com wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
The Winged Monkey server would register a Twitter account, with protected tweets.
A user would install and run the Winged Monkey phone app. The first run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
Thereafter Winged Monkey and the phone app use tweets to communicate over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
The communications are authenticated, with access permission which can be very quickly revoked by unfollowing an account which is no longer supported.
The communications are also (moderately) secure, in the sense that tweets from and between protected accounts aren’t generally readable.
The timelines of the accounts constitute an audit history of events etc.. It would be trivial to scrape that audit history from Twitter if required.
The principle benefit, though, is that the requirement for the Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
On Fri, Feb 01, 2013 at 10:51:16AM +0000, Martyn Taylor wrote:
On 01/31/2013 09:09 PM, Jeremy Perry wrote:
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
This sounds awesome. I can envision many mobile applications that consume various services offered by Aeolus. Having something like "mobile-converge-ui" would be really fantastic (proving we choose to go down the html5, css3, js route, which I would recommend).
I wonder how much work converting our current converge-ui to target mobile devices would be.
I have a very little understanding for the idea of creating a mobile converge-ui.
We need a complete wireframe of how the conductor UI should look like, we need to fix most of the workflows in conductor and then we have the winged monkey UI to work on.
Also there are things such as Sencha Touch and other mobile web frameworks that can be used w/o reinventing the wheel.
I would love if we could concentrate more on getting things done rather than splitting forces between more and projects.
Seems to me people are sort of escaping the work on conductor and seek every opportunity to work on something else ;-)
Regards
Martyn
On 02/01/2013 02:50 PM, Martin Povolny wrote:
On Fri, Feb 01, 2013 at 10:51:16AM +0000, Martyn Taylor wrote:
On 01/31/2013 09:09 PM, Jeremy Perry wrote:
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
This sounds awesome. I can envision many mobile applications that consume various services offered by Aeolus. Having something like "mobile-converge-ui" would be really fantastic (proving we choose to go down the html5, css3, js route, which I would recommend).
I wonder how much work converting our current converge-ui to target mobile devices would be.
I have a very little understanding for the idea of creating a mobile converge-ui.
We need a complete wireframe of how the conductor UI should look like, we need to fix most of the workflows in conductor and then we have the winged monkey UI to work on.
Also there are things such as Sencha Touch and other mobile web frameworks that can be used w/o reinventing the wheel.
Thing like Sencha Touch and JQuery mobile offer libraries for creating standard elements and mobile type pages using js and html5. Converge UI is more about creating a uniform style and look and feel across projects such as Katello and Conductor and builds on top of things like standard JQuery.
I would love if we could concentrate more on getting things done rather than splitting forces between more and projects.
I would say given that we would like to create mobile applications like Jeremy and Angus suggested, then having a uniform look and feel across the many possible applications would
a) make development easier b) make it look like it fits in with the the rest of Aeolus projects, like conductor and Katello.
Seems to me people are sort of escaping the work on conductor and seek every opportunity to work on something else ;-)
I don't think anyone is escaping the work on conductor, but merely seeing the potential that our many applications can offer and suggesting possible avenues that could help better the project and develop more community interest. There are 1001 things we could be working on, conductor is one of them. But it's all about priorities, "What do real companies actually want?" If the answer is conductor and nothing else, then I agree we should put the majority of our effort there, if it's mobile applications then we should make it possible to create mobile applicaitons. The problem is that we really don't know. Hence my previous email to this thread.
6-9 month ago people were saying pulling Tim into it's own component was wasted effort. But already, it has potential to be migrated into the MIQ products. IMO Conductor is not the be all and end all of Aeolus.
Regards
Martyn
On Fri, Feb 01, 2013 at 03:02:18PM +0000, Martyn Taylor wrote:
On 02/01/2013 02:50 PM, Martin Povolny wrote:
Also there are things such as Sencha Touch and other mobile web frameworks that can be used w/o reinventing the wheel.
Thing like Sencha Touch and JQuery mobile offer libraries for creating standard elements and mobile type pages using js and html5. converge ui is more about creating a uniform style and look and feel across projects such as katello and conductor and builds on top of things like standard jquery.
Sorry Martyn but what you are writing is simply not true.
Sencha Touch [1] and JQuery mobile [2] are libraries that provide (beside other benefits) a set of mobile-optimised components -- optimized and tested on/for small devices.
These can be compared to Sencha ExtJS and SmartClient in the desktop web world.
Your description "offer libraries for creating standard elements" fits to plain JQuery, Sencha ExtJS Core and other libraries.
To get a uniform look and feel, you can use the theming capabilities of JQuery Mobile and/or Sencha Touch. Both seem to be strong in this aspect.
Also worth attention is the fact that while mobile web framework generally use JavaScript a lot, Alchemy (Converge UI) tries to work w/o JavaScript which might be seen as swimming against the stream on mobile platforms.
With all respect to Alchemy, to support the mobile web in the way comparable to JQuery Mobile and Sencha Touch a huge effort would be needed.
This is just to get facts right before jumping into something.
I would love if we could concentrate more on getting things done rather than splitting forces between more and projects.
I would say given that we would like to create mobile applications like Jeremy and Angus suggested, then having a uniform look and feel across the many possible applications would
a) make development easier b) make it look like it fits in with the the rest of Aeolus projects, like conductor and Katello.
That is surely true. But writing own mobile web toolkit is IMHO not the way to get there in a reasonable time with a justifiable effort.
We should pick an existing solution and just style it to fit our would-like-to-have uniform look and feel.
[1] http://cdn.sencha.io/touch/sencha-touch-2.1.0/examples/kitchensink/index.htm... [2] http://jquerymobile.com/demos/1.2.0/docs/about/features.html
On 4.2.2013 09:28, Martin Povolny wrote:
With all respect to Alchemy, to support the mobile web in the way comparable to JQuery Mobile and Sencha Touch a huge effort would be needed.
+1 here.
I already told Jarda directly, but never wrote it to the list because the topic was never brought up before:
I think that if we make Alchemy an alternative to Twitter Bootstrap or JQuery Mobile, rather than a plugin for one of them, Alchemy won't get much traction upstream. Given the development power assigned for Alchemy, I don't think we'll be able to provide a compelling alternative to those frameworks, nor would I see the point of focusing our effort to this area. We'll keep solving the same problems that others already solve and they have much more dev power to do so. If using Alchemy means that you can't use it with one of the major frameworks, then I don't think Alchemy will make much success upstream. I think people will not want to jump the ship of Twitter Bootstrap or JQuery Mobile or Sencha Touch for Alchemy.
I think it would be better to make Alchemy a plugin for one of those frameworks, even if it means making compromises in some areas. We won't compete with existing huge communities, we'll go along with them. Also we'll be able to benefit from their solutions instead of hitting the same issues and spending our own time to solve them.
That's just my 2 cents, I don't mean to push this opinion violently, but I felt that I should say it :)
J.
On 02/04/2013 08:28 AM, Martin Povolny wrote:
On Fri, Feb 01, 2013 at 03:02:18PM +0000, Martyn Taylor wrote:
On 02/01/2013 02:50 PM, Martin Povolny wrote:
Also there are things such as Sencha Touch and other mobile web frameworks that can be used w/o reinventing the wheel.
Thing like Sencha Touch and JQuery mobile offer libraries for creating standard elements and mobile type pages using js and html5. converge ui is more about creating a uniform style and look and feel across projects such as katello and conductor and builds on top of things like standard jquery.
Sorry Martyn but what you are writing is simply not true.
Sencha Touch [1] and JQuery mobile [2] are libraries that provide (beside other benefits) a set of mobile-optimised components -- optimized and tested on/for small devices.
I can not see how what you suggested and what I said is different. My point is that Converge-UI stemmed from the need to create a consistent look and feel across Aeolus projects, having this extend to mobile applications imo would be useful. It could well be that the best approach to implement this is to create a theme or something else that utilizes the two libraries you suggest or do what Jaromir suggested and use responsive web design, the point is that simply using one of these libraries is not going to solve the problem.
I can say that I know different developers that have chosen to use both approaches suggested in this thread, i.e. building a JQuery mobile app with custom themes or use a responsive approach like Jaromir suggested.
From my experience I can say that I found that beyond simple styling I
found customisation of JQuery mobile elements particularly complex.
These can be compared to Sencha ExtJS and SmartClient in the desktop web world.
Your description "offer libraries for creating standard elements" fits to plain JQuery, Sencha ExtJS Core and other libraries.
To get a uniform look and feel, you can use the theming capabilities of JQuery Mobile and/or Sencha Touch. Both seem to be strong in this aspect.
Also worth attention is the fact that while mobile web framework generally use JavaScript a lot, Alchemy (Converge UI) tries to work w/o JavaScript which might be seen as swimming against the stream on mobile platforms.
With all respect to Alchemy, to support the mobile web in the way comparable to JQuery Mobile and Sencha Touch a huge effort would be needed.
This is just to get facts right before jumping into something.
I think it is you that jumped into something, it seems with both feet. I merely asked: "I wonder how much work converting our current converge-ui to target mobile devices would be. Telling someone to "Get their facts right" is where I am from rather insulting. I can only assume that this does not quite translate properly. However, I feel this is actually leading to nothing, so I shall remove myself from this conversation.
I would love if we could concentrate more on getting things done rather than splitting forces between more and projects.
I would say given that we would like to create mobile applications like Jeremy and Angus suggested, then having a uniform look and feel across the many possible applications would
a) make development easier b) make it look like it fits in with the the rest of Aeolus projects, like conductor and Katello.
That is surely true. But writing own mobile web toolkit is IMHO not the way to get there in a reasonable time with a justifiable effort.
We should pick an existing solution and just style it to fit our would-like-to-have uniform look and feel.
[1] http://cdn.sencha.io/touch/sencha-touch-2.1.0/examples/kitchensink/index.htm... [2] http://jquerymobile.com/demos/1.2.0/docs/about/features.html
On Tue, Feb 05, 2013 at 11:42:06AM +0000, Martyn Taylor wrote:
On 02/04/2013 08:28 AM, Martin Povolny wrote:
On Fri, Feb 01, 2013 at 03:02:18PM +0000, Martyn Taylor wrote:
On 02/01/2013 02:50 PM, Martin Povolny wrote:
Also there are things such as Sencha Touch and other mobile web frameworks that can be used w/o reinventing the wheel.
Thing like Sencha Touch and JQuery mobile offer libraries for creating standard elements and mobile type pages using js and html5. converge ui is more about creating a uniform style and look and feel across projects such as katello and conductor and builds on top of things like standard jquery.
Sorry Martyn but what you are writing is simply not true.
Sencha Touch [1] and JQuery mobile [2] are libraries that provide (beside other benefits) a set of mobile-optimised components -- optimized and tested on/for small devices.
I can not see how what you suggested and what I said is different. My point is that Converge-UI stemmed from the need to create a consistent look and feel across Aeolus projects, having this extend to mobile applications imo would be useful. It could well be that the best approach to implement this is to create a theme or something else that utilizes the two libraries you suggest or do what Jaromir suggested and use responsive web design, the point is that simply using one of these libraries is not going to solve the problem.
Sorry Martyn did not mean to offend you.
But I think that the difference between:
"Sencha Touch and JQuery mobile offer libraries for creating standard elements"
and
"Sencha Touch and JQuery mobile provide libraries of standard elements".
is months or years of work. And my only intention was to point out this difference.
Sorry again for giving you the feeling of being insulted.
Thanks Martyn, this is really good point, if you don't mind, my answer is within your text.
On 1.2.2013 11:51, Martyn Taylor wrote:
On 01/31/2013 09:09 PM, Jeremy Perry wrote:
This is really cool Angus. From the beginning we have known that mobile and alerts is naturally important to WM -- It's suggested in the original wireframes. The interface we've been building has been designed with mobile in mind - though we had not considered the connection issue you point out. Anyhow, Jarda has some awesome wires to share soon that show how a responsive front end will give us an optimized experience mobile phones, at least while on the same network.
This sounds awesome. I can envision many mobile applications that consume various services offered by Aeolus. Having something like "mobile-converge-ui" would be really fantastic (proving we choose to go down the html5, css3, js route, which I would recommend).
I wonder how much work converting our current converge-ui to target mobile devices would be.
As for alchemy (or previously named converge-ui), we are trying to have everything in responsive webdesign, so just by recognizing device width, components will auto-adapt. And we definitely want to keep this approach, for new added features, that everything what comes into alchemy, works at mobile phones as well. Unfortunately we are not supporting all composites yet (talking about login), but we are heading mobile direction as well.
Regards
Martyn
[snip]
Interesting proposal Angus. Though I think this does detract a little from some of the benefits of providing REST interfaces for all our components. One of the cool things about REST is how easy it is a to consume by clients like mobile applications.
Though, like you said it maybe that companies do not want to expose direct access to internal running services. This was something that Lutter highlighted in one of his replies to the messaging thread. What I really think we are lacking when making many decisions in this project is a real understanding of the real world. In this case, i think we could better make architectural/design decisions if we have some information on our target audience/customers. In this for case for example, it would be extremely helpful to know what percentage of customers behave as you described below?
We must have a wealth of knowledge about real paying customers given RedHats large customer base and I think we need to start using it. As a developer with little/no on-site experience, I can only make best guesses as to what we feel customers require. Are you aware of any form of channel at RedHat that we can go through to get this sort of information? If we had a target audience/customer profile, it would make these decisions much more straight forward, and I think we'd actually end up with a project/product that people actually want.
What are your thoughts?
Regards
Martyn
On 01/31/2013 07:23 PM, Angus Thomas wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
- The Winged Monkey server would register a Twitter account, with
protected tweets.
- A user would install and run the Winged Monkey phone app. The first
run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
- Thereafter Winged Monkey and the phone app use tweets to communicate
over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
- The communications are authenticated, with access permission which
can be very quickly revoked by unfollowing an account which is no longer supported.
- The communications are also (moderately) secure, in the sense that
tweets from and between protected accounts aren’t generally readable.
- The timelines of the accounts constitute an audit history of events
etc.. It would be trivial to scrape that audit history from Twitter if required.
- The principle benefit, though, is that the requirement for the
Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
+1, For me it sounds like a good approach. If there are no restrictions from Twitter's side... I like it.
I might be little bit concerned about one thing: Once Twitter changes their policy or somehow cuts us from using this approach, we can't provide such feature anymore. And this means taking something from users, what we already provided them. This definitely will make whole bunch of users very angry and disappointed and we might lose them. So maybe something like backup plan, if this case happens that we can deal with that, might be sufficient.
-- Jarda
On 31.1.2013 20:23, Angus Thomas wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
- The Winged Monkey server would register a Twitter account, with
protected tweets.
- A user would install and run the Winged Monkey phone app. The first
run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
- Thereafter Winged Monkey and the phone app use tweets to communicate
over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
- The communications are authenticated, with access permission which
can be very quickly revoked by unfollowing an account which is no longer supported.
- The communications are also (moderately) secure, in the sense that
tweets from and between protected accounts aren’t generally readable.
- The timelines of the accounts constitute an audit history of events
etc.. It would be trivial to scrape that audit history from Twitter if required.
- The principle benefit, though, is that the requirement for the
Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
On Thu, Jan 31, 2013 at 02:23:36PM -0500, Angus Thomas wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
I think that trying to use Twitter as a messaging conduit is novel, but I'm not sure it's really the right solution. (That said, the proposal was an excellent way to get us proposing other ideas.)
For mobile clients, I think the idea of using native push-messaging is a good one.
For non-mobile clients, I would argue that it's not quite our problem to solve. As a system administrator, I feel like I'd either have set up remote access functionality, or I'd be quite uncomfortable with the idea of a tool sharing my data outside of the means I set up.
The more I think about this, though, the more I abstract 'Twitter' into just any old message service hosted in the cloud. Much in the same way the Audrey will launch a purpose-built config server in your cloud, we could do the same with a notification service in the cloud if needed. That way the data would remain (as much as anything else in the cloud) in the user's control.
Though I still suspect that, although it's an interesting problem that our customers may have, it's not directly related to our app. (By which I mean that we should try to solve it in an app-agnostic way, not that we should refuse to consider trying to solve it.) That is, how to make $onsite_app accessible to users behind a firewall, especially in a way that system and network employees would be on board with.
-- Matt
On 1.2.2013 18:19, Matt Wagner wrote:
On Thu, Jan 31, 2013 at 02:23:36PM -0500, Angus Thomas wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
I think that trying to use Twitter as a messaging conduit is novel, but I'm not sure it's really the right solution. (That said, the proposal was an excellent way to get us proposing other ideas.)
For mobile clients, I think the idea of using native push-messaging is a good one.
For non-mobile clients, I would argue that it's not quite our problem to solve. As a system administrator, I feel like I'd either have set up remote access functionality, or I'd be quite uncomfortable with the idea of a tool sharing my data outside of the means I set up.
The more I think about this, though, the more I abstract 'Twitter' into just any old message service hosted in the cloud. Much in the same way the Audrey will launch a purpose-built config server in your cloud, we could do the same with a notification service in the cloud if needed. That way the data would remain (as much as anything else in the cloud) in the user's control.
Though I still suspect that, although it's an interesting problem that our customers may have, it's not directly related to our app. (By which I mean that we should try to solve it in an app-agnostic way, not that we should refuse to consider trying to solve it.) That is, how to make $onsite_app accessible to users behind a firewall, especially in a way that system and network employees would be on board with.
-- Matt
+1
J.
On 31/01/13 20:23, Angus Thomas wrote:
This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose...
So, here’s how this could work:
- The Winged Monkey server would register a Twitter account, with
protected tweets.
- A user would install and run the Winged Monkey phone app. The first
run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other.
- Thereafter Winged Monkey and the phone app use tweets to communicate
over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users.
Some of the benefits are:
- The communications are authenticated, with access permission which can
be very quickly revoked by unfollowing an account which is no longer supported.
- The communications are also (moderately) secure, in the sense that
tweets from and between protected accounts aren’t generally readable.
- The timelines of the accounts constitute an audit history of events
etc.. It would be trivial to scrape that audit history from Twitter if required.
- The principle benefit, though, is that the requirement for the Winged
Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem.
Angus
Angus,
You're proposing we build a backdoork to our users' VPN that can be exploited by Twitter, Inc. and anyone who gains access to their infrastructure (a malicious hacker, rogue employee or the US government).
If an organisation puts Winged Monkey behind a VPN and doesn't make the UI/API available from the outside, this proposal won't fly (pardon the pun).
It seems you're trying to solve two distinct things: use an existing communication protocol between the mobile app and the server; and have a way of connecting the app to a hardened server.
For the first option, we can use a wide range of open protocols: XMPP, RSS, Atom, PubSubHubbub or the API Winged Monkey will provide. Behind SSL/TLS of course. Any of these would be fine for a mobile client and are successfully being used.
To provide push notifications to the mobile devices, we can utilise SMS, email or the native push services (as Jeremy and Steve suggested). Note that all of these rely on third-party services. They will leak potentially sensitive data to third parties. Still, it can be useful as an optional feature.
The issue of connecting to the server is orthogonal to all that. If a company doesn't want to set up a public connection point for security reasons, the game is over.
However, I could see us provide a very streamlined, simple and easily auditable service separate from the main WM/Aeolus API. This would allow only certain data and operations to flow back and forth and could be deployed instead of the full-fledged API/UI.
This is similar to running phpMyAdmin on the internal network only and having the Wordpress admin interface accessible from the outside. They can both access your internal database, but the Wordpress access is more limited. Unless there are holes in Wordpress. Hence the need for a simple and robust solution.
We (or anyone else) could even host this ourselves. That way the security implications for the company are the same as the original Twitter proposal but at least it's an open solution and they are not locked in to a single company's proprietary service.
Thomas
aeolus-devel@lists.fedorahosted.org