I was thinking about this. Another very simple way to force the sync
plugin to load without messing around with files names and
load/unload/update commands would be to put the sync plugin in the
root of Application/Plugins, and all other plugins in a subdirectory
(Application/Plugins/Plugins).
Bernard
On Fri, Feb 29, 2008 at 7:58 PM, Bernard Lebel <3dbernard(at)gmail.com> wrote:
> On Fri, Feb 29, 2008 at 5:05 PM, Matt Lind <mlind(at)carbinestudios.com> wrote:
> > Could you elaborate here? What do you mean by, "also allowed us to
> > change the log commands preference without having reset to true by XSI,
> > by modifying the user preference file."
>
> Having the command logging preference turned on slows down XSI. So
> unless a user explicetely requires it, it had to be turned off.
>
> The problem is that if the preference is true, and that you set it to
> false in a script, XSI will automatically set it back to true after
> execution. I believe this decision was made because of users abusing
> support with having commands no longer logged without knowing why.
>
> So the only way to turn off command logging is to not do it with a
> script that is executed in the XSI scripting engine.
>
> The file %XSI_USERROOT%\Data\Preferences\default.xsipref has the
> command logging preference. Over here it's on line 122:
> scripting.cmdlog = True
> If you change this value to False and save the file, then you've
> effectively disabled command logging without risking having it turned
> to True by XSI.
>
> Now the thing is that some users actually want command logging. You
> can't force them to not have it. So one solution is to have the user
> value recorded in a database, and query the database to find out the
> value the user really wants.
>
> How you perform this modification is entirely up to you. At big bang a
> colleague wrote a JScript script that we would use to start XSI.
> The script did many things:
> - request a php page through an httprequest object (this is one handy
> application of an apache server) so the user value can be retrieve
> - rewrite the xsipref file
> - launch the XSI batch file and die
>
> The script would also control the log file (to cut a long story short,
> this was to make sure the last log would not get overwritten by a new
> launch of XSI, and could be sent to a network location so that we
> could look at it without bothering the user).
>
>
> Speaking of apache server. It is the same process to synchronize the
> local workgroup.
> The JScript script would send a GET request for a php file to the
> apache server (via a XMLRequest object), which would return an XML
> with all the network workgroup files, including their mtime and an
> http url to access them via the http protocol.
> Then the JScript file would compare the XML mtimes vs the local
> mtimes. For each server file more recent, it would send a single http
> request to download the server file, using the http url provided in
> the XML file, and write it in the local workgroup. Worked very well.
>
> Doing things this way allowed to not even bother about UpdatePlugins()
> and stability. In fact, you don't even need to have the local
> workgroup installed, as it will be created and populated at the first
> launch.
>
> The impact of such processes is that there is a delay between the
> moment you double-click the launch icon and the moment XSI actually
> starts. Unless you were downloading the entire workgroup, it was 1-2
> seconds.
>
>
>
>
>
>
>
>
> > Unfortunately, I don't have any experience with Apache servers or the
> > like. I'd like to get more involved in that area but don't know where
> > to begin.
>
> I cannot tell you how to install and configure an apache server.
> That's what sysadmins are there for :-)
> From what I know it should run on Windows, but former sysadmin
> colleagues advised me to only run one on a linux box.
>
> I can only recommend getting familiar with the XMLRequest and
> WinHttpRequest objects (they share lots of functionality), Ajax and
> PHP. Since you're already proficient with JavaScript, the request
> objects should be very easy. Examples abound on the internet. PHP is
> also quite an easy language imo. The problem is that if you go the
> XMLRequest/Ajax route, you'll hardly make it without learning PHP at
> the same time, Ajax being the client-side code, while PHP being the
> server-side.
>
> Getting the basics of these nailed down will get you a long way.
>
> I know no other use of an apache server than everything I already
> mentioned, unfortunately.
>
>
>
>
>
>
> > Using your filenames as an example, if I needed to update async.js, I
> > can't do it when XSI is loading because async.js will be executing. The
> > only other time I can pull the latest version of async.js and not get in
> > the way of the user would be when XSI terminates. I can then unload the
> > plugin manually from XSI and replace it. Next time XSI starts, it will
> > use the new version of async.js. This is useful for occasions where the
> > production pipeline changes affecting tool delivery.
>
> The idea is to never have to update the async.js plugin. Once it's
> written, tested and deployed, it must be only in the most major
> circumstances that this specific plugin should be updated. Only other
> plugins are updated. Again, using LoadPlugin()/UpdatePlugins() through
> a loader plugin should completely eliminate the problem.
>
>
> Bernard
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
