[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gitlab Migration
From: |
koder33 |
Subject: |
Re: Gitlab Migration |
Date: |
Sat, 11 Sep 2021 08:48:59 +0000 |
Just reply to my own post for completeness.
"Client part" can be implemented as an add-on/module in emacs itself; even with
lisp.
"Server part" just provide a bunch of api to communicate.
Feel free to choose an app layer protocol (http, https, others ...) for
communication;
even raw ip socket as they best fit.
BTW: How about other projects under the GNU/FSF umbrella wrt "forge" things.
How about unifying all member project into one 'server'/'server api' then use
emacs with mentioned add-on(s) as client to manage everything wrt forge.
One add-on for e-mail things, one for vcs/scm backend and one for instant
messaging :P
Sounds crazy? Posting just FYI. If counts as noise pardon me.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, September 10th, 2021 at 9:53 PM, koder33 wrote:
> hi. Just come here to drop a brillant idea as one more option: Write your own
> server-client app.
>
> Pros:
>
> - Really not need to go beyond above 3-5k LOC.
> - Its needs written with C language. Available eveywhere.
> - No JS problem from the beginning.
> - No spam message or spam account.
> - No needs for an e-mail account.
> - Client part as cli or basic curses/dialog like tui. Available everwhere,
> even a system composed only kernel + busybox.
> - Its generic. Available for everyone/every other project to host own
> project.
> - Offers 100% control w.r.t security, privacy.
> - Low maintenance burden for admins, project leaders.
> - Low maintenance burden for its own developer.
> - Easy to use for user. Single click/press to fork, make patch, MR, commit
> ...
> - Feel free to use git, hg ... as backend. Or rool your own.
> - So on.
> - Really so on.
>
> Cons:
> - Someone has to write.
> - No fancy, no loby, no eyecandy.
Re: Gitlab Migration, Yuchen Pei, 2021/09/04
Re: Gitlab Migration, koder33, 2021/09/10
- Re: Gitlab Migration,
koder33 <=