Noob questions

[Tamás Gulácsi]

See gowut, for example.

[Carlos Castillo]

Although I am about to say a lot, it is still only an high-level response to your questions.

1.a)

Go compiles to native binaries for a single OS/Architecture, the myapp.exe will only run on systems similar to the one you built it on.

Eg: Windows x86 (32-bit) binaries will only work on those machines, and on 64-bit x86-64 Windows machines

The portability of go is that the entire standard library (essentially everything documented on golang.org) has no platform dependencies, so most "pure-go" programs and libraries can be built to run anywhere go does without modification. The only non-portable package in the standard library is the "syscall" package, which contains the low-level system dependent types & interfaces used by the standard library to implement it's portable interface.

You still will need to build a different executable for each OS/ARCH you wish to support. Cross compiling in Go however isn't too difficult, but AFAIK it requires you to use the command line interface and source code install, as well as there are some features which can't be cross-compiled (anything using cgo). Most pure-go projects should be able to cross-compile, but it's still a good idea to build on the target environment directly, both "to be sure", as well as to be able to run tests (to be really sure).

1.b) I'm not familiar with Android enough to be able to answer about the support of Go there. The OS (android) is not an officially supported Go platform, but the hardware architecture (arm) is. On the iOS side, both the OS (darwin - ie: OSX) and the architecture are supported (arm, again), but not together, in some part due to the restrictions imposed by Apple. In the most recent version of Go (1.1) the main technical limitation was dealt with but official support is probably some time away.

I believe that the runtime environment for the Chrome OS is essentially the Chrome browser, which means no native binaries, so no Go, but I could be wrong (it is running linux underneath).

2.a)

Building a Go that serves HTTP requests fall into 3 main camps:

• Building a Go program that acts as the HTTP server, and handles all requests. This is what most of the code in the standard library is built for.
• Building a program that does the above, but has a proxy in front of it for load balancing or other services where fast or existing code is already present.
• Building a Go program that is a helper program to another server via a protocol like CGI, Fastcgi, etc... Go includes support for both CGI and FastCGI, but it requires a slightly different program design as the Go program has a different set of responsibilities and life-cycle.

If you are wanting to make a Go program to run "inside" Apache, you will probably be using the third option. The way I have done this on OSX, where apache is built-in, is to use the Apache config option ExecCGI; a tutorial to set up Apache's CGI support (not go specific) is at http://httpd.apache.org/docs/2.0/howto/cgi.html . CGI is a protocol where webserver starts up another program (in this case the go exe), and passes it the parsed request information in environment variables, and using stdin (eg: for POST data). The program then responds by writing a response to stdout. You can do this manually yourself, but the net/http/cgi provides a simple interface, nearly identical to the stand alone one, to handle the request. It uses the same net/http.Handler interface as the built-in server package so you can (mostly) use the same handlers for a stand-alone server (option 1 & 2) as for CGI. I have in-fact made a private package that can be used to build servers that can run either as a CGI program or in stand-alone mode, but it does require knowledge about how these two modes differ.

2.b) Most examples you will see are for building a go program that acts as a self-contained web-server, since it is fairly simple to do so in Go, and has had quite a lot of work done to improve it's performance w.r.t. existing web-servers. That means that there is one EXE, with nothing between it and the internet, handling all requests for data on a given network socket. This makes it very easy to build and test your apps, as nothing needs to be installed or running on the target machine for you to enter (in this case) "http://localhost:9999" into a web-browser to see the output of the program.

3.a) yes, using cmd/exec is probably the most straight-forward way to ask the OS to open a URL for you. The exact method / command differs with the OS though, but most OS's provide a utility command to open web-sites. Eg on windows, the command is "start <URL>", on Mac OS X its "open <URL>", and on Linux you can often use "xdg-open" (but I'm not 100% sure). Alternatively, if you know the path to the browser you want to use you could call it directly, but that is generally not a good idea, as it might not be the user's desired browser, and it might not exist.

3.b) The most portable way (works with non HTML5 browsers) would be to have a heartbeat request made by the page, IE: if the pages refresh every 10 seconds, then no requests for 30 seconds probably means the browser window/tab was closed. This could be done by refreshing the entire page (<meta http-equiv="refresh"...>), or by making AJAX requests. A more accurate way would be to use websockets (see: http://caniuse.com/websockets for support in modern browsers), as there is then a way for the server to know when the client closes the connection.

4) This is definitely one way to do it, and Go gives you all the pieces necessary to build the entire end-to-end process (if necessary) as it has fairly easy to use http server and client code. Also if you want to implement encryption, and / or message digests to ensure authenticated, error checked updates, those features exist in the standard library as well. Because of go's static compilation, in many cases all you'd need to transmit is a single file, and no installer needs to be run, nor does the environment need to be set up (eg: install DLL's). If you need to send app+data, you can either use multiple requests, or the built-in zip support to pack/unpack a single zip file. Again all these features have implementations in pure Go, as part of the standard library, so you have far fewer portability concerns.

On Thursday, May 30, 2013 12:37:51 PM UTC-7, Jim Ellis wrote:

I have been out of programming for the past decade.  I recently stumbled across Go and this is the first language I have seen in this past decade that has caught my interest as I think it shows the ability to create a program that can .  I like how it produces a compiled program that I believe is suppose to be able to run on different platforms, it is "c like", designed to take advantage of multi core processors, and I believe also distributed web apps.

The first "problem" I encountered is that Go does not have a user interface.  I can grasp how to create a go program to perform a task, but what caused me some conceptual problems is the gap of how to know when to perform the task and what to do with the result.

So I kept reading and looking into this issue, and I believe the answer for me is HTML5/CSS3.  Html allows for the typical user input items (text box, check box, list, button).  And after looking at the new features in html5, such as the canvas and flexbox, as well as go's ability to work with an html template, and that provides the way to show the result.  So this gives me a constructive direction to work with.

Now we get to some practical issues, which is where the questions arise as I still have some things that I have not figured out yet.

#1.  Executable file.

I have myapp.go which performs a simple task.  It is compiled into myapp.exe.

I am using Win7 on my pc with eclipse for the IDE.  Can I take the myapp.exe and run it on a mac and/or linux pc?  What about an apache web server?

This is the first test to get my eventual end program to be usable on different platforms.  I want to run it on an apache server to prepare the web site pages.  I also want a "desktop" program that will do most of the processing so the server is not over used.  (see #2 for reason of this.)

1B)  From what I understand, at this time myapp.exe will not run on Android.  So for a droid app, I would just wrap the html5 so the app could be downloaded from the google play app-store.

Is it planned to have a go program be able to run on droid?

What about the chrome os?

------

#2.  Getting the "myapp" to run on the apache web server.

I am using a hosted web site on a shared server.  

  A) What do I need to do to get the myapp.exe to run on the web server?

      Can I load it to the root directory of the web site, or even put it in a sub directory?

  B) The examples I have looked at use http.ListenAndServe("localhost:9999", nil) this won't work for the actual web site.  What should this be set to?

-----

#3.  Running on the desktop.

Because of the shared server that has limits on the use, I want to offload some of the processing to the desktop.  I can do this for both preparing the pages, and also for some computations.  The myapp would run on the desktop, pull data from the website, and then display the result in the browser that is set to work with "localhost".

As mentioned, I have used the localhost to get the myapp to work with a browser.  But I would like to integrate this a bit more.  I would like to have a shortcut that runs the myapp.exe file, and have it open the browser with the browser directed to "localhost".  

Am I correct that this can be done using the os/exec package?  (using cmd.start)

