inotify bindings

[Lennart Kolmodin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Stewart wrote:
| agl:
|> On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts
|> <duncan.coutts at worc.ox.ac.uk> wrote:
|>>  Could you give us a comparison of the existing hinotify package and
your
|>>  new system-inotify package?
|> Blink. Drat.
|>
|> I swear I  searched on Hackage yesterday for inotify and only saw the
|> GrowlNotify package. I guess I mistyped.
|>
|> Sorry about that. Can you delete system-inotify from Hackage? Probably
|> best not to have two, almost identical, packages.

Very interesting to see another lib solving the same problem, with
somewhat different approaches :)

| Well, at least do a merge first :)

Lets see where they differ:

System-inotify provides a lower level interface where you call a 'next'
function to get the next event, while the hinotify lib let you register
callbacks to each watch which are then called when a event happen.

The events in system-inotify is pretty much a 1:1 to the C event, while
hinotify extracts the pieces set in the event into different constructors.
Compare:
data Event = Event { evwatch :: Watch
~                   , evevents :: [ChangeEvent] -- Accessed, for example
~                   , evalerts :: [Alert]
~                   , evcookie :: Word32
~                   , evname :: B.ByteString
~                   } deriving (Show)
to:
data Event =
~      Accessed
~        { isDirectory :: Bool
~        , maybeFilePath :: Maybe FilePath
~        }
~      | ...
The latter event is passed to the callback to the particular watch, thus
it does not contain as much data.

Learning from the experience in bos blog[1]  it is interesting to
provide a lower level of abstraction too, which the higher level could
be built on top.

Neither of the packages delay the reading of events[1].

hinotify tries to be thread safe. System-inotify too, but I think it
requires a patch or two before it really is.

They are both small libs, and could both easily be adapted. I like the
approach with several constructors for the Event data type, as the
programmer can see what information is actually set for each event. For
the hinotify lib, the callback API should probably be extracted into a
separate module, so that both lower and higher APIs available.

| There's probably documentation, at a minimum, that can be salvaged.

Both packages refer to the docs upstream, not heavily documented
themselves. :)

| This is a rather novel situation for the Haskell community -- we're now
| to assume that a library has already been written, and is on hackage,
| rather than assuming no one's done it yet :-)

Hah, yes. :)

| Kudos to the Cabal and Hackage devs!

Indeed.

Cheers,
~  Lennart Kolmodin


[1]
http://www.serpentine.com/blog/2008/01/04/why-you-should-not-use-pyinotify/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6Tt24txYG4KUCuERAjY8AJ4+7LkNsBrpa1MQQSgB97JuSNzVzACdFd7D
TUo+vgMqPJyBojYxvrtpOts=
=N+wK
-----END PGP SIGNATURE-----