writing and reading from files

[Bron Gondwana]

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