3B)  What is the best way to end the myapp program when the browser is closed?

-----

#4.  Desktop version updating.

I realized that if the os/exec package can be used to start another program, then I can create a "launcher" program.

The "launcher.exe" would be downloaded from the server and placed in a directory on the pc.

The "launcher.exe" program would be the one that has a shortcut set to it.  When ran it would check the website for the latest version of the myapp program, if needed download it from the website, and put it in the correct directory on the pc.

Then the launcher.exe would start myapp.exe.

Am I on the right track with this line of thought?

----

The answers to these questions should tie up the loose ends where I will have a better grasp on the concepts and can get to work on the details.

Thanks,

Jim.

[Jim Ellis]

I checked this thread last night and saw the reply from András Belicza about gowut.  I did not have time to look at it in-depth, but bookmarked the pages.

I had time to look at them more today, and I would like to thank Andras as that answers quite a few of the UI questions that I had.

@Carlos Castillo,

Your "high level" answers were exactly what I am looking for.  I am the type where I want to get a good grasp on the concept, 

and then I will worry about the details on how to make the concept work.

"You still will need to build a different executable for each OS/ARCH you wish to support."

I appreciate the frankness of that answer, and your explanation that went with it.  

On your answer for 2a.  I understand the first 2 camps your described.  The 3rd one I am not familiar with, so this sounds like it will be more of a learning curve for me to be able to use an apache web server for my website.

I had thought that apache ran on Linux, so after reading your first answer I thought that I would need to just build the exe for linux and it would be good.  But from what I am seeing in your second answer, it sounds like it is a bit more involved than that, so thank you for the link to the apache cgi tutorial.  

For 2B I think my question may have been confusing.  So let me restate it.

I know that to run "myapp.exe" on my pc I use localhost for the port to be listened to.

What do I use in place of that when I run the program on a web server?

Thanks for the answers on 3.  You are right, I would want to use the users default browser.  

Thanks for adding the information that each platform has a slightly different call that is needed to open the browser.  That information really helps!

Thanks for the websockets hint, that sounds like it will be the best approach.

And thanks for confirming my ideas on #4 would work.

-----------------------------------

Based on the answers I can now lay out a rough plan of action.

First thing I will do is check with my web host to see if they will let me use a windows server to test with.  If it works out well, then I will move my site to the windows server.

This would be the fastest way for me to get "up and running".  

If not, then I will take the extra time and work through that apache tutorial.

** I will need to figure out what to use in the listen command when I start the program on the server.

The first version will have a download to windows for the "desktop" version of the program.

Once I get the site and program going the way I want, then I can work on taking care of the "p"'s and "q"s to get the desktop program to work on macs and linux pc's.  This would involve taking care of platform specific commands and the compiling of the program for each platform.

Thanks for the assistance,

Jim.

[Jim Ellis]

correction to previous post.  Thanks to Tamas Gulacsi for pointing to gowut.

I think I found the answer to 2B.

I was looking at more examples and found this:

http.ListenAndServe(":8080", nil); err != nil {

Is that the proper way to set it up for when it runs on a website?

The "localhost" is only put in that line when you want to force it to use your pc.

[Carlos Castillo]

What I meant about the different camps is that you can

1. Have the Go app as the web-server (stand alone mode),
2. Have a stand alone server in go on a non-standard port, and have requests to an existing Apache server (or nginx, lighthttpd, etc...) redirect the user to that server
   
3. Have the main server (apache and friends), somehow pass the request through to a Go app, and return the response back to the user (the user only interacts with apache)

With #1, the user sees / accesses one executable (your go app), which must do all the work (handling all requests), and so you have to put the effort in to do things like serve static files (fairly simple in go), compress output to minimize traffic (a little harder), or anything else a traditional webserver might do in addition to handle HTTP requests.

With #2, you can serve a static website with Apache, and have links on pages to dynamic content be served by the go server. This means that the majority of the hits and traffic is handled by apache, but your go app is contacted when dynamic things need to be done. This often has a very small config cost, but things such as firewalls, the Same origin Policy, etc... can get in your way if you aren't too careful.

With #3, the apache server is the only online entity that users contact, but apache silently (to them) hands the work to the go app, and returns the response back. This has the benefit that as long as the user can access the main site they'll have no problems with the dynamically generated parts because to them it will just be another request to the same web-site. Also benefits that the web-server brings to static content (like compression), can transparently be applied to your app. The downside of this approach is on your end: the server needs to be configured to enable a protocol like CGI (with appropriate restrictions on how it's used), and your app often has to be restructured because it will be receiving requests and sending out responses differently and in the case of CGI, the program has a different life-cycle, the program is started once per request, and is expected to exit at the end of the request.

Even with these hassles the most popular option is usually #3 if you are integrating into an existing site since it's invisible to the user, and most of the work is done by tried and true code. PHP for example works in this model, and it is either run as a CGI program, a FastCGI server, or most commonly a dynamically loaded module in the web-server (mod_php). Go doesn't support the third option as it doesn't produce dynamically linked code.

Jim.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Carlos Castillo]

I didn't catch the ":8080" vs "localhost:8080" before so I wasn't sure what you were asking. Yes, if you provide an address (and not just a port) in a listener declaration, then the requests can only be received if sent to that address. Since localhost only exists on the current machine, no other machine can send requests to a server listening there.

Also, calling http.ListenAndServe(...) sets up your go app *as* a web server, so if you are trying to integrate it into an existing server (eg: apache), you are now running two servers on the same machine, one at port 80, the default port, and the other at whatever port you specify. There can be some subtle problems (as mentioned before same origin policy & firewalls) that you can trip over if you work this way.

--

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Jim Ellis]

Carlos,

I really appreciate your patience and explanations.  I am not a "network" person, so this is quite a bit of new stuff for me to get a grasp on.  When I have worked on web sites I either just used html for a static page or php for a dynamic page.  I did not have to get into the server set up.  

So I have been trying to get the concept in place of how a go program would fit into this.  I spent the weekend giving your replies some thought.

I am still having problems though figuring out how to proceed where I can use go.  So I would like to talk through where I am at and what problems I am seeing.

First, your further explanation about the 3 camps is very helpful.  

It would appear that #3, the cgi approach is one that are saying is the most popular.  A few questions I have would be how would concurrency be handled with this approach?

Doesn't this involve more server resources as it is constantly restarting and re-initializing the program on every request?  

How would a chat program be handled in this approach where there is a constant stream of data going to the server and being displayed to many different clients?

Let me give you an outline of what I want to do with go.

I belong to a social club and I want to redo the club web site.

We have the main page that tells people about the club.

We have a "join us" page.

We have a members section. 

The main part of the members section is a forum.

In the members section we want to have a chat room.

And I would like to add a program where people can put in some base information and it will perform calculations to give them an answer to help them know what parts they need to complete a project.

(The chat and project calc stuff are things I was thinking of putting into a desktop program to try to lesson the processing of the server.)

The club is using a shared web server from a web hosting company.

Here are things I have a good grasp on the concept, and for me are just a matter of putting the details in place..

I have researched how to use session and static cookies to figure out if the person is logged in.

I can do the coding to determine the persons access level.  Whether they are a guest, a member, a moderator, or an administrator.

I am working out the best approach for a menu, and the page template layout.  (I want to make sure it shows up well on a mobile devise as well as a desktop browser.)  

I can do the coding to store info in a database and retrieve it.

I can do the page layout where people can enter data and review it.

