Hi Shoichi,
On Mon, Oct 17, 2016 at 5:25 AM, 魔法設計師 <shoichi.chou(a)gmail.com> wrote:
1. Acutally speaking it can be launched as a
self-server by lightweight
Jetty (the server is Jetty embedded) it will be launched as a nomal java
application. Why I use Tomcat now but not launched by "java -jar XXXX.jar"
,is because on
tools.wmflabs.org , as I remembered,
I had took the way :
"webservice generic start /data/project/toolname/code/myserver.bash "
Then, the port binding always faiedl,because the command "port" seemed
always take away parameters belongs to
the java ap owns.
I couldn't resolve it,so I changed to Tomcat.
Great point--we can serve this using whatever Java web container is most
practical! Question for wikitech-l: Which would that be? It looks like
we're already running Jetty for Gerrit, is that the best choice for a new
service?
2.About Chinese variable and function names in the
server code, after
forking from the upstream , I think it can be translated to English (
Actually speaking,I have get some works done.)
I'd be happy to help with some of that, maybe we can coordinate the work at
some point. Forking just for the sake of translation sounds problematic,
though. Maybe I'm wrong about this being a review requirement--or maybe
the upstream author would be open to switching to English variable names?
Sorry again about the anglocentrism...
3. There are another way : deploying it to an independent server. For
example
a. use the upstream server like this
<http://%E6%BC%A2%E5%AD%97.%E6%84%8F%E5%82%B3.%E5%8F%B0%E7%81%A3/%E2%BF%B1%E2%BF%B0%E7%81%AB%E7%81%AB%E2%BF%B0%E7%81%AB%E7%81%AB.png?%E5%AD%97%E9%AB%94=%E5%AE%8B%E9%AB%94>
b.use a server maintained by we, Taiwan Chapter, providing service for
C.J.K.V wiki_____ and etc.
I don't think we have the option of using a 3rd-party server, nor relying
on a WMF Labs service for production use. We want to have the same uptime
and security guarantees as for the wiki itself. The production
configuration will probably need to look like a dedicated node or cluster
for serving the IDS requests, and we would cache its PNG or SVG responses.
Someone here might be able to correct me, though?
Thanks again for integrating this tool for us!
-Adam