Make examples more representative

[flowchartsman]

These examples are nice and exhaustive, but they rely so heavily on shared, external methods, that it can be difficult to figure out what's going on

[gmallard]

So, do you have any concrete suggestions?

The problem description is pretty vague.

[flowchartsman]

I think it would go a long way to just make sngecomm.go concentrate on header munging and default values rather than convenience methods that obfuscate the generation of the necessary headers for what's really necessary to use the library in its current form

So, then, instead of

// in subscribe.go
sngecomm.Subscribe(conn, d, i, "auto")

you have

h := stompngo.Headers{"destination", d, "ack", "auto"}
idField := sngecomm.ConnNeedsID(conn, i)
if idField != nil {
    h.add(idField...)
}
conn.Subscribe(h)

Then it's pretty clear that headers (and conforming them to the spec) is what using stompngo is all about. It just seems like sngecomm.go is almost like another STOMP framework unto itself, which I guess is fine, if part of the example is telling people they need to set up their own convenience libraries, but the examples just look nothing like how you would actually use the library.

EDIT: I've changed the title of the issue to more accurately reflect the point I was trying to get across.

[gmallard]

I will easily admit this examples package is a bit chaotic.

It was quickly slapped together when the main stompngo was being completed. And has grown without much (if any) thought given to 'design/architecture'.

I am going to suggest that you make a few changes of the sort you would like to see, and send me pull requests.

[flowchartsman]

Righto. I'll branch it or something.

[gmallard]

If you clone, make sure you stay up to date. I will try to get a small RECEIPT example in soon. And have one other change almost ready.