From what I had read, I wanted to use the url for just the site navigation, such as club.com/members/chat to tell go to load the chat page.  Or club.com/members/forum to load the forum page.  (and likely have a further sub level to define the specific forum to view.

I wanted to use "POST" for the data to be posted.  I wanted to keep this data out of the url so I could make it easier to make sure that the program is safe from sql injection attacks.  Also, I think it makes the overall look a lot cleaner.

But now I question whether I can use the post method this way with the cgi route?

With cgi how does the page know to call the go program?

With cgi could I have multiple go programs in the cgi-bin directory, and how would the page know which one to call to execute?

I also question how well will the templates show up sending them via the cgi output format?

If I were to use the #1 approach of using go as the web server, would that mean that I could not do a static html page, or a php page?

With the #1 approach, would it work on a shared server, where there are multiple web sites on the server, and only the web site of my club is running go as a server?

Would #2 wind up being the best approach where concurrency could be used as well as the chat room stuff, and where the server would not be starting and initializing the program so much?

What approach would you take to do this and why?

Thanks,

Jim.

PS.  A comment that I hope the go team would see and think about.

From what I have seen go is showing a lot of potential as a new language.  It can do quite a bit of processing and handle things "behind the scenes".  For those that are "systems" type of programmers, that know what it takes to create a language, and know the very deep things that take place on a system level, such as how to make a web server, go is "usable".

I believe that go is reaching the point though where the big issue is how programmers that are not "systems" people will be able to use go.  A good example is the difficulties I am having figuring out how actually be able to use go on a web site.  I am running into a lot of difficulties in how to get it set up to run.

I believe there are only a few types of web servers.  So why isn't there a guide on how to get a go program to run on the different server types?

There are quite a few examples of how to use go with a web browser, which gives us 1 UI type.  But there is not much out there on how to get go to work with other UI's, such as QT.

It would be very helpful if there was a guide on how to do this.

IMHO for go to be successful the programmers that are not "systems" type of people need to be shown how to get go to work with a user interface, and how to get a program to run on a desktop, a web server and when it is working, on a mobile device.

[Kiki Sugiaman]

On 6/3/2013 10:05 AM, Jim Ellis wrote:
> Carlos,
>
> I really appreciate your patience and explanations. I am not a
> "network" person, so this is quite a bit of new stuff for me to get a
> grasp on. When I have worked on web sites I either just used html for
> a static page or php for a dynamic page. I did not have to get into
> the server set up.
> So I have been trying to get the concept in place of how a go program
> would fit into this. I spent the weekend giving your replies some
> thought.
>
> I am still having problems though figuring out how to proceed where I
> can use go. So I would like to talk through where I am at and what
> problems I am seeing.
>
> First, your further explanation about the 3 camps is very helpful.
>
> It would appear that #3, the cgi approach is one that are saying is
> the most popular. A few questions I have would be how would
> concurrency be handled with this approach?
> Doesn't this involve more server resources as it is constantly
> restarting and re-initializing the program on every request?

That is what CGI is and not only it is resource intensive, it's slow and
it gets hairy pretty fast in terms of code logic. Nobody in 2013 would
recommend you writing CGI unless when you have a very simple application.

> How would a chat program be handled in this approach where there is a
> constant stream of data going to the server and being displayed to
> many different clients?
>
> Let me give you an outline of what I want to do with go.
>
> I belong to a social club and I want to redo the club web site.
> We have the main page that tells people about the club.
> We have a "join us" page.
> We have a members section.
> The main part of the members section is a forum.
> In the members section we want to have a chat room.
> And I would like to add a program where people can put in some base
> information and it will perform calculations to give them an answer to
> help them know what parts they need to complete a project.
> (The chat and project calc stuff are things I was thinking of putting
> into a desktop program to try to lesson the processing of the server.)
>
> The club is using a shared web server from a web hosting company.

Is the shared hosting a hard requirement? Unlike php which comes
preconfigured with many shared hosting, you probably have to write
cgi/fastcgi if you want to use Go on shared hosting. We know what the
problem with cgi is.
Fastcgi while is fast and resource efficient, is very hard to write from
scratch.
Today, you can spin up a VM for as little as $5/month and scale up only
when you grow and run with existing libraries other people have written,
so you don't have to write your own session, cookies, and DB handling or
html templating.

You can also implement chat on the browser, but it's really up to you.

>
> Here are things I have a good grasp on the concept, and for me are
> just a matter of putting the details in place..
> I have researched how to use session and static cookies to figure out
> if the person is logged in.
> I can do the coding to determine the persons access level. Whether
> they are a guest, a member, a moderator, or an administrator.
> I am working out the best approach for a menu, and the page template
> layout. (I want to make sure it shows up well on a mobile devise as
> well as a desktop browser.)
> I can do the coding to store info in a database and retrieve it.
> I can do the page layout where people can enter data and review it.
>
> From what I had read, I wanted to use the url for just the site
> navigation, such as club.com/members/chat to tell go to load the chat
> page. Or club.com/members/forum to load the forum page. (and likely
> have a further sub level to define the specific forum to view.
> I wanted to use "POST" for the data to be posted. I wanted to keep
> this data out of the url so I could make it easier to make sure that
> the program is safe from sql injection attacks. Also, I think it
> makes the overall look a lot cleaner.
>
> But now I question whether I can use the post method this way with the
> cgi route?
>
> With cgi how does the page know to call the go program?

Basically this is web server configuration work.
For Apache: http://httpd.apache.org/docs/2.4/howto/cgi.html

I think Go is just made to fulfill a different kind of expectation.
Shared hosting comes preconfigured with a certain stack (web server +
script runtime such as php, asp.net, etc + probably mysql). So when you
host on those environments, you install your script and configuration
files and static assets. A Go application is basically its own
independent executable, so when you deploy a Go app, you are deploying
an executable. It also comes with a web server ("net/http") as part of
the standard library, which most Go people are using.

So while you can put a Go app behind any web-server if you prefer, it's
really not necessary. A runtime is also not necessary. What you need to
run a Go app is an OS.

Also, don't let the term "systems programmer" get in your way. While you
can use Go to access deep parts of the OS kernel, you really don't have
to. Go runs directly on top of the OS and that is all you need to know
as an application developer. (Well, it probably means that you have to
perform root-level OS administration on your server but that's not
systems programming :P)

Best

> There are quite a few examples of how to use go with a web browser,
> which gives us 1 UI type. But there is not much out there on how to
> get go to work with other UI's, such as QT.
> It would be very helpful if there was a guide on how to do this.
>
> IMHO for go to be successful the programmers that are not "systems"
> type of people need to be shown how to get go to work with a user
> interface, and how to get a program to run on a desktop, a web server
> and when it is working, on a mobile device.
>

> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send

[Carlos Castillo]

I realize now that you were asking about using Go to to build a desktop app (with a web-based UI), and I went off on a tangent about integrating go programs in existing web-servers. To be fair, you did ask about that as well. I have some answers and follow up about servers below. I write a separate post about client-side apps.

Sorry if it looked like I was pushing you to use CGI (or implying it was the most popular), I wasn't certain the exact situation you were in w.r.t. your web-server, and I brought up CGI because it's the simplest to configure, and has decent support in the go standard library.

 Looked at another way, the 3 approaches are:

1. Have Go run everything
2. Have 2 servers (1 Apache + 1 Go) running simultaneously (and not necessarily on the same machine)
3. Have the Apache as the main server, and using delegate programs (Go / PHP) to service certain requests.

These aren't exactly mutually exclusive groups, for example where I used to work, we had an Apache server for static content, and a Tomcat server for Java servlet based dynamic content. By using mod_jk to connect the two servers, we were essentially combining 2&3: two servers, where one is the invisible delegate of the other. We did this not because Tomcat couldn't handle static content (it could, we in fact tested our site locally that way), but the overhead of having the Java servlet system process a simple file request was not considered worth it in production. On the other hand, writing separate CGI programs would incur (as you and Kiki noted) a start up cost on every request, which in Java can get pretty bad.

You are right about some of the shortcomings of CGI, because it involves starting up your go program with every request, so there is extra latency; and semi-persistent data (eg: sessions) are harder to do and often necessary. I have never tried to set up FastCGI before (either in general or for go) but it should help with some of the problems of CGI.

Although there are limitations with every technique and approach, they are all supposed to support HTTP, which means that POST requests and cookies shouldn't be a problem no matter how you choose to solve the problem. The thing most likely to trip you up will be the sessions. Most session systems involve two parts: a session id, which is usually added to the HTTP headers (often as a cookie or part of the URL), and a server-side storage indexed by that id. The issue is the later, as you will probably not be able to access with go the session data of programs in other environments (you mentioned you had PHP services). This isn't necessarily a blocking issue, you just need to either have a way of passing data from the foreign app to the go app (preferably not through the user), or have the user re-login to the go app.

If you decide to go with a go stand alone server, you won't have a problem with static content, as you can either use http://golang.org/pkg/net/http/#FileServer to create a handler that serves a url on the site from a folder on the server, or inside an existing http.Handler you can use http://golang.org/pkg/net/http/#ServeFile to serve an individual file from disk.

The design of Go with respect to building web-applications is that it provides simple to use, mostly low-level features instead of a high-level abstraction, such as with PHP. The parts for dealing with HTTP (the protocol), running a server, routing requests, handling cookies, compression, HTML templates, etc... are all separate and can be used, ignored, or replaced as needed. If you want a more complicated request router, or full sessions you can add pieces from the gorilla toolkit to your program (http://www.gorillatoolkit.org/) without replacing the other parts of your program.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/8VjyHRYMl2Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Carlos Castillo

[Carlos Castillo]

Comparing a Go client Desktop app with Web interface to a HTML/JS/CSS app served by the server they share the following benefits:

• Simple to create and modify interface, as it's HTML/CSS/JS although YMMV
• Portable Interface (rendered by browser)
• Easy to write code to communicate with the server

A pure web-app has the following advantages:

• Can better integrate with the website
• Only one layer of processing and communication between interface and the server
• No installation and automatic upgrades implicit in the design
• Portability is greater / simpler (ie: only need browser)

The Go app has the following advantages:

• Better access to native machine resources (CPU, Disk)
• A local cache of UI resources (no need to hit main server for large UI)
• Client side processing is generally more efficient (than JS)

If you use a UI package to build your go program (such as https://github.com/skelterjohn/go.wde):

• Better integration with native UI (most likely)
• No Browser dependency & runs separately from browser (eg: no hack to close app)
• One level of network communications (client<->server) instead of 2
• Possible size benefit (net/http is a large dependency)

If your writing a chat program, there seems to be little benefit to writing a go program with web-ui, compared to a HTML/JS/CSS client served by the web-server. There is no real processing that needs to be done, and most of the work of the app is centered around the message sent to from the server (no real client side processing). The only real benefit the go program would have is that it would not have to be restricted to browser technologies to comunicate with the server/other clients. Before websockets became part of HTML5 and integrated into most browsers, the communication between client & server could only be done with regular HTTP requests (or AJAX) which is complicated to get right for both clients and servers, as opposed to using traditional sockets, something a browser won't allow JavaScript to use.

I'm not sure of the requirements of your other client-side service, but if it actually does prove beneficial to use go for it, then integrating the chat into the program could then make sense.

If you need to make a go server, possibly to support web-sockets on the server, then go clients make more sense, because you would have a shared codebase, and easier methods to pass data back and forth. For example the Gob encoding in go allows you send structs back and forth over the websocket with little configuration needed.

[Jim Ellis]

@ksug,

Thanks for the answers.  CGI is out of consideration.

"So while you can put a Go app behind any web-server if you prefer, it's 

really not necessary. A runtime is also not necessary. What you need to 
run a Go app is an OS."

It is too bad I did not have a camera running, as the expression on my face would have been priceless to watch as that little man made it to the top floor and turned on the lights.  :)

It finally dawned on me that what I was trying figure out is how to run that executable on the hosted server. 

I have been in contact with the tech support of the hosting company and am just waiting for them to provide me the details on logging in via ssh to be able to start the myapp.exe program, and let me know the best folder to put it in.

As to "systems programmer", it doesn't get in my way.  I am in awe at those that can create a programming language and know how to manipulate a computer at the "systems" level.  That is just a level I have never had to use.  My experience has been with creating routines for gathering data, processing it, storing it in a db and retrieving it for viewing/edit and reports.

Thanks!

[Jim Ellis]

Carlos,

You are right, part of my my questions were about using go for a desktop app.  Those parts were easily answered, such as using a "launching app" and loading a browser when the app starts.  Also, with the "localhost" I have a good grasp on using go for the desktop app.

Your "tangent" about go and web servers is the area that I was really struggling with and was having a hard time grasping what I needed to do.  So your comments on it have been very helpful!

The tech support that hosts the web server did a little test for me.  He ran a simple "hello world" app, and used port 8080 for the program to listen to.  So both apache and go were running on the same server.

I believe that this is the approach I am going to take.

This way I can keep the current site up and running while I create the new site.  

Once the go program (myapp.exe) is up and running, I can either use htaccess or an index.html page to redirect the browser to port 8080 so the go program can take over and run the site.

I believe this will offer the best of all worlds as it will have apache to handle the low level parts you mentioned, and go will handle the actual processing to do what I want to do with the site.

And as I mentioned in the last reply, I finally grasped the issue I was struggling with as figuring out how to run the go program (myapp.exe) on the server.

Thanks for the reference to the gorilla toolkit. 

I think for now I am going to use html5/css3 for the UI.  I think it provides an interface where I don't have to worry about platform issues with it, the browser can do that for me.  HTML has the buttons, input boxes, etc to let the user interact with the program, and it has the mechanisms to display the output.  

I think that the canvas element in it might be the best solution for one program I have in mind that will have a graphical output.

Once again, thank you for all of the help, I greatly appreciate it!

Jim.

[Jim Ellis]

New Questions:  (I plan to write a "how to for dummies" based on these questions/answers, to try to make it easier on others as they set up a web server.)

1.  Placement of myapp.exe on web server.  (discussion of pros/cons & can it be done?)

This is a question on what directory would be best to ftp the program to.

a)  When I go into my ftp client, the "root" directory of the website is  /var/www/html 

This is where the "index.html" file is at that a web browser would read.

b)  Can a "lower level" directory on the sever be used?

I could create a /var/goprg directory and load the program there.

Which directory would be best.  Would there be "path" issues for either one.  Which would be better for security, such as if I want to create a text file to store some settings or data.  Is there any issues with the "listen" command based on what folder the program resides in?

I am thinking that the lower level directory would work, and because it is a lower level it is "hidden" from simple web browser access, so this would make it "safer" from the casual hacker.  It would take someone getting access to the server to get to the program or any files that I create that are stored in the lower level directory or path such as /var/goprg/datafiles

#2.  SSH shell.

When it comes to unix, for me it is pretty much so "u-what?"  :)

