externals

[Randall Lee Reetz]

>> I had a look at the C source, and will be able to do a quick  
>> external Demo, but with the information above,
>> well, it seems a bit of a tricky path to go there !  What do you  
>> think ?
>>
>> Regards,
>> Thierry

Tricky path?  I have no idea.

 From what I have read, there are two file system event tracking  
systems... the first for system OS X 10.4 which forces all fs events  
out and can lead to buffer overloads, and the second for system OS X  
10.5 which writes to a log file when there are processing resources  
to do so... and sends notification after such epochs in which it did  
not have the resources and was not able to log all events.

The source I pointed you towards works with the 10.4 live publishing  
scheme (no log).  Which is great because I am using 10.4.11.  The  
later logging scheme might listen in on the same file system event  
publishing mechanism... I don't know.  Ideally, the external would  
work with both systems.  The idea of the log if you can and notify if  
you can't mechanism of 10.5 solution is that the client would respond  
to the buffer overload notification by initiating it's own event  
rectification by doing a manual scan of the file directory branch in  
question.

Because I have not used either system yet, I do not know how  
frequently this overload condition comes into play... the ratio of   
missed events to properly published events.

I do not know therefore if the "tricky path" referenced by the  
"Caveat" in the fslogger docs have the bases in the mechanism itself  
or the algorithmic choices made by the original writers of this  
published source code.

Either way, I would greatly appreciate a stab at an external that  
would make this fsevents data available to xtalk stacks and projects.

I think it would be wise of Rev as a company to work towards  
including this functionality (cross platform) into their products.    
There are ways to build protection into such capabilities to avoid  
any (or most) malware potential.

Thanks, Randall


On Jan 23, 2009, at 3:21 AM, François Chaplais wrote:

>
> Le 23 janv. 09 à 11:31, Thierry a écrit :
>
>> Hi  Randall,
>>
>>> Here is a reposting of a link to a page describing the files  
>>> system events reporter fslogger:
>>> http://osxbook.com/software/fslogger/
>>>
>>> If anyone has the inkling or the hankering to fuse this source  
>>> into an external for xTalk on the Mac...
>>> please please please let me know.
>>>>
>>
>> From fslogger Doc :
>>
>> Caveat:
>>
>> The interface that fslogger uses is private to Apple.
>> Currently, there is a caveat regarding the use of this interface  
>> by third parties (including fslogger).  <.....>
>> fslogger is meant to be a learning tool. If you use it, you must  
>> understand the aforementioned caveat.
>> ---------------
>>
>> I had a look at the C source, and will be able to do a quick  
>> external Demo, but with the information above,
>> well, it seems a bit of a tricky path to go there !  What do you  
>> think ?
>>
>> Regards,
>> Thierry
>>
>
> from what I have read, fslogger relies on a private API which is  
> used by spotlight. On the other hand, FSEvent, I think, is a public  
> API. I think it is interesting to have a look on a review of Time  
> Machine
> http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14
> which (Time Machine), incidentally, relies on FSEvents. The  
> interesting part lies in the compromises that the Apple engineers  
> had to made in order
> a) not constantly monitoring the file system activity, which can  
> bring the system to a virtual halt
> b) select the right granularity both in time and in files to have a  
> working backup which does not fill the backup disk in a few hours
> I think the "real time" requirement is too demanding; a suitable  
> time scale for scanning file events must be found that compromises  
> between reliability and system availibility.
>
> best regards,
> 	François
>
> _______________________________________________
> 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
>