[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [translate-pootle] Wordforge - Gasper



Oh, and one thing I've forgotten to metion.

I think XMPP (Jabber) is a good candidate for RPC. Why?

1. The protocol is already XML based, and XML can be nested.

2. It would allow triggered updates, where master server would 
notify slave servers of a new or fuzzy string needing 
translation, so there would be less need for polling the 
master server to stay updated. Sure, slave servers would 
check for new strings eg. daily and at pootle restarts, but 
updates would still spread much much faster this way.

More here:
http://www.jabber.org/jeps/jep-0060.html

3. Jabber could be integrated into web interface in many ways, 
eg. instead of standard username/password, Pootle server 
would require your jabber username, and would only log you in 
if your account is reachable (this meaning a subset of jabber 
account states). Using jabber account as a login means fellow 
translators know where to reach you and since you are signed 
in, they can quickly intervene if you start messing around.

This is also another SoC project, see more here:
http://wiki.jabber.org/index.php/HTTP-Auth_suite  
http://www.jabber.org/jeps/jep-0070.html

4. Encryption, compression and many similar features are 
already implemented, all the Pootle project needs to do is to 
set up a jabber server.

I was mostly inspired by a blogpost seen on planetkde.org, but 
have been thinking about this earlier:
http://blog.bepointbe.be/index.php/2006/06/10/15-jabber-is-more-than-instant-messaging

Regards,
Gasper

Dne sobota 10 junij 2006 18:07 je Javier SOLA napisal(a):
> Gasper,
>
> This is great stuff. Please let us talk more about it in
> July, after your exams.
>
> Zejn Gasper wrote:
> >Indexing would be split; statistics, translation states
> > and similar metadata would go into relational database
> > for faster access. But for the PO/XLIFF files, I think
> > I'd somehow rather go with (pickled) flatfiles.
>
> This could be a real posibility, as it could really
> accelerate the merging processes, which will usually take
> place between an external file (which needs to be parsed
> anyway) and an internal one, which as things are now could
> be XLIFF, pickled or DB access. I would love to compare the
> performance of the last two approaches.
>
> Javier



Reply to: