[Freecats-Dev] HTTP server... (Front-End only) - cont.

[Henri Chorand]

> > 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 ;-)).
>
>
> Why not just develop your own protocol first - figure out what needs
> to go in and out, and get that working, then worry about whatever
> front end you need.

Yes, definitely.
Basically, any client (translation, alignment or whatever) must be able 
to make API calls, as described in our Development Roadmap, via HTTP GET 
& PUT.

We must also decide if we implement it on top of a filesystem (which 
seems to have assets as well as drawbacks to me) or via some DBMS.

These API calls are a draft, but I guess they should not be far from 
what we'll end up implementing.
For instance, the way we send user's or admin's ID and password may be 
followed after all, since nobody knocked on the door bringing back some 
a magical mystery secure connection layer ;-)

Now that we do have an algorithm for the worst part (TU search & 
indexing), the other API calls are going to be comparatively easier to 
write, so coding stage is not too far away.

And, as an early draft, I believe we'll start by calling each of these 
functions in batch mode on test cases, and see what happens.


For now, I mainly see two areas of potential difficulty with Free CATS 
project:

On the server side, if we end up needing to pick and set up too many 
individual components in order to achieve what we need. In this respect, 
stuff like PyXML (if ever we need it, it's only an example here) look 
really neatly packaged and Python should be feasible for people like me, 
with just an average experience of computing, not (yet) closely related 
to things which look mainstream for more experienced free software 
programmers.

On the client side, wxpython may well be the tool thanks to which we'll 
build a sophisticated while portable GUI, but we'll really need help in 
order to set up everything in a clean way. It seems to require 
high-level experience of C++. Hopefully, we'll obtain help more easily 
at this stage. Also, the related problems might correspond more closely 
to widely encountered issues than with our (highly specific) TM server.

I'm less impressed with still very "obscure" (for me) issues like what 
our bilingual document working format will end up looking like.

Also, when the time will come to begin writing conversion filters, 
writing each other in turn (the first one being, of course, for the 
dummiest file format possible) should have a cascading effect, in that 
each one will help us to deal with the next one.


Henri