To start the go program (myapp.exe) I need to log into the server via ssh and issue a command to start the program.

Also, if the program "hangs" or becomes non-responsive I would need to log in and kill the program and then re-start it.

AND, when I go to update the program I would need to kill it, ftp the new version and then start the new program.

This means you need a log in for the server that has ssh privileges.  (bin/bash is what I have it set to and I am using Putty for the ssh client)

Once you log in you need to go to the directory where the go program is loaded at.  

For my website control panel, when I add a user to the website, and log in ssh with that user I have to change directories in this manner:

cd /var/www/html

or

cd /var/goprg

That will place me in the directory with the go program (myapp.exe)

you can do a "ls" command to list the files and it should show up.

The question I have now is what command do I use to start the go program, where it will remain running after I close the ssh client?

To stop the program, I would log in, and then type in the command "ps" to show all processes.

To terminate/stop the program you take the PID (job/process number) 

Kill #####    (the PID )

 

If that does not work then do:

Kill -9 #####  (PID)

When done type "exit" to end the ssh client session.

These are the steps that I was having so many problems with.  I think making a little tutorial out of this would be helpful to those that like me are not familiar with the "lower level" stuff.

Thanks,

Jim.

[Kiki Sugiaman]

On 6/5/2013 12:00 PM, Jim Ellis wrote:
> New Questions: (I plan to write a "how to for dummies" based on these
> questions/answers, to try to make it easier on others as they set up a
> web server.)
>
> 1. Placement of myapp.exe on web server. (discussion of pros/cons &
> can it be done?)
> This is a question on what directory would be best to ftp the program to.

