PDA

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