<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Fri, 17 Feb 2012 05:24:48 -0800<br>> From: davep@confluence.org<br>> To: discuss@lists.osgeo.org<br>> Subject: [OSGeo-Discuss] any ideas on how to Monitor and Review 'random'   files?<br>> <br>> We are doing some brainstorming in order to come up with possible<br>> ideas of how to address a problem, so any thoughts, comments, or <br>> suggestions are welcome. The problem is outlined below.<br>> =============================================================<br>> <br>> Within a corporate environment the users have workstations<br>> running Microsoft Vista. All users have access to some<br>> network file shares, but different groups of users have<br>> access to different file shares. All file shares are<br>> using the NTFS filesystem.<br>> <br>> A group of users - call them the Workers - have a common<br>> file share that they use during the course of their business.<br>> When an "event" takes place, and for some time after, various<br>> Workers will add event-related files to the shared location.<br>> How such files are organized is up to the Workers. There is<br>> no technical mechanism (i.e. filesystem monitoring software)<br>> or procedural mechanism (i.e. business process) that currently<br>> exists that results in 'monitoring' the addition of, or changes to,<br>> the event-related files.<br><br>I recall an item in the visual basic idé (the visual programming environment) called a 'file-system-watcher'.</div><div>I never used it, so I cann't comment an further.<br><br>> A different user - call them the Reviewer - who works in a different<br>> part of the corporate organization, has a need to 'review and organize'<br>> some of the event-related files that are provided by the Workers.<br>> This process typically takes place 'after the event', however,<br>> event-related files might be added by the Workers well after the<br>> event took place (e.g. months or years later), so the Workers could<br>> be making updates during the same time period that the Reviewer is<br>> doing their 'reviewing and organizing'.<br>> <br>> For a particular event the Reviewer may want to review the<br>> event-related files, 'organize' them, and be informed when Workers<br>> add more files for that event. Eventually there may be a need to<br>> make a copy of some of the event-related files, based on criteria<br>> specified by the Reviewer.<br>> <br>> It may be possible to add software to the Reviewer's workstation<br>> to assist with this process, but it will be less likely to be<br>> able to deal with the Workers' workstations, and very unlikely<br>> to be able to deal with the servers hosting the file shares.<br><br>is that to be understood as .. they can view or download from, but not say make any scripts on the server ?</div><div><br>> Although this isn't really about "geospatial processing", there<br>> are some geospatial files involved in this process. As an example:<br>> - an event takes place - call it "ABC123"<br>> - a Worker who has files related to ABC123 will put the original<br>>    files, or copies, on a file share (e.g. some raster maps, some<br>>    shape files, some word processing documents, some emails, some<br>>    JPEG photos, KMZ files, etc.)<br>> - other Workers will also have files related to ABC123, and they<br>>    will also put them on the file share<br>> - the above process continues while the event ABC123 is 'active'<br>> - over time the initial set of "ABC123 files" will stabilize,<br>>    and there may not be any new files added very often<br>> - the Reviewer gets involved sometime after the event, and starts<br>>    with the set of files that exist at that point for event ABC123<br>> - the Reviewer may want to 'organize' the files for event ABC123,<br>>    however that might be able to be accomplished by 'organizing'<br>>    file metadata, rather than having to make copies of the ABC123<br>>    files and organizing the copies<br>> - when files for event ABC123 are updated (e.g. a Worker adds a<br>>    "One Year After" report for event ABC123), the Reviewer wants<br>>    to be able to know that there has been an update<br>> - at some point the 'organized files' for event ABC123 (and possibly<br>>    some 'notes' or 'metadata' about those files) will need to be<br>>    copied from the Workers' file share to another file share, in<br>>    order to preserve a copy of the files and to provide a location<br>>    to use for processing the files as they are loaded into a<br>>    'document management system' that the Reviewer uses<br>> (the last step of loading files into the document management system<br>> is already in place, and isn't part of the brainstorming exercise)<br><br></div><div>It's not a straightforward problem, so, I could imagine that I would tackle it by my process of working. Coding is the heaven of 'divide and concur' .. building a long list of involved files for starters would bring something to .. divide (read: organize). A way would be to mandate a process of registering files (ie by way of a form on a php/html-driven page). </div><div>I'll not attempt to feed my brain with the whole setup of your problem, but currently I'm sort of taking a run at dealing with an eqvivalent problem-set: administering a twitter-page (never been twittering thou - just exersizing my skills in html, css, javascript & php before the real deal: GIS). </div><div>No need to say that, if you've got a central page, you can collect information, and possible also generate different sorts of events from there, depending on the input. </div><div>My web-programming skills is comming up to be 2 weeks old ... but this was a brainstorm, right ;o)</div><div><br></div><div>Carsten</div>                                        </div></body>
</html>