View Full Version : payload for internet envent (feature request)
Ron
October 13th, 2002, 12:55 PM
I've just finished extending Girder to have a "binary" field, thus allowing the plugins to add abritrary data to a command. I needed this for the eventserver client plugin because I'd used up all the available fields :wink: And other developers have been asking for this too.
I'm now testing this binary field and extending the plugin, as my time currently is limited ( as i said earlier my classes started again ) I cannot make any promises when this will be finished.
-Ron
ot: for the interested developers, the API now also supports the new register types.
Ron
October 13th, 2002, 12:55 PM
Sounds interesting. I'll look into this, if I can add it without braking the protocol.
Ron
October 13th, 2002, 12:55 PM
That will break compatibility. Just think of the people that used eventstrings with a space.
Ron
October 13th, 2002, 12:55 PM
I was thinking this of adding a command "payload" to the protocol, everything after that until the newline would be used as the payload for the next eventstring that is passed.
<font size=-1>[ This Message was edited by: RonB on 2002-04-02 23:55 ]</font>
Mark F
October 13th, 2002, 12:55 PM
If the INetServer would place the whole string into pld1 then the Variable Manipulation Script stuff could be used to parse it any way you'd like.
JayCee
October 13th, 2002, 12:55 PM
Don't know if this has been covered before, I didn't see any references:
I would like to pass an additional string (payload) with an internt command and have that stored in a text register. Then I could send stuff like this from my "remote control webpad" to girder
Winamp_AddFile c:mediamusicartistsong.mp3
and have winamp enque the specified file.
Ron?
cu jc
JayCee
October 13th, 2002, 12:55 PM
Treat everything in front of a space as the command string, everything after the space as the parameter?
cu jc
JayCee
October 13th, 2002, 12:55 PM
But then you'd have the problem of Girder having to decide what the correct eventstring is. Maybe there could be a second string after the eventstring that is the payload.
Maybe something like:
<- accept
-> EventString n
-> Parameter1 n
-> Parameter2 n
-> Parametern n
-> closen
JayCee
October 13th, 2002, 12:55 PM
Sounds good to me too...
(When will this be ready? <g,d&r>)
cu jc
Powered by vBulletin® Version 4.1.8 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.