Before answering your questions, I want to point out the difference
between a typical Apache setup and a typical Go app setup:
Apache is a static file server by default and application server by
configuration (remember you can configure it to serve the output of a
cgi app when you need some dynamic logic).
Your Go app should be an application server by default and a file server
by configuration, that is, until you specify by code that all the files
in the folder ~/myAwesomeGoApp/public/css/ .....(example) is publicly
accessible, no folder in your server will be publicly accessible.
As such, your directory structure should reflect logic and convenience
instead of access criteria.

Research how to run a process as a daemon in *nix, or as a service in
windows.
More elaborate setup will utilize some form of "process monitor".
Example:
http://mmonit.com/monit/documentation/monit.pdf
http://supervisord.org/

I feel that this topic is more appropriate for sysadmin discussion
forums. Feel free to come back here to discuss your Go code :)

Best

>
> To stop the program, I would log in, and then type in the command "ps"
> to show all processes.
>
> To terminate/stop the program you take the PID (job/process number)
> Kill ##### (the PID )
> If that does not work then do:
> Kill -9 ##### (PID)
>
> When done type "exit" to end the ssh client session.
>
> These are the steps that I was having so many problems with. I think
> making a little tutorial out of this would be helpful to those that
> like me are not familiar with the "lower level" stuff.
>
> Thanks,
>
> Jim.
>

> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send

[Jim Ellis]

ksug,

Thanks for the links to monit and supervisord.

I have a lot of information to sift through.  I even found a g+ post by Andrew Gerrand from a year ago that was showing how to use go via cgi on a particular website host.
So for someone like me that is not familiar with the network admin type of stuff, this is fairly complicated and confusing.

"I feel that this topic is more appropriate for sysadmin discussion 

forums. Feel free to come back here to discuss your Go code :)  "

If you know of a system admin discussion forum that is geared towards setting up a server to use go, PLEASE point it out to me!

If you don't, then I feel my questions are appropriate for this forum.  I have 1 very simple argument to make to support this.  

If I can not get my web site to use a go program, then I do not have any reason to write any go code!

Go is geared towards "processing", it "does stuff" with data.  But it needs to have inputs, where a user enters data and makes a request for processing to be done.  And when that processing is done, there needs to be a way to display the results to the user.

In go there is the net/http library.  And I am seeing that html5 is showing a lot of promise to be a user interface.

What I am finding quite ironic, is that in the comments I have seen, the go creators have said go is designed more for web processes and not really for a "desktop program".  But yet, the way that the net/http is set up, it is very easy to use it for a desktop program by using localhost in the browser url!

But to set it up on a website is a major problem!!!!!

And this is where I think that go is failing to get widespread support.

For those that are low level developers, that know "systems" type of issues, which quite often include the network admin type of issues, it is not a big deal and they can make go work.

But for those of us that are not at that level, these problems with getting go to work on a web site is a major stumbling block.  And if it is too complicated it winds up where a person will just pass up on go and use a different language that they can get to work on the web site.

Consider this.  With php all I need to do is use an ide, whether it is notepad or one that has features built into it.  I create a text file with the php tags, the code to "do stuff", give it a php extension, ftp it to the web site, and it runs!

Basically all I have to do is learn the correct php syntax.  This makes it a pretty low barrier to overcome!

For go, you have to learn the syntax, which is not that big of a deal.  The development of go has made this something that is not a major obstacle.

There is a bit of an issue on the compiling to run on the different platforms.  Such as to do a localhost test I would compile to windows.  When it is ready for my website, then I need to compile it to run on linux.  

Then there is the barrier that has been my major problem, what to do to get it where when I type in the website address in a browser, the go program will work.

My goal here is to get a guide developed to help people overcome this barrier.  IMHO, right now this barrier is something that I believe is hindering the widespread acceptance of go.

Jim.

[Matt Silverlock]

On Thursday, June 6, 2013 8:54:01 PM UTC+8, Jim Ellis wrote:

And this is where I think that go is failing to get widespread support.

For those that are low level developers, that know "systems" type of issues, which quite often include the network admin type of issues, it is not a big deal and they can make go work.

But for those of us that are not at that level, these problems with getting go to work on a web site is a major stumbling block.  And if it is too complicated it winds up where a person will just pass up on go and use a different language that they can get to work on the web site.

Consider this.  With php all I need to do is use an ide, whether it is notepad or one that has features built into it.  I create a text file with the php tags, the code to "do stuff", give it a php extension, ftp it to the web site, and it runs!

Basically all I have to do is learn the correct php syntax.  This makes it a pretty low barrier to overcome!

For go, you have to learn the syntax, which is not that big of a deal.  The development of go has made this something that is not a major obstacle.

There is a bit of an issue on the compiling to run on the different platforms.  Such as to do a localhost test I would compile to windows.  When it is ready for my website, then I need to compile it to run on linux.  

Then there is the barrier that has been my major problem, what to do to get it where when I type in the website address in a browser, the go program will work.

The "ease" at which you can just upload a bunch of PHP files is two-fold: PHP is designed to be embedded alongside HTML—ignoring, for a moment, the more sensible MVC approach—and PHP hosting (typically Apache + mod_php or FCGI) is extremely widespread due to its age and popularity.

I also don't believe Go is "failing to get widespread support": it's still a (very) young language. It, likely many other modern languages, take a different tack from PHP and enforce a bit more structure: this ultimately makes the barrier to entry a little higher. PHP isn't without it's own problems though: it's just that typically don't show themselves when you're just starting out. Note that the "issues" (to use your phrasing) you're having re: compiling won't ever change: Go is a compiled language, and targets different architectures. Cross-compiling in Go, thankfully, is super easy and makes writing on platform X and deploying to platform Y pretty easy. 

Creating a basic web application in Go is really no harder than doing so with a minimal Python or Ruby framework—and Go, like those languages, has a ton of libraries (gorilla, et. al) that can keep you from having to reinvent the wheel. 

I mean no offense by this, but judging by the way you refer to some technologies ("browser URL", "desktop program", "html5"), I think some of your issues are just due to a lack of experience with modern development environments. Yes, there's a bit more to learn these days, but in exchange you gain a lot more flexibility.

