Maybe that's another way of looking at it. It's introducing network related issues when we should be concentrating on building the app that has nothing to do with network, right?
> That is definitely very true. But in this day and age of html5 boilerplate, > twitter bootstrap, jquery, etc. this particular problem can be considered > well under control. IMO, you can never trust the user system too much. It is a possible case that the user system doesn't have a browser installed, right? What'd happen then? Any fallback mechanism? On Saturday 28 September 2013 12:04:40 AM IST, Gopalakrishnan Subramani wrote: > I have spent 10+ years of Desktop app development using VC++/.NET, mostly > on Windows. After Windows XP SP 3 onwards, Microsoft changed the > application installation and execution architecture, specifically the > socket servers, firewall, administrator rights etc. > > We have WCF Web Service (part of MS .NET framework), which was running on > TCP/IP, we have so much of trouble when users install application on their > machines. > > Basic issues are listed here, which are difficult for common users to deal. > > 1. Anti-virus apps block the socket/outgoing emails/application altogether > 2. Firewall blocks the binding to port, incoming/outgoing connections. > 3. End user shall not have admin rights to install/run the server > applications that especially binds to socket server. > 4. Socket port number could have been bind by other process, so we get > port bind exceptions. > > None of above are not part of our application, but affected by external > world. Situation is completely based on what user had before, what is there > right now, what he/she might have later. > > On Windows, we use WCF Named Pipe binding now. No more socket related > issues. During installation, we install our server as Windows Service with > admin rights which uses named pipe (using GUID + some strong identity > options for naming pipe). > > -- > > Krish > > > > > > > > > > On Fri, Sep 27, 2013 at 10:20 PM, Dhananjay Nene > <dhananjay.n...@gmail.com>wrote: > >> On Fri, Sep 27, 2013 at 10:04 PM, Sriram Karra <karra....@gmail.com> >> wrote: >>> On Fri, Sep 27, 2013 at 8:55 PM, Dhananjay Nene < >> dhananjay.n...@gmail.com>wrote: >>> >>> >>>> >>>> In most cases I find users want a installer. Basically just point and >>>> click. So if there is no installer where a user selects a install >>>> directory and presses a button called install (and perhaps a couple of >>>> app specific items), there's a huge support cost due to users being >>>> not able to install apps successfully. I presume what you mean by a >>>> standard python application, but if it means a user having to install >>>> python if not installed, create a virtualenv, run pip install, create >>>> desktop shortcuts to start / stop servers, in most cases it is very >>>> very unlikely to work with lay end users. (Much of this applies to >>>> desktop based apps as well). >>>> >>> >>> >>> None of that pip/virtualenv stuff is required. There are tools available >>> that can convert a python application into a native executable - py2exe >> for >>> windows, and py2app mac, for. e.g. Once you have the native, self >> contained >>> executables, they can be wrapped into a msi or dmg package like any other >>> native application. >>> >> Ok. I haven't tried them myself ever :( Though usually there's more >> required during installation (eg. where does the program get installed >> what directory should data go to etc. Not sure if these get addressed >> by these. Perhaps there are standard python ways to deal with all such >> issues that I am unaware of. >> >>> When I said the embedded webapp is like any other python application I >>> wanted to say that the above packaging options area available for a >> webapp >>> as well - because all the code is pure python and is completely self >>> contained. I hope that was clear. >>> >> It wasn't to me, but that could be my shortcoming. >>> >>>> >>>>> I have not done this. The invocation is explicitly on demand. It is >>>> trivial >>>>> to protect against multiple invocations of the program, and to >> support a >>>>> 'Exit Program' action on the front end that will shut down the web >>>> server. >>>> >>>> Ok. I've never tried this. Perhaps it is trivial. But shutting down a >>>> server even as the controller is processing a request may >>>> "potentially" be hard. Perhaps one could set a timeout to allow the >>>> request to complete and then trigger a shutdown. >>>> >>> >>> >>> You should definitely fire up the PRS program below, and look at how the >>> shutdown action is triggered and handled in the controller. My guess is >> you >>> will find it very straightforward. >>> >> Ok. >>> >>> >>>>> >>>>> It is as easy as any other program. To give you an example, take a >> look >>>> at >>>>> a sample: https://github.com/skarra/PRS >>>> >>>> Ok, I am not particularly familiar with how the windows integration >>>> works so am not able to quickly figure it out. >>>> >>> >>> >>> There is no windows integration of any sort here. If you are using python >>> on Windows already, just clone that repo and double click on the file >>> called prs.pyw -> that is all you need to start the program. >>> >> Haven't used windows in ages :( >>> >>> >>>> The difficulty is that the user may have multiple versions of python >>>> installed and/or his default version may not be compatible with the >>>> one you want. Plus virtualenv specific for your app will need to be >>>> configured. >>>> >>> >>> >>> As explained above, the py2exe / py2app type programs are able to make >>> completely self contained native executables. >>> >>> >>>> >>>> You did mention reusable code. Service integration, system tray >>>> integration etc. are all cross platform issues that are introduced >>>> when you install a web app on a desktop >>> >>> >>> >>> I do not know if there are any cross-platform python libraries that take >>> care of issues such as this. I will only say that the webapp approach to >>> cross-platform UI programming does not put you at any greater >> disadvantage >>> than using a UI toolkit. Remember the original topic was discussion on UI >>> toolkits! >>> >> My point was that service and system tray integration are usually not >> required for desktop apps. But if your webapp is going to be >> explicitly started and stopped by user, it may not be required by such >> webapps as well. >>> >>> You also open yourself up to cross browser portability issues. Also >>>> having to deal with older vs newer browsers (IE6??). Which if you were >>>> using a standard widget library wouldn't have worried you. >>>> >>> >>> >>> That is definitely very true. But in this day and age of html5 >> boilerplate, >>> twitter bootstrap, jquery, etc. this particular problem can be considered >>> well under control. >>> >>> >>>> >>>> At the minimum you have an open port. You probably need to restrict >>>> traffic only from localhost. >>> >>> >>> >>> Yes, and this is done very easily, I am sure agree. >> Yes. >>> >>> >>>> In addition you need to worry about SQL >>>> injection, XSS, XSRF, and a bunch of other alphabet soup combinations. >>>> >>> >>> >>> I would image these are all non-issues if you reject all connections not >>> from localhost as discussed above? >> I am afraid not. >>> >>> >>> I don't mean to suggest it is wrong or inappropriate to use webapps as >>>> desktop apps. But just wanted to point out there are a whole bunch of >>>> counter issues as well that need to be dealt with. >>>> >>> >>> >>> Absolutely. It is definitely constructive and instructive to think about >>> all angles - even if just to understand the limits of a given approach. >>> Thank you for this conversation. >> The pleasure's mutual. I learnt a few things along the way. >> >> Dhananjay >> _______________________________________________ >> BangPypers mailing list >> BangPypers@python.org >> https://mail.python.org/mailman/listinfo/bangpypers >> > _______________________________________________ > BangPypers mailing list > BangPypers@python.org > https://mail.python.org/mailman/listinfo/bangpypers _______________________________________________ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
