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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