To answer your root question: just use the built-in HTTP server and router to serve your content for testing ("localhost"). Dump your static files behind the /static route. When you need to deploy into production, set up Apache or nginx w/ FCGI or as a reverse HTTP proxy. There are literally hundreds of guides on how to set up both of those web servers in FCGI or reverse HTTP "modes", and it's generally pretty simple if you just want vanilla HTTP. My advice is to cross that bridge when you get to it: start building an application first.

[Kiki Sugiaman]

On 6/6/2013 7:54 AM, Jim Ellis wrote:
> ksug,
>
> Thanks for the links to monit and supervisord.
> I have a lot of information to sift through. I even found a g+ post
> by Andrew Gerrand from a year ago that was showing how to use go via
> cgi on a particular website host.
> So for someone like me that is not familiar with the network admin
> type of stuff, this is fairly complicated and confusing.
>
> "I feel that this topic is more appropriate for sysadmin discussion
> forums. Feel free to come back here to discuss your Go code :) "
>
> If you know of a system admin discussion forum that is geared towards
> setting up a server to use go, PLEASE point it out to me!
>
> If you don't, then I feel my questions are appropriate for this forum.
> I have 1 very simple argument to make to support this.
> If I can not get my web site to use a go program, then I do not have
> any reason to write any go code!

You are facing the same deployment hurdles as what you would face if you
were to deploy a Python-Django or Ruby on Rails application for example.
So I meant it in that sense.
I didn't point you to a specific site because I felt that your problem
was a bit open ended, that is (and I'm making assumptions here) you need
to brush up a bit on OS administration, background vs foreground
processes, etc.
http://www.webhostingtalk.com/ is a good place for hosting and
deployment discussions.
It wasn't my intention to drive you away from this list, it's just that
you'll get better answer for your questions somewhere else.

>
> Go is geared towards "processing", it "does stuff" with data. But it
> needs to have inputs, where a user enters data and makes a request for
> processing to be done. And when that processing is done, there needs
> to be a way to display the results to the user.
>
> In go there is the net/http library. And I am seeing that html5 is
> showing a lot of promise to be a user interface.
> What I am finding quite ironic, is that in the comments I have seen,
> the go creators have said go is designed more for web processes and
> not really for a "desktop program". But yet, the way that the
> net/http is set up, it is very easy to use it for a desktop program by
> using localhost in the browser url!
> But to set it up on a website is a major problem!!!!!

What's serving on localhost:8080 for example, is actually a web app. You
can deploy it on mysite.com:80 and it will be accessible to the world as
http://www.mysite.com. The same way you can run Apache on your desktop,
but after you deploy it on a proper web-host, your Apache becomes a
fully fledged website.
The difference is that Apache comes preconfigured by a lot of web hosts
due to it adoption.

>
> And this is where I think that go is failing to get widespread support.
> For those that are low level developers, that know "systems" type of
> issues, which quite often include the network admin type of issues, it
> is not a big deal and they can make go work.
> But for those of us that are not at that level, these problems with
> getting go to work on a web site is a major stumbling block. And if
> it is too complicated it winds up where a person will just pass up on
> go and use a different language that they can get to work on the web site.
>
> Consider this. With php all I need to do is use an ide, whether it is
> notepad or one that has features built into it. I create a text file
> with the php tags, the code to "do stuff", give it a php extension,
> ftp it to the web site, and it runs!
> Basically all I have to do is learn the correct php syntax. This
> makes it a pretty low barrier to overcome!

Yes, Go has a higher barrier to entry than PHP, for more power and
flexibility. But it's not any higher than something like Ruby on Rails
for example.
Good luck with your guide!

>
> For go, you have to learn the syntax, which is not that big of a deal.
> The development of go has made this something that is not a major
> obstacle.
> There is a bit of an issue on the compiling to run on the different
> platforms. Such as to do a localhost test I would compile to windows.
> When it is ready for my website, then I need to compile it to run on
> linux.
>
> Then there is the barrier that has been my major problem, what to do
> to get it where when I type in the website address in a browser, the
> go program will work.
>
> My goal here is to get a guide developed to help people overcome this
> barrier. IMHO, right now this barrier is something that I believe is
> hindering the widespread acceptance of go.
>
> Jim.
>
>

[Jim Ellis]

Matt,

The comparison to php was a bit of a crude one.  I would not be here trying to learn this if I did not think that go could do a lot more than php.

Actually, this is the first time in a very long time that I have been excited about a language, as I can see a lot of potential for using go where in the end it will save me a lot of work and be usable across many different platforms in one form or another.

BTW, yes, the compile to each platform is something that will have to be done, which is a cost of it being a compiled program, a cost that IMHO is well worth it.  I listed it because it is just another step that has some details that have to be paid attention to so it is done right.

And yes, you are right, I am behind the times in regards to modern dev environments.  I have been away from programming for a while, a big part of it has been due to my impression that there was not a language that would do what I wanted to do.  The "juice was not worth the squeeze".

Once again, this shows that I see a lot of potential for go.

>"start building an application first"

I have.  :)  

I am taking it in measured steps.  I found how easy it is to use the start of the program on my desktop with localhost.  So the next step was to put it on the website and see it run there.  Thus, this thread......

For the next few days I am going to break this down to 2 steps.  First I need to get the program compiled to run on the linux server.

Then I need to digest all of the information I have gathered and start "playing" with the program on the linux box.

It looks like I will have to do a lot of trial and error to figure out what will work.  (From everything I have seen, it appears to me that the program will be ran in the background on the linux box.)

>"What's serving on localhost:8080 for example, is actually a web app."

I understand that part of it.  My pc is acting like a server to have the program interact with the browser.

>"You can deploy it on mysite.com:80 and it will be accessible to the world as 
http://www.mysite.com."

Will this cause a conflict between the go program and apache?

(this was one of the things I figured would be part of the "trial and error".)

>"Yes, Go has a higher barrier to entry than PHP, for more power and 
flexibility. But it's not any higher than something like Ruby on Rails 
for example. "

I think it is higher than ruby on rails.  With one little search I found several links to "how to's" that contain instructions on what a person needs to do to get ruby on their apache server.

(from that very quick glance, it appears that the instructions I found install the runtime on apache, and then when you write the app it is handled in a manner similar to php)

>"Good luck with your guide! "

Thanks.  As you can see in this thread, a lot has been said, but there have not been any clear instructions so I am left with a lot of trial and error.

I am hoping that once I am done with this, it will make for a good wiki entry on the steps needed to be followed.

[Kiki Sugiaman]

On 6/6/2013 2:40 PM, Jim Ellis wrote:

Matt,

The comparison to php was a bit of a crude one.  I would not be here trying to learn this if I did not think that go could do a lot more than php.

Actually, this is the first time in a very long time that I have been excited about a language, as I can see a lot of potential for using go where in the end it will save me a lot of work and be usable across many different platforms in one form or another.

BTW, yes, the compile to each platform is something that will have to be done, which is a cost of it being a compiled program, a cost that IMHO is well worth it.  I listed it because it is just another step that has some details that have to be paid attention to so it is done right.

And yes, you are right, I am behind the times in regards to modern dev environments.  I have been away from programming for a while, a big part of it has been due to my impression that there was not a language that would do what I wanted to do.  The "juice was not worth the squeeze".

Once again, this shows that I see a lot of potential for go.

>"start building an application first"

I have.  :)  

