I would prefer git-bug not to include a webserver by default.

Anachron (Anachron) changed the title from Separate webui from git-bug? to Separate webui from git-bug? 7 years ago

Can you explain why ?

The webserver is only active and listening when you actually launch the web UI.

Sure!

I don't really see the need to bundle a web-server into a command-line first bugtracker application that is meant to be offline-first.

Also I am really a fan of the SoC (separation of concerns) concept.

Well, the all-in-one binary make it extremely easy to install. Just drop it wherever you want in your $PATH.

Maybe what you want would be two different version, one with everything and one with just the terminal tools ? It's doable but it would just reduce slightly the binary size.

Am I missing something ?

Yep I can understand that it makes it easy to install and use.

I guess the second version with a stripped server is a good solution for both parties.

Honestly, I still don't see a good enough reason to make the release process more complex and possibly confuse new user with multiple binaries. It would just reduce the binary size by something like 1 or 2 Mb, which is close to nothing nowadays.

@ianwalter I see that you agree with this idea, can you explain why ?

That‘s funny because I don‘t see a reason as for why we need to ship a webserver by default ;-)

Just when you use a terminal text editor you also dont want it to ship a webserver by default, just because it makes it easier for some people to read man pages as it could open them in html instead.

I‘m all about the unix philosophy. Do one thing and do it well.

My 2 cents.. keep the webserver. It makes it easy to get going. You will want a webserver for ops. In fact the way the web server has been built using the VFS is smart too as it makes it very easy to debug.

If you don't want it then just don't use it ? What's your use case leading to wanting it removed ?

On Sun, 19 Aug 2018, 08:53 Anachron, notifications@github.com wrote:

That‘s funny because I don‘t see a reason as for why we need to ship a webserver by default ;-)

Just when you use a terminal text editor you also dont want it to ship a webserver by default, just because it makes it easier for some people to read man pages as it could open them in html instead.

I‘m all about the unix philosophy. Do one thing and do it well.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MichaelMure/git-bug/issues/22#issuecomment-414107952, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwml3J36I31RPfjTtQxTKWd4jcQGeks5uSQtwgaJpZM4WCjx6 .

fwiw popular text editors not only actually ship a web server by default but also a browser. https://github.com/atom/atom

and there is gitWeb builtin into git https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb where you just need to specify a server, but get the web ui builtin

I also think this should be separated, but because of my philosophy, which is: Git also doesn't pack a web server and web UI, people install Gitea etc. for that and there's a choice in the web UIs for people to use.

By separating the two, you'll give people something they can build their own web UIs atop, with yours being the leading example.

But then build on top of the one already there I stead of encouraging fragmentation.

And if you don't want the one there you can use your own if you really want anyway so why deprive users that prefer a built in web GUI from having one. You have lost nothing if there is a built in one anyway.

On Sun, 19 Aug 2018, 11:05 Tomáš Hübelbauer, notifications@github.com wrote:

I also think this should be separated, but because of my philosophy, which is: Git also doesn't pack a web server and web UI, people install Gitea etc. for that and there's a choice in the web UIs for people to use.

By separating the two, you'll give people something they can build their own web UIs atop, with yours being the leading example.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MichaelMure/git-bug/issues/22#issuecomment-414114181, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwm9d-8kHYOJlhyiFtjmgc5YNBUldks5uSSpvgaJpZM4WCjx6 .

@monouser7dig

Did you not see the „terminal“ I‘ve put in my comment?

I know there are editors with electron runtime and alike.

But there are people who don‘t want that. I dont want to have 15 apps with browsers bundled, which is why I dont install any electron apps.

I also don‘t want to have 15 packages which have a webserver bundled optionally.

It‘s not about the size of binary but rather: I don‘t need it to use git-bug, so I dont see why it should be shipped by default. There are tons of people who will use the cli only part.

@TomasHubelbauer you can already run your own web UI if you want to.

But honestly, i hope that people would come forward instead and build the current one as they see fit.

@Anachron you can make the same argument with any feature of any software.

I'm not using the interactive terminal UI, so why would it be shipped with that ?

How and where do you draw the line ? How an inactive web server is any different ?

I draw the line on the webserver part. Which is why I opened the issue ;-)

Its fine if an email client supports mbox but I only use maildir. Thats ok because you expect the email client to be able to handle it.

But for a git based cli bug tracker I wouldn‘t expect it to ship a webserver by default.

I really would prefer to keep the webserver too, it makes sense to keep it since it can be useful for users that are not so much used to the command line. A distributed issue-tracker doesn't mean that the UI should only be usable by command-line users.

Having two separate binaries will complexify build and confuse users imo.

And how would that confuse users? Call then „git-bug terminal version“ and „git-bug webserver version“ or alike.

Don‘t make the mistake and expect the users to be stupid. The target group are developers and alike, not computer-noobs that dont know the difference from linux and windows.

i think having a web server AND a terminal ui is a fantastic idea.

i agree with @edi9999, having 2 separate binaries would mean more time spent on building/releasing rather than development, and users wouldn't know which one to pick: the one without the webserver or the one with? does that mean it's better to have the webserver or not? what if at some point in the future i want to use the webserver but i only have the terminal ui? confusion right there. just have one binary, and it's simple.

