writing and reading from files

[arun kumar]

thanks Bron and Etan for replying.

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

@Etan

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


cheers,
arun

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
>