I am taking it in measured steps.  I found how easy it is to use the start of the program on my desktop with localhost.  So the next step was to put it on the website and see it run there.  Thus, this thread......

For the next few days I am going to break this down to 2 steps.  First I need to get the program compiled to run on the linux server.

Then I need to digest all of the information I have gathered and start "playing" with the program on the linux box.

It looks like I will have to do a lot of trial and error to figure out what will work.  (From everything I have seen, it appears to me that the program will be ran in the background on the linux box.)

>"What's serving on localhost:8080 for example, is actually a web app."

I understand that part of it.  My pc is acting like a server to have the program interact with the browser.

>"You can deploy it on mysite.com:80 and it will be accessible to the world as 
http://www.mysite.com."

Will this cause a conflict between the go program and apache?

(this was one of the things I figured would be part of the "trial and error".)

If you deploy the go exec as a standalone app, there will be no Apache in the picture.

If you use Apache or any other web-server as a proxy, then the picture more or less becomes like this:

------http request------> :80 | Apache | ----req----> :8080 | Go app |
<-----http response-----                           <----resp----

(I know indentation will murder the cute picture above, oh well)


If you use fcgi with Apache, it will be similar but now your go app has to speak the protocol:

------http request------> :80 | Apache | ----fcgi_protocol----> :8080 | Go app |
<-----http response-----                           <----fcgi_protocol----

>"Yes, Go has a higher barrier to entry than PHP, for more power and 
flexibility. But it's not any higher than something like Ruby on Rails 
for example. "

I think it is higher than ruby on rails.  With one little search I found several links to "how to's" that contain instructions on what a person needs to do to get ruby on their apache server.

(from that very quick glance, it appears that the instructions I found install the runtime on apache, and then when you write the app it is handled in a manner similar to php)

Only because RoR has been around longer. The principle/mechanics is similar. A Ruby runtime/interpreter is needed because Ruby is a scripting/interpreted language.

>"Good luck with your guide! "

Thanks.  As you can see in this thread, a lot has been said, but there have not been any clear instructions so I am left with a lot of trial and error.

I am hoping that once I am done with this, it will make for a good wiki entry on the steps needed to be followed.

[Kiki Sugiaman]

Also, take a look at various PaaS/cloud options like Google App Engine. I personally dislike PaaS' because I have to learn the specifics of their API and I like root control of my OS. But I'm *guessing* that they will minimize your job of daemonizing and monitoring your running app.

On 6/6/2013 2:40 PM, Jim Ellis wrote:

[Matt Silverlock]

On Friday, June 7, 2013 4:30:46 AM UTC+8, ksug wrote:

Also, take a look at various PaaS/cloud options like Google App Engine. I personally dislike PaaS' because I have to learn the specifics of their API and I like root control of my OS. But I'm *guessing* that they will minimize your job of daemonizing and monitoring your running app.

Heroku can also be a good option. Go binaries can easily be run there, there is very little API tie-in (usually just if you go down the add-on route) and you don't need to worry about the sysadmin side. dotCloud also supports Go, although they don't have Go 1.1 support yet (there's a 1.0.3 config that needs a fork...).

The problem with going down the "Linux" route from day zero is that you have a fair bit more to configure than just your web server--which can get in the way of actually making something.

[Jim Ellis]

A little update.

I installed LiteIDE as it has the selection to compile to linux.  I also had to install all the stuff to get that to work.  I am now able to compile a program that will run on my linux/apache web server.

BUT,,,,,,,,,,  I am having a "problem" with the listenandserve command.

        http.HandleFunc("/", handler)

http.HandleFunc("/stop/", stopHandler)

err := http.ListenAndServe("localhost:8080", nil)

We all know that the "localhost" makes the program run on my pc, what I would refer to as a "desktop" program.  One "problem" I am now having when I compile the program to run on my windows pc is that it opens a dos/command window.  There is no prompt showing, and while that window is open I can direct a browser to localhost:8080 and see the hello page.

I then changed the listenandserver to (":8080", nil)

I compiled this and it runs on my pc, the browser will show the page at localhost:8080.

I compiled it to linux32, FTP'd the file to the web server, ssh'd in and started it.

I went to mysite.com:8080 and the page shows up.  So it is running on the web site and is viewable!  yeah!  :)

BUT, here is the problem.  It is a shared server.  So a person with a different url on that server can also see the program.  othersite.com:8080 showed the same hello page.   This is a problem, I can not have my program show up on other web sites!

I then made the next change to the listenandserve command to ("http://mysite.com:8080", nil)

It compiled to linux32, I ftp'd it to the server, and when I ssh'd in to run it, I got the error message of "too many colons http://mysite.com:8080"

It would not run!

Would someone please be kind enough to give me some instructions on what I need to do to get the program where it only shows up on my web site, not on every site that is on that server!

And for the last step, what is the command or steps that I will need to take to redirect the apache server to feed the base url requests to the 8080 port.  

Thanks,

Jim.

ps.  I am getting very close to where I can post that guide.  I just have these few small details to get taken care of.

[James Bardin]

On Monday, June 10, 2013 3:43:54 PM UTC-4, Jim Ellis wrote:

I went to mysite.com:8080 and the page shows up.  So it is running on the web site and is viewable!  yeah!  :)

BUT, here is the problem.  It is a shared server.  So a person with a different url on that server can also see the program.  othersite.com:8080 showed the same hello page.   This is a problem, I can not have my program show up on other web sites!

I then made the next change to the listenandserve command to ("http://mysite.com:8080", nil)

It compiled to linux32, I ftp'd it to the server, and when I ssh'd in to run it, I got the error message of "too many colons http://mysite.com:8080"

It would not run!

The ListenAndServe  function declares what ip address and port to bind the server to. If your shared hosting gives you your own ip address, then you wan to put it there (the empty ip address is a wildcard, and will listen on all interfaces).

You very likely won't have your own IP on a shard server, which requires that you specify a "virtual host". Luckily, ServeMux can match against the host name as well (http://golang.org/pkg/net/http/#ServeMux). Adding your hostname to the handler pattern should take care of only responding on your intended domain. You probably don't want to do this however if you intend to put the go service behind a reverse proxy. It will just complicate things, and you can handle the virtual host definitions in the frontend server.

[Jim Ellis]

James,

Thanks for the answer.  I have some followup questions to it.

If listenandserve is looking for an IP address, why are there examples that show using http://url.com  ?

(note:  that is just a question out of frustration of trying to follow an example that sends you down a wrong path)

I will take a look at the servemux.  Would you happen to know of an example where it is used, so that I would make sure I use it correctly?

What is a reverse proxy?  Your last part of the answer is confusing, as you say here is what you need to do (servemux), but don't do it as "it will complicate things and you can handle the virtual host definitions in the frontend server".  How would this be handled in the frontend server, and would this be better than doing the servemux?

Thanks,

Jim.

[Kiki Sugiaman]

Reverse proxy refers to a setup where you put your app behind something
like Apache or Nginx, with your app being just an http server (as
opposed to something like fcgi or module app).
When you use this setup, you should configure your front-end server to
do the domain binding and not your Go app.

[James Bardin]

On Monday, June 10, 2013 4:38:48 PM UTC-4, Jim Ellis wrote:

James,

Thanks for the answer.  I have some followup questions to it.

If listenandserve is looking for an IP address, why are there examples that show using http://url.com  ?

(note:  that is just a question out of frustration of trying to follow an example that sends you down a wrong path)

Where are these examples? ListenAndServe takes an address string, and 'http://' isn't part of an address, it's the URI scheme (well, http is the scheme name, then the separator, and start of the authority part). You can use a hostname as long as the system can resolve it to an ip address to which it can bind.

 

