writing and reading from files

[Bron Gondwana]

On Wed, Jan 21, 2009 at 09:49:57PM -0500, Ethan Blanton wrote:
> Bron Gondwana spake unto us the following wisdom:
> > On Wed, Jan 21, 2009 at 03:04:53PM -0500, Etan Reisner wrote:
> > > That sounds like it is incredibly likely to introduce somewhat substantial
> > > delays into the display of incoming messages and likely to break thereby
> > > removing all ability to see incoming messages to me.
> > > 
> > > Did I miss something?
> > 
> > Yeah, modern desktop computers are hella-fast (especially if you put
> > /tmp on tmpfs or something) and fork is pretty cheap too.
> 
> This doesn't really tell the whole picture.  I'm glad you're trying to
> be friendly, but pointing out a poor solution as a poor solution
> *before* someone does the work of implementing it is a better idea
> than encouraging the poor solution.

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.

When I read the initial messages, I was thinking something along the
lines of an automatic translator, or LOLCATS filter for that matter.  A
program is invoked which does something to the file and then exits.
Pidgin would be expected to notice the exit and carry on processing.
Assuming the program does something smart like write a new file and then
atomically 'rename()' the file over the top of the original, that's 
actually pretty tidy.  If the program fails in any one of a million
ways that isn't going into an infinite loop, then either the original
text or the processed text is available in the file for pidgin.
 
> > Compared to the delays introduced by the network (ok, so my djabberd is
> > in New York, and I'm in Australia), this is nothing.  Invoking a simple
> > program to change the contents of a file is well under the human
> > noticability threshold these days - and if your system is so heavily
> > loaded that it's likely to a problem then all bets are already off -
> > pidgin itself could be swapped out for an indeterminate time.
> 
> A substantial issue here (and one which will likely lead to either real
> expense or nontrivial delays which are *well* within the realm of
> human ken) is that detecting file changes is Hard to do well and
> portably.  Polling the filesystem is still the best plan out there
> (some systems have better plans, but I'm not aware of multiple systems
> which have the *same* better plan), and that's Expensive.

I'm not reading it that an external daemon is sitting around waiting to
process files and dump them elsewhere.  I'm reading the request as a
plugin that launches and external process to deal with the file.  Maybe
we're at cross purposes here.  Yeah, detecting file changes is hard[tm],
though at least Windows has a recurive API for it.  Linux you roll your
own and hope you don't have a race condition in your "directory was
added/removed" code.

> I'm not sure at all what the original poster is *really* trying to
> accomplish, but communicating through files is almost certainly not
> the right solution.  The D-Bus API or a custom socket communication
> are probably more in line.
> 
> > Bron ( so let's try being positive about people's ideas )
> 
> Ethan ( so let's try being helpful )

Well, yeah.  That too :)  Maybe the question showed that the asker
didn't have a full handle on all the posibilities and the relative
merits or otherwise of them.  And indeed there may be a better way,
but temporary files and blocking that's 99% good is heaps better for 
a lot of "me and my friends" use-cases than the perfect solution 
that never gets finished.

Bron ( poking fun at everyone's favourite branch for fun and profit -
       I swear VV was -><- this close 5 years ago )