writing and reading from files

arun kumar arunkumar0107 at gmail.com
Thu Jan 22 17:10:52 EST 2009

thanks Bron and Etan for replying.

you are right,Bron The main idea of the plugin is to provide automatic
translation feature.


The main idea is to make translation feature, user transparent. Also
please note that currently Webservices (from internet)  are used to
get the text translated. So i think the delay can be really a major
factor......if any better idea is there, please let me know


On 1/22/09, Bron Gondwana <brong at fastmail.fm> wrote:
> On Thu, 22 Jan 2009 14:10 -0500, "Etan Reisner"
> <pidgin at unreliablesource.net> wrote:
>> On Thu, Jan 22, 2009 at 10:18:40PM +1100, Bron Gondwana wrote:
>> <snip>
>> > I'm writting this reply in vim, which was invoked by mutt by writing
>> > your message, pre-quoted and all no doubt, into a temporary file.  When
>> > vim has finished editing the file, it will close, and mutt will come
>> > back again asking me if I want to make any further changes or just send
>> > the message.
>> >
>> > It's a pretty standard paradigm.  Other programs I can think of off the
>> > top of my head that do this include visudo and crontab -e.
>> Yes, it is pretty standard for applications that work on single tasks at
>> a
>> time and which block until completion of the sub-task. It does not work,
>> at all, for something like an IM client where people expect to be able to
>> have multiple conversations running at once. That is just not an
>> acceptable usage model for an IM client and thus an unacceptable design
>> model for a pidgin plugin.
> It's also acceptable as a simple and easy to test way to proof-of-concept
> your design in a limited environment like, I dunno, "my first plugin"[tm].
> At the other end from my pidgin is djabberd.  It's a pretty funky piece of
> epoll based non-blocking Perl.
> You know what - it ships with a stack of synchronous plugins for testing and
> initial development, along with an asynchronous interface that you're going
> to want to use if you ever want to scale later - but for initial testing or
> a small site, synchronous tends to work out mostly fine.
> And you know what, it's eleventy zillion times easier to debug.
> I can see we're never going to agree on this, so I'm going to leave this
> issue alone now...
>> Again, the assumption is that blocking for an out-of-band process is not
>> an acceptable solution for just about anything in a pidgin plugin. There
>> are of course exceptions and it is up to the plugin author to understand
>> their problem domain well enough to make those decisions.
> ... but man, of all the projects I use and watch, this has to be the one
> which is the most hostile to new people who come along without a perfect
> understanding of the issues involved and who want to start with something
> relatively simple that, I dunno, solves their problems.
> I bet you if you gave the author of the initial request an interface that
> wrote each incoming message to, say, an XML file with the routing
> information and message contents in a standard format, and exec()ed a
> configurable path with that filename as the first argument - then pidgin
> blocked until the program finished and read back the same file - they'd
> be happy.  And they wouldn't notice the blocking in practice.
> Bron.
> --
>   Bron Gondwana
>   brong at fastmail.fm
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel

More information about the Devel mailing list