serial numbers on standalones

[Anthony Howe]

Hiya Jacqueline,

As far as my understanding goes, it's like this:

1. libURL looks after any internet requests from an LC app to an internet server and has basic support for manual proxy configuration via the HTTPProxy function. e.g. "set the HTTPProxy to "127.0.0.0:80""

However, a lot of user computer connections to proxy servers we're experiencing these days are configured via .pac files - which is basically a file on the local subnet that 'points to' the correct proxy settings - allowing for a 'lookup' sequence to occur. Sometimes the .pac config also triggers system level authentication before providing full access to the requesting app.

.pac file configuration is actually much better, as it allows auto lookup of proxy details on the host computer which shields the user from having to : 

	a. know what a proxy server is in the first place
	b. know how to configure it, and 
	c. what the details actually are for their specific situation

..... if the user machines are NOT configured, via .pac files, they usually require the user to manually enter proxy server details into software that requires access. 

The ideal user experience of course, is complete invisibility of all this.

Sometimes, both methods are available. We are finding that the manual configuration method is being 'phased out' in the schools we are shipping to due to the onset of iPads that are more easily configured by .pac method.

2. LC / libURL support is OK, for manual configuration, after which point, all internet requests are sent via that method. All sounds easy enough right?

The gotchya is, that LC does NOT currently have the capability to query a .pac file configuration at the system level, and therefore auto-populate the httpproxy details. So, users are immediately locked into scenario outlined in point 1 above.

In addition, there are significant anomalies with how the http proxy function and/or subsequent file up/downloads work on mac/win when met with the myriad of different proxy server software that exists in different organisations in an authentication session.

We have launched into a nation wide distribution with internet dependant features, and have found considerable variance with basic connectivity support in the app when using these functions. Our users are not avid computer users, and are now having to fill out multiple forms before being able to use the software for the first time. It's a big hurdle for most of them.... and that's when everythings actually working!

Eventually, it all gets up and running, but our support queue is usually running at capacity, and it's rarely to do with our actual software, and almost ALWAYS to do with the proxy support or configuration process.

I would recommend:

1. Putting a LOT of thought and execution into your startup UX to ensure maximum simplicity and timing of events that are likely when a user starts up the software in a proxied environment. Error messaging, progress bars, simple, visually comfortable forms to fill out...etc...

2. Researching and testing as many different proxy configurations with your resultant model to check for variance / timeouts etc..

3. Making friends with a few experts in the IT departments of organisations you're shipping to so that testing is even possible. An internal test server just doesn't cut it.

4. Keeping an eye on .pac support process for LC (Trevor DV has already been down this path with the GLX App framework, but it's yet to appear anywhere else, including LC proper)

BOTTOM LINE, any internet dependent software running in an organisation is HEAVILY dependent on the whims of the IT team(s) controlling the network configuration it's running in. 

As developers in LC, we are pretty much limited to what LC has in the box for proxy support. In addition, because our functionality does not run in a browser, we're subject to the usual overriding assumption in these organisational configurations that any app not 'known about' is evil. 

It'd be great to see a solid solution / external / plugin that thinks this stuff through properly emerge for us all from somewhere, the two key requirements being:

- UX optimisations / templates for developers making internet aware apps requiring user based proxy authentication - preferably with .pac and manual config workflows covered

- Addressing the myriad of variables that exist across MAC/WIN network configurations and the common suite of proxy servers that are likely to be encountered, some of which do NOT provide the 'standard' handshake expected, creating anomalies / errors in the connect process.

Easy huh? 

I'd love to see how other education community focussed solutions have dealt with this problem for internet dependent features and proxy support previously. We can't help wondering if we're missing something totally simple in our rather challenging process here.

Hope that sheds light.

Cheers,

A.


On 18/03/2013, at 3:33 PM, J. Landman Gay wrote:

> On 3/17/13 9:06 PM, Anthony Howe wrote:
> 
>> If you are distributing cross platform software to users inside
>> organisations that use firewalls and proxy servers, and then intend
>> to attach an internet based registration service to your product,
>> using LiveCode as the underlying application engine do it, I strongly
>> suggest signing up for a life membership to your nearest acupuncture,
>> remedial massage, and zen meditation centre as quickly as possible.
> 
> Could you say a little more about the problems you had? I don't want to hit the same wall.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode