[Freecats-Dev] our HTTP server... (yes, Front-End only ?)

[Henri Chorand]

Hi,

Please, could anybody vote on this:
Do you believe we need more than a user ID and password in order to access a
Free CATS server?

Just to influence your vote before you answer ;-)
if a majority votes "Yes" now, it means some extra work which I am
absolutely ill-qualified.

My own opinion is, even if so, then, of course it can wait. I believe that
the best way to work on highly sensitive projects would simply be to avoid
sharing them over the Internet in the first place, and to keep them on a
reasonably secured local network. Enabling Free CATS' Web access feature,
like any Web access feature, should be used with one's own judgment.

This would not be a problem for free software translation projects, as no
huge piles of money would be at stake.
It's not like if Localization Giant Number One (company A) tries to hack the
"trésor de guerre" of World Company(c)'s Translation Branch (company B) - I
mean their reserve of legacy TMs - in order to suck their contents.

> Henri Chorand <address@hidden> writes:
>
> > I'm thinking about such a setup for the interface part of the
> > server. Dave being, apart from Apache Tcl's David Welton, the
> > highest-ranking Tcl officer on this list...
>
> > So I thought we could design our server as follows:
> (...)
>
> Do you really need or want an HTTP server, when all it's going to do
> is call some other commands?  I'm not sure that an http server should
> be used except as a frontend, much like it can act as a front end for
> an SQL server.

I don't know, which is why I was calling for help ;-)

But seriously, yes, I was seeing it as a front-end only, which would
transform HTTP requests (GET) into Free CATS API calls and send back Free
CATS API return values via HTTP (PUT or whatever).

I believe it's a pre-requisite if our server has to answer HTTP requests
from clients, but you might mean in fact, it's not that obvious. David, I
believe you will confirm that we DO need a HTTP server as a front-end [if
only] to process HTTP requests?
I'm not sure what we could do without one, except rewrite a VERY poor ersatz
of Apache, I'm afraid - we might name it after General Custer ;-)).

What we need is probably similar to what's happening between PHP & MySQL on
top of an Apache server:
- HTTP server (front-end)
- Free CATS server module (written in Tcl / C / C++ / whatever)
- Free CATS database (filesystem / Berkeley DB / whatever).

So I'm not talking about a HTTP server apart from being a front-end
(interface between clients and our actual routines and DB).

A HTTP server may also provide the two following advantages, none of which
is mandatory:
- There are so many existing modules which run on top of an HTTP server
today, so MAYBE it would help future integration with whatever else one has
in mind. Not to say this is a present requirement.
- In case we need more than user ID and password... can we expect to find
some pre-written secure user access module to put on top of a HTTP server,
or would we have to write everything by hand? Or am I just dreaming because,
in such a case, everything is entirely application-specific and done
"manually"?

> > Could anybody provide a basic explanation of how a HTTP server
> > works?
>
> Request comes in:
>
> GET /some/file.html HTTP/1.0
> headers...
>
> Resource requested goes out:
> ...
>
> It's pretty simple.
>
> As for the internals.... depends on the server, and very much so.

Of course. Can you tell us what you think about my little "synchronous loop"
idea? Do you believe it is, as a whole, the right way to go?


Anyway, thanks for these explanations, David !


Henri