Re: [Freecats-Dev] Re: Implementation

[Henri Chorand]

Hi,

> > > (...)
> > > I'd like to implement at least a prototype for the
> > > server API.
>
> > Well, for a start, you could possibly work in team with
> > Dan so as to review my API proposal and Dan's WSDL
> > files so as to highlight discrepancies in terms (I saw
> > some) and features (mostly minor ones, I guess), so as
> > to call for a short set of votes and see them converge.
> > This is a type of job where an "external eye" is quite
> > valuable. Also, Dan's WSDL files is not exactly an API,
> > as it's an implementation of an API. Again, I believe his
> > work to be a quite valuable basis, but I think it's important
> > for the future to be able to stabilize a first "core", even if it
> > later evolves a bit.
> >
> > My API proposal is obviously not the work of a hard-core
> > hacker, but it tries to synthetize the core features needed
> > by any CAT software from the point of view of experienced
> > translators. Because of this, I believe it should be globally
> > taken into account (possibly extended and improved, of
> > course).
> >
> > This is important, because other bits of code are likely to
> > come up, and we ensure all of them comply to the same
> > consistent set: one (compatible with itself) project.
> > Otherwise, it could (and will) become a source of hassle.
> > Once the API has been finalized, and every layer well-fefined,
> > it will be easy to plug other modules. I hope I express myself
> > right here.

> OK, I will try to stick with those, but use the yours as
> a primary source.
> IMHO, we should stop talking about specifications
> and start to write the code.

Sure, the sooner the better.


What I insist on is, I would like everybody to use the same vocabulary and
agree on the same set of core features. In this respect, if Dan does not
review our documents, he may use different terms for the same parameters or
features (a major source of confusion), or work with something different in
mind (also a potential problem).

I have been careful to follow mainstream CAT terms. To retain the same
example, seeing the next ("Free CATS-compatible") version of Dan's API
"standardized" (complying to terms found in Free CATS' draft specs) would
relieve me.

Otherwise, Free CATS would be what we call in French "une auberge espagnole"
("a Spanish inn") where everybody brings his/her own stuff without caring
about the common goal.


So, if you agree with me, I suggest you begin work based on our documents.
As fuzzy indexing will be a major source of improvements, you may well begin
by coding the server communication layer.

Several client/server frameworks already exist, including Python ones, like
Twisted (a full-fledged one):
http://twistedmatrix.com/products/twisted

There are also more lightweight ones, like Cherry.

Any of these would most probably make up a good overall communication
platform.

Let me know what you think.

Oh, and I haven't checked if any of these are compatible with SOAP (as used
by Dan).

I spotted these when looking for general-purpose client/server frameworks.

P.S. I've been awfully busy with paid work (translations) lately, which I
needed pretty badly anyway, but I still intend to do some work on the
clients' interfaces soon.


Cheers,

Henri