Brad Langhorst schrieb: (...)
You might think I'm only complaining - I'm not. In fact, I'm trying to find weak points, to that we could come up with a better design. > The advantage of having a file on the server is that the admin does not > have to touch every machine (or use psexec) to get them all to sync up. > You bring up a good point about sets of machines... That would be a > PITA to deal with using psexec too. Still, WPKG Client has to attempt to read such a file every X minutes / hours. > Maybe it's better to put this feature in the profiles.xml where it could > enabled be on a per group basis. There is one slight problem with that: WPKG Client and wpkg.js are not very well integrated (it will change slowly in the future; right now, there are even problems with restarts initiated by wpkg.js etc.). This means, we would have to learn WPKG Client to read and parse files used by wpkg.js. Which means - parsing profiles.xml is not enough, and profiles can be also kept in "profiles" directory. > The value of X could be included as an attrib of the force_sync element > (or in the file) and could default to never. All right - this is why I don't like the "force_sync=1 / force_sync=0" idea. Assume we want to initiate a sync, so we put force_sync=1 there. The client syncs, but we see we forgot about something, so another sync is needed. Hmm, force_sync=2, force_sync=3, force_sync=n? Logically, how should it work? > I bet you could use the mac address of the nic to randomize the time > they sync up so you don't end up with bursts of activity. -- Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ wpkg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wpkg-users
