hmm; Syncing files/folders is a relatively easy job and is much like an intelegent copy;
copy A->B if/only if date of A younger than that B.
Second consideration is 'Which system is the "master" and considered to always be the current copy'? With a single master, it's a snap, but if non-master version get modified independently, then you can run in circles a->b; b'->c and b'->back to a.
Third issue is the DB representation. Take for example a graphic file of which there are several formats; eg JPG, GIF, PNG. Getting a DB field to hold an arbitrary object is usually done with a field type BLOB which is just a flock of unstructured bits.
Inserting JPG->Blob(graphic) is fine, but how then do you store the GIF & PNG?
One approach might be a table of two fields
* objectType
* objectData
insert into objectName=graphicFileName,
objectType = "JPG",
objectData(x) table SYNCDATA;
defining objectType to be one of {JPG,GIF,PNG,HTML,CSS,JS} would then allow
SYNCDATA to hold all types of webpage contents.
Retreival then would have access to the file type in the objectType field,
the object itself, and the original fileName from objectName.
As a webpage can be a collection of files sent to the browser;
< script type=javascript src=filename > < / script >
< style type=text/css src=cssfilename > < / style>
you may need a 'parentObjectName' to relate where the pieces belong
and you have a BIG problem parsing and reassembling html where tags
are embedded within the file itself rather that neatly externalized with src=x or href=y
Code:
<html><head>
<script LANGUAGE="JavaScript">
<!-- Begin JavaScript ---- scroller for status bar
function scrollit(seed) { ....
}
</script>
<script src=emv.js ></script>
</head>
<body>
</body></html>
For this, IGNORE the inline stuff and just save the HTML which implicitly saves the embeds.
Having come this far, it is starting to look like a Content Management System(CMS) - -
Is that your intent?