if you want to use the webserver: use it. dont wanna use it? dont. its your choice.

I don‘t need it to use git-bug, so I dont see why it should be shipped by default. There are tons of people who will use the cli only part.

@Anachron i personally like to see the issues of a project in my web browser, i dont wanna do that inside my terminal, i can say that "i dont need a termui to use git-bug, so I dont see why it should be shipped by default. there are tons of people who will only use the web part"? it seems to me that you dont want a web server just because you dont use it.

also this webserver/ui combo is awesome: just run the command, and the ui is already there. no need to install lighttpd for example (which is required for git instaweb btw) and no need to spend time configuring anything.

@MichaelMure keep the webserver, it doesnt hurt anyone, saves time by not having to install anything to get the webui working, and people who like to use their web browser to comment issues will be happy. terminal people can still use the terminal ui, and they will be happy too. win win for everyone.

having 2 separate binaries would mean more time spent on building/releasing rather than development, and users wouldn't know which one to pick: the one without the webserver or the one with? does that mean it's better to have the webserver or not? what if at some point in the future i want to use the webserver but i only have the terminal ui? confusion right there. just have one binary, and it's simple.

I can hardly see how a split base increases the time to maintain the building and releasing. You need to do it once and then it‘s done. It‘s not like your changing your makefile every release but if you are you are doing something very wrong.

also this webserver/ui combo is awesome: just run the command, and the ui is already there. no need to install lighttpd for example (which is required for git instaweb btw) and no need to spend time configuring anything.

Thank you for making this example! Git itself separated git and git-web, so you actually made a point against your own opinion.

@Anachron i personally like to see the issues of a project in my web browser, i dont wanna do that inside my terminal, i can say that "i dont need a termui to use git-bug, so I dont see why it should be shipped by default. there are tons of people who will only use the web part"? it seems to me that you dont want a web server just because you dont use it.

Again I can hardly understand your reasoning. This tool comes with optional webserver (default passive) already so it already shows webui is just a secondary ui. If we make a survey I am pretty sure most people will do terminal-ui only instead of web-ui.

This integrated webserver stuff seems popular in Go. I‘ve found several cool projects which dont need one but include it „because it doesn‘t take much“. I am not a fan of every new software I get to have a standalone webserver that I cant maintain and/or configure/harden etc.

I am not a fan of every new software I get to have a standalone webserver that I cant maintain and/or configure/harden etc.

Then, would it be better for you to be able to access webserver settings? Since it's a local webserver... No so much things to harden...

I can hardly see how a split base increases the time to maintain the building and releasing. You need to do it once and then it‘s done. It‘s not like your changing your makefile every release but if you are you are doing something very wrong.

I'm doing this for a living mainly, and this isnt just a one time drop. You'll have to maintain each build system anytime there's a change in building system/pipelines. I really like the idea of the dormant bundled webserver, wanna use it? Enable it, otherwise just ignore it.

Don't see the problem here. Wanna save 1MB of space, for how much work hours ?

Just gonna drop by and leave my 2p on this topic having worked on vfs embedded frontends and go apps.

This is the optimal solution to handle UI right now. I don't really see the point in separating the two, it will bring more issues than it will solve.

Don't make the mistake and expect the users to be stupid. The target group are developers and alike, not computer-noobs that don't know the difference from linux and windows.

That's rather rude, not everyone is a capable linux professional, even now there's probably quite a few devs that have only had experience with Windows based systems.

I am not a fan of every new software I get to have a standalone web server that I can't maintain and/or configure/harden etc.

As person above me already covered this, this is not a public server, it's meant for your personal use only.

I am not a fan of unix holy warriors complaining on every new software doing things differently.

Alright, I think we had enough time to discuss this.

I don't see a good enough reason to justify adding development complexity and potentially confusing newcomers. As stated, if not used, the webUI is just dead code in the binary. If used, it doesn't introduce any particular security issue as it's localhost only and the API surface is quite narrow.

Of course, this can be revisited later with more specifics arguments but it will stay that way in the meantime.

Michael Muré (MichaelMure) closed the bug 7 years ago

On Mon, Aug 20, 2018 at 06:45:40AM +0000, Anachron wrote:

also this webserver/ui combo is awesome: just run the command, and the ui is already there. no need to install lighttpd for example (which is required for git instaweb btw) and no need to spend time configuring anything.

Thank you for making this example! Git itself separated git and git-web, so you actually made a point against your own opinion.

no @Anachron, you are getting it wrong. git-web is included by default with git, it just requires you to install a web server on top of that.

git-bug comes with a very light webserver, so you dont have to install one yourself, which you may (or not) never use.

Simple comment: I would love to see git-bug able to integrate with code editors (atom/intellij/vim/etc) ! It would need an API on which one can build an extension, plugin, or a complete new webui :slightly_smiling_face: This is somewhat an argument in favor of separation of concern, but does not imply the builtin webui should be distributed in another binary :slightly_smiling_face: We can have both.

@pawamoy git-bug expose a GraphQL api when running the WebUI. This could be used to build any kind of UI, including integration in code editor.

For now this API is only running alongside the WebUI but it could be made standalone easily if the need arise.