-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Don Stewart wrote: | agl: |> On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts |> 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-----