I will take a look at the servemux.  Would you happen to know of an example where it is used, so that I would make sure I use it correctly?

You are using the DefaultServeMux already: http://golang.org/pkg/net/http/#HandleFunc

 

What is a reverse proxy?  Your last part of the answer is confusing, as you say here is what you need to do (servemux), but don't do it as "it will complicate things and you can handle the virtual host definitions in the frontend server".  How would this be handled in the frontend server, and would this be better than doing the servemux?

Well, I only skimmed some of the previous discussion, but others had suggested you put the go service behind a web server, so as to easily combine your static assets with your application. This isn't really a discussion for golang-nuts though; you need to do some more reading up on these systems, and how they work if you intend to deploy an application in this manner. You're missing a lot of background here, and it makes it difficult to communicate precisely (I wouldn't have known to differentiate between a hostname and a URI for example, which I can see is confusing if you don't know the difference).

[Jim Ellis]

Here is the code of the program I am trying to get run on my website.

package main

import (

    "log"

    "net/http"

    "os"

)

const resp = `<html>

    <head>

        <title>Simple Web App</title>

    </head>

    <body>

        <h1>Simple Web App</h1>

        <p>Hello Jim!</p>

    </body>

</html>`

func handler(w http.ResponseWriter, r *http.Request) {

    w.Write([]byte(resp))

}

func stopHandler(w http.ResponseWriter, r *http.Request) {

    go gopanic()

}

func gopanic() { // very ugly way to abort the listenandserve

    panic("stop request called")

}

func main() {

    http.HandleFunc("/", handler)

    http.HandleFunc("/stop", stopHandler)

    err := http.ListenAndServe(":8080", nil)

    if err != nil {

        log.Println(err)

        os.Exit(1)

    }

}

When I run that code, it does run on the web site, and the /stop will cause it to panic and end the program.

The "problem" is that this also shows up on other web sites that are on the same server!

And the /stop on the othersite.com will cause the program to panic and stop.

So I need to make this where it responds only to my web site.  And as someone above said, I do NOT have a specific ip address for the web site.  It is an ip to the server.  I believe apache takes over at that point to send the request to the correct url.

Because it is a shared host, I don't know if I can do any of the reverse proxy stuff or anything else that would effect the other sites on the server.

In another thread it was suggested to use localhost:8080 in the handlefunc.  Further discussion suggested it might need :// infront of that.

I tried this change to the above code.

 http.HandleFunc("localhost:8080/", handler)
    http.HandleFunc("localhost:8080/stop", stopHandler)
    err := http.ListenAndServe(":8080", nil)

the program ran, but it gave a 404 page not found error when I went to mysite.com:8080
same thing when I tried the /stop at the end of the url.

The same thing happened when I went to the url of another site on the server, so it is not responding only to my domain.

How do I get the server to only respond to requests for mysite.com?  Please give specific code examples, I have not been able to figure it out on my own.

Thank you,

Jim.

[Kiki Sugiaman]

When you deploy, your host is not localhost anymore. Have you tried changing "localhost:8080/" to "mysite.com:8080/"

The same thing happened when I went to the url of another site on the server, so it is not responding only to my domain.

How do I get the server to only respond to requests for mysite.com?  Please give specific code examples, I have not been able to figure it out on my own.

Thank you,

Jim.

--

[Eric Palmer]

If I'm understanding this then

x.com, y.com and z.com (some list of host names) are mapped to the same ip address. Right?

You are listening to a specific port (8080).  All requests to the ip address on the server at 8080 will go to your go program.  So for this example x.com, y.com and z.com will go to the same http server when accessing 8080.  That is because at the lower level it is just an ip and port #.  Knowledge of the host name is not at that level of tcp net listening.  What you need is http/1.1.  See below.

You can restrict what you respond to if you look at the request header and see what the request url is.  Then you can decide only to respond to that host and ignore the others. I don't know that go syntax.

Modern httpd web servers support virtual hosts (apache httpd for example) . See this post http://en.wikipedia.org/wiki/Virtual_hosting

http/1.1 protocol supports virtual hosts.  I have no idea if go supports 1.1. But I doubt it as it I am assuming it is meant to be lower level.  

I hope this helps. If I am miss reading this let us know more about the problem.

Eric

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
KK4MWM (Ham Radio)
About Me
http://www.thingiverse.com/DaddyOh
Join the 3DPrinter Revolution
http://makerbot.com

[Jim Ellis]

Ksug,
http://mysite.com:8080/ does not work. It is looking for an up address to go with the port 8080. It is the nil that should refer to the url. But I have not figured out how to make mux work.

Eric, you summed it up real well. The thing is I need the go code to get it to work.

Thanks
Jim.

[Kiki Sugiaman]

If x.com, y.com, and z.com are mapped to the same IP address, then the server will receive all requests directed to all 3 domains.
However, my understanding is that the mux can choose to only respond to requests directed to a specific host:port, and return 404 on others.

On 6/11/2013 5:24 PM, Eric Palmer wrote:

[Matt Silverlock]

The "nil" in ListenAndServe(":8080", nil) is not meant to refer to a hostname/domain name: it is meant to refer to a set of handlers (i.e. one Go app can handle routes for many applications). Note that this is outside the scope of what you are doing and therefore don't worry about this.

The problem you are having is this:

1. Apache receives a request.

2. It directs it to port 8080 where your Go application is listening

3. Your Go application responds, and Apache serves that response.

What information we are missing:

1. Your shared host - who is it? Are you hosting this on your own Apache server, or a company?

2. Apache on this machine does not sound like it is set up correctly: it should serve requests for http://yoursite.com/ to a specific port (:8080, in your case) or FCGI socket. But not all requests.

Note that much of this is beyond the scope of Go itself—Ruby and Python applications would suffer similar problems.

[Andy Balholm]

On Tuesday, June 11, 2013 3:24:38 PM UTC-7, Eric Palmer wrote:

http/1.1 protocol supports virtual hosts.  I have no idea if go supports 1.1. But I doubt it as it I am assuming it is meant to be lower level.  

Go does support HTTP 1.1. 

[Eric Palmer]

that is good to know.

[Kiki Sugiaman]

OK, I did a little experiment to prove this. I deployed the following code:

/*====*/
package main

import (
"net/http"
)

func main() {
http.HandleFunc("godeploy.sugiaman.com:8080/", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("Hello world!"))
})
http.HandleFunc("godeploy.sugiaman.com:8080/stop", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("/stop/called"))
})
http.HandleFunc("godeploy.sugiaman.com:8080/start", func(resp
http.ResponseWriter, req *http.Request) {
resp.Write([]byte("/start/called"))
})
http.ListenAndServe(":8080", nil)
}
/*====*/

to godeploy.sugiaman.com:8080 and godeployfalse.sugiaman.com:8080 (both
resolve to 198.199.106.37) . Notice the lack of trailing "/" on "/stop"
and "/start", it makes a difference in my test.
I can confirm that requests to godeploy are answered, and requests to
godeployfalse receive 404.

Can you confirm this?

[Eric Palmer]

This is awesome.

Sent from my iPhone

[Jim Ellis]

Ksug,

I am at my grandsons ball game. I checked your links on my DROID and they worked as intended. The start&stop commands worked too on the first link.
The second link returned a 404 like it is suppose to and the start&stop commands also returned 404.
So it looks like that should do the job.

In the morning I will lead that code on my server and let you know the results.

Thank you! !!

Jim.