Mass Instance Change possible?

[kwaugh]

All -

I have a need to move a bunch of actions that I need to move from one instance of girder to a new one (and I can't change the instance ID, as that will make some other actions fubar).

When I look at the details of the action, I see that the "actionID" at the top lists which instance the action will take place on. Is it possible to edit the action ID so that I can move the action from one girder instance to another.

Or, is there some other way to do a "mass" instance change?

Thanks in advance,

K

[Rob H]

I don't think there's currently any way to do this I'm afraid other than going through each action one at a time.

[kwaugh]

I even opened up the .ccf file in a hex editor to see if I could find a way to change it there.

Oh well!

[Ben S]

Unfortunately no. Sorry.

[Barf]

Tonto comes with a quite capable API for accessing and manipulating ccfs. With that, "everything" can be done, at least for those of us proficient in Java. However, Tonto cannot open (most) NR ccfs. Any chance along these lines?

Is there an API for NR ccfs (planned)? Or even a documenation of the Promixis ccf extensions?

[Rob H]

I think there might be more mileage in using XML, not necessarily as a native format but as export/import options.

[Barf]

XML would certainly be an alternative (but then done correctly, with a scheme or DTD). Actually, the difference is not that drastic: Given a documented API, an XML exporter and an importer can be written in a very short time; conversly, given an XML format (with documented semantics (i.e. a DTD or a Schema) AND documented semantics), "API operations" can instead be performed on (e.g.) the corresponding DOM tree, using for example DOM/SAX libraries, or something like XSLT.

I would undoubtly put this (API or XML) as #1 on my feature request list for "NR 3". "Control/Automate/Enjoy" should apply to the creation of CCF files too ;-)

[Ben S]

You keep saying "documented". What does that word mean? :)

Agree about the need, Barf. It's on my list for a future rev of NRD.

[Barf]

You keep saying "documented". What does that word mean? :)

By a documented API, I mean that the vendor has defined, in a document, the syntax and semantics of the functions/classes making up the API. The vendor thus commits himself to this working, which is not to be changed (lightly). It is declared that these functions are "public"; available for the user to call. Prerequisites, incompatibilities, and side effects should also go into that document. Conversely, there should be no other side effects etc other than those documented. A bug (=discrepancy between described and actual functionallity) within these functions is a support issue for the vendor.

Conversely, using "undocumented functionallity" is a risky thing: It may change between minor releases; it may have unexpected side effects. If not working the way the user expects, first, it is unclear if it is a bug or not, since documentation does not exist. Secondly, since the functions were never released to the public anyhow, the vendor will (likely) refuse support.

Keywords are "supported", "public", and "committed".

AMEN. ;-)



Agree about the need, Barf. It's on my list for a future rev of NRD.

I am really happy to hear this.