externals
Randall Lee Reetz
randall at randallreetz.com
Thu Jan 22 13:14:22 EST 2009
So, it appears that most OS's now have mechanisms for real time
publishing of files system events in real time. The platform of
interest to me is the Mac... OS X is evolving a set of protocols and
tools to deal with this opportunity. Specifically, a low level event
publisher called fslogger and a systems level accumulative log file
called "" which attempts to archive these events as they are
published. In the old pre-log scheme, apps and processes needing to
react to file system changes would subscribe directly to receive
fsEvents fire-hose of data. Spotlight, Apple's user level disk
directory index and search system, is the primary official subscriber
to this data stream. Receiving the fslogger data is one thing, then
the subscriber code must parse the stream and filter it for domain
specific events. But the real potential for problems come to play if
the subscriber intends to actively react to file system events
through functions that cause other file system events. If your code
intends to move a file or create an alias of a file each time one is
created or moved, and this file system events will trigger yet more
reactive events, It should be obvious that undue recursion will arise
and will need therefore to be dealt with proactively before the
resulting feedback loop gets out of control. Specifically, any
process or app that intends to react to file system events through
the creation of other file system events will need to actively track
those events its own code causes and filter these events from the cue
of events it reacts to.
Still, the mechanisms appear to exist for real time tracking of file
system events as they occur. I downloaded an app called fsEventer
which provides a visual representation of file system events as they
happen. I wrote a stack that created a hundred text files within a
folder and tested the performance with fsEventer running and then
without. With fsEventer app running, file system events were almost
two and a half times slower. Of course, this only shows how a real
time graphical display of file system events will slow down file
system I/O... which is to be expected. Both tests were run while the
file system event API running... it is always running!
What I am still not able to understand, and this probably has more to
do with the fact that I am more an interface and interaction designer
than a deep systems-level programmer, is how to send xtalk events to
xtalk clients (projects, stacks, and standalones). What is the intra-
application communication protocol that would allow for the sending
of xtalk messages to xtalk clients? Another tack would be to write a
stack that subscribed directly to the API that sflogger subscribes
to. Any ideas? Anyone willing to attempt this code as an external?
Randall
On Jan 22, 2009, at 2:03 AM, Luis wrote:
> Hiya,
>
> Google glasses on:
>
> http://www.macosxhints.com/article.php?story=20060817044149264
>
> http://www.ibm.com/developerworks/linux/library/l-ubuntu-
> inotify/ (OS X is in there too)
>
> http://developer.apple.com/mac/articles/cocoa/
> filesystemevents.html (DIY)
>
> http://oss.sgi.com/projects/fam/ (FAM: Check the Links page)
> http://www.gnome.org/~veillard/gamin/ (FAM subset)
>
> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
> (I'm assuming this has command line options too)
>
> And then writing a Rev front end to these command line tools?
>
> Cheers,
>
> Luis.
>
>
> On 21 Jan 2009, at 17:46, Randall Reetz wrote:
>
>> Defeats the purpose (real time, and universal)!
>>
>> -----Original Message-----
>> From: "viktoras d." <viktoras at ekoinf.net>
>> To: "How to use Revolution" <use-revolution at lists.runrev.com>
>> Sent: 1/21/2009 2:27 AM
>> Subject: Re: externals
>>
>> Hi,
>>
>> why not instead let user choose folders or files that should be
>> monitored and then monitor these by comparing files (get files
>> etc...),
>> folders (get folders) regularly. Use recursion to get into sub
>> folders,
>> etc. Revolution is fast enough to do this efficiently.
>>
>> Best wishes
>> Viktoras
>>>
>>> I am asking for outside help here. An intermediate application
>>> that would launch at startup and listen to the flile system event
>>> loop... Waiting for user defined events and sending them out to
>>> my reactor app. (or any other stack or app so inclined).
>>>
>>> I dont write binding code... Just xtalk... So i am dependent on
>>> that other dark art called "the nerd" for deep access to system
>>> processing.
>>> Randall
>>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list