Girder 3.1 payload data

[Ron]

make the strings always meaningful. This is a bit less of an issue, though, now that EventString can be renamed.

I'm not quite sure what you mean... Eventstrings didn't even have a name before...


Am I right in thinking that GetPayload works in a RegisterCB in the straightforward way?

yep just call GetPayload. ( Mind it doesn't have to be a string! Can be arbritrary binary data.)


Is there a syntax for ParseGirderRegEx that expands the payload?

Just pass the payload data to the parser, should not be a problem.

This is completely new code, so if you find anything strange let me know so we can sort it out!

<font size=-1>[ This Message was edited by: RonB on 2002-03-10 21:15 ]</font>

[Ron]

Ah I see DVDSpy internal stuff. I was confused with the girder stuff.

[Ron]

Aaaah I see, [pl?] meant payload.

Might not be a good idea, because payload can be any kind of data, not just text. Do you think that the payload should be limited to text ?

[Ron]

Sounds good.... After the second rewrite, ( Yeah Mark I should have listened XML is too slow :smile: ) I'll get right to this.

[Ron]

The fileformat will stay XML, just the internal data storage will be just a normal tree.

[Ron]

I think I like Mark's suggestion. How about using this ?

[Ron]

Yes, but isn't expanding the string the duty of the action that actually uses the register?

<font size=-1>[ This Message was edited by: RonB on 2002-03-14 08:04 ]</font>

[Ron]

Okay, I'll do the expansion during the setreg.

[Ron]

beta12c has this change.

[Ron]

Only the plugin settextregister does this.

[Ron]

I see. Let me adjust that.

[Mark F]

I agree with applying a bit of structure to the payload to allow interoperability. For future expandability, could we agree to allow multiple NULL-terminated strings at the start of the payload? A NULL string (0 length) would signify the end of the strings. This could work much like ARGV processing.

Anything in the payload after the strings could be binary data.

If the Girder register parser (ParseGirderRegEx) was enhanced to use a {PLX} syntax (payload string X), plugins (like LCD and OSD) wouldn't need to change much to support multiple pay load strings.

Plugins that generate payloads would need to be documented with which strings are what. (title, time elapsed, artist, etc.)

What do you think?

_________________
Mark F

<font size=-1>[ This Message was edited by: Mark F on 2002-03-11 15:58 ]</font>

[Mark F]

XML is too slow
I'm sorry I was right. :sad: XML has some very nice characteristics.

[Mark F]

To allow the null string to be embedded in the set of strings, you could include a single byte, number of strings (ARGC), at the start of the data.

A binary only payload would still start with a 0 for the number of strings and a mixed payload would have the binary data immediately following the last null of the last string.

[MMcM]

I've just gotten around to downloading the 3.1 beta. There have been other demands on my time.

It looks like it ought to be easy to convert DVDSpy and LCD to use the new synchronous payload support. Hopefully I can get to this before too long. I'll also update Logger to know about payloads (I have a version that knows about associated text registers, but it does not look like it will have a very long lifetime.)

I guess everyone will just have to live through another spy event string renaming. :wink: Maybe I can get rid of the numbers and make the strings always meaningful. This is a bit less of an issue, though, now that EventString can be renamed.

Am I right in thinking that GetPayload works in a RegisterCB in the straightforward way?

Is there a syntax for ParseGirderRegEx that expands the payload? LCD can display straight from the payload, as it does now straight from the text register. But some of the actions in the sample add a little formatting and so tell LCD to display a string that contains [tregn]. They'll need something equivalent. Also, there are people using DVDSpy with OSD.

[MMcM]

Sorry I wasn't clear enough. I need some escape that can be placed in the string passed to the parser that expands into the contents of the current payload (which it will assume to be text characters). So, where one puts /[treg4] now, one would put /[pl?] as the second half of an elapsed/total display.

<font size=-1>[ This Message was edited by: MMcM on 2002-03-10 21:50 ]</font>

[MMcM]

It's not just internal. This new escape that I am requesting has to be supported by ParseGirderRegEx, since we want it to work to put it into the display string given to the OSD popup plugin.

Although the DVDSpy and LCD plugins are closely allied, their communication should not involve mechanisms or conventions that nothing else uses. The synchronous payload data should be available to any action that knows about strings in the Girder standard way, just as the text registers were.

[MMcM]

By pl? I meant to indicate that I don't myself care what the escape looks like. Sorry for creating any additional confusion.

I like the idea of allowing non-text payloads, since something might be able to use them down the road. The first command of the action would then have to be more specific to the source.

We could just define the new escape to insert all of the payload bytes into the result string, on the assumption that they are text. Using it with non-text payloads would simply be in the "well, don't do that then" category of problems. (After all, you can program OnGirderOpen to shut down the machine, but you wouldn't.)

Another possibility would be to define the escape to insert up to the payload length bytes, stopping before the first null byte. Then, by convention, non-text payloads could start with a null byte. And, again by convention, text payloads could include a null byte in their count, like with WM_COPYDATA. The little bit of redundancy gives some extra clarity as to what's involved.

[MMcM]

Spy events that have multiple logical payloads send multiple events because they only send state that has changed. This is the origin of the digit suffixes, which I plan to replace with something more meaningful as part of this conversion. That said, I have no problem with conventions for multiple strings.

There are payloads that can legitimately be the empty string. No title, no PSIP data, etc. We could just say that those cannot occur earlier in a sequence of strings. Or we could relax the definition of the new [pln] to take the total length into account rather than stopping at the first empty string. Then [pl1] would never accidentally display binary data, but [pl9] might.

Arrays of string pointers like ARGV have the benefit of distinguishing the null pointer from the empty string. To do roughly this in the context of a block of bytes that must travel across address spaces, you could have a sequence of four-byte integers that gave byte offsets for null-terminated strings, ending with a four-byte zero. I think that's more trouble than it's worth, though.

[MMcM]

Mark's proposal sounds fine to me too.
First byte is the number of null-terminated strings, which follow immediately. Total length of payload includes this byte, the lengths of all the strings, including their ending null bytes, and the length of any binary data that follows the last string. [pln] inserts the nth string into the reg expansion; it inserts nothing if n is out of range.

[MMcM]

I am sending Ron updates to some plug-ins for payloads.

A new version of Logger that optionally displays payloads. It shows each string payload and the first few hex bytes of any binary payload.

A new version of LCD that can display the contents of a string payload.

A new version of DVDSpy (and all its various hooks) that uses payloads instead of text registers. I have not done comprehensive testing of this, yet. So, it too should be considered beta quality. I hope that there are some other DVDSpy users among those testing 3.1.

[MMcM]

It would be nice if Set Text Register expanded its argument string. Then it could be used to copy a payload into a text register.

[MMcM]

I'm actually not a big fan of recursive expansion; it causes problems in the face of arbitrary data. But more fundamentally, in this case, it is a timing issue.

I want to write a sample DVD -> OSD multi-line displayer. Each event will supply a piece of the display to be assembled. I need to grab the payload right away and put it into one of several unique registers. Leaving [pld1] to be expanded later doesn't work.

[MMcM]

Hmm. I'm not seeing it. I used the .ZIP installer (on this particular machine), but it says I have beta 12c.


From Register Display, put x into treg2.
Add Command
Girder > Set Text Reg
Reg 3
[treg2]
F5
Register Display
Reg 3 has [treg2], not x.

[MMcM]

Do you mean TSetGirderStrRegister in the plug-in API or some separate SetTextRegister plug-in (I don't see one)?

All along I meant the Set Text Register action, not the function. I agree that the caller of the function can expand first if they so choose, so the function itself need not. But I need the command action to expand for the reason I mentioned (see the DVD2OSD sample in DVDSpy). I cannot rely on the reader of the register later expanding recursively.

I'm really sorry for causing so much confusion.