Client to Server Communication

[tmiranda]

I think i know the answer to this already, but it can't hurt to ask. Has anybody created a class that allows easy communication between a SageClient and the Sage server? I know I can use jetty to pass strings back and forth but that's a bit of work I'd like to avoid.

I'm not looking for anything fancy, just a simple way to pass a piece of data between a SageClient and the Sage server.

Thanks,

Tom

[GKusnick]

Well, the simplest way is probably SetServerProperty, but then the server would have to poll the property periodically to see if it's changed. But if it doesn't change very often, and the server routinely reads it from the property file anyway, then that could be the best option.

If you need real-time two-way communication, with messages going back and forth continuously, then a TCP socket might be a good choice.

You could also look at RMI, but I don't have any hands-on experience with that.

I guess Jetty could work if you already have a dependency on it anyway, but it seems like overkill just for this.

To some degree the choice is going to depend on what you're trying to accomplish and how frequent and responsive you need it to be.

[PLUCKYHD]

You can pass it to the uicontext of clients from the server and I believe visa versa using SageTV.apiUI().

I have never used it but I have been told and believe it works like this.

API call GetConnectedClients() will give you IDs (IPort) that can be used to identify a SageTVClient connection. You can then specify one of those for the uiContext argument to the SageTV.apiUI call in order to have that command executed within the SageTVClient itself.

That is all from how Narflex explained it would work I believe.

There is also the Ortus MQ (I believe that is the name it) but I have never used that either.

Edit: Greg and I must have been posting at the same time I also use the SetServerproperty allot but you have to poll to get the change.

[tmiranda]

Thanks Greg and Plucky,

I don't want to execute widget code, so I think I will stay away from he UIContext approach.

I'm working on the CommercialDetector plugin and there are two or three things that I need to co-ordinate between the server and the client:

1. If the SageClient requests comskip to be run on a MediaFile, I want it to pass a message to the server telling it to run comskip. I just need the the MediaFile ID so I could pass that as a String. I'd need a way to make sure the server received the info so another request by the client is not posted before the first one was picked up by the server.

2. I need a way to poll the server from a client to see if the server is processing a file. That's easy to do with a ServerProperty.

3. I need a way to poll the server to see if a particular file is being processed. That can easily be done using the ServerProperty as well.

I suppose the easiest way will be to build some code to take care of item 1 using ServerProperty.

Thanks,

Tom

[GKusnick]

Actually for that you might consider putting a custom "ComskipStatus" metadata property on the MediaFile itself using Get/SetMediaFileMetadata. So clients would mark MediaFiles for comskip processing, and the server would periodically do a FilterByMethod call to find MediaFiles that have been marked for processing, and change their status to "in progress" and then "completed" as appropriate. Clients can do a similar filtering call to display the processing queue. Seems to me this covers all your needs, although there are perhaps some synchronization issues to think about.

[Slugger]

Originally Posted by GKusnick

Seems to me this covers all your needs, although there are perhaps some synchronization issues to think about.

Definitely watch out for synchronization issues. If you don't think about this before starting, you'll get very confused, very quickly when things start going crazy on you.

[jphipps]

The ortus-mq plugin that I created uses JMS queueing to communicate between the various clients and servers. It uses events that you can can be sent to the server/clients/broadcast that can trigger methods similar to the Sage events. The plugin has a sample module for writing an event class. Let me know if you are interested, I can send you more info about it...

Thanks,
Jeff

[tmiranda]

Thanks for all the feedback.

Jeff, yes I am interested in learning about your MQ plugin. I'll PM you my email address. Hopefully it is something easy to use, because all I need to do is create a FIFO queue of int's.

I whipped up something that uses ServerProperty() but I'm worried about synchronization errors as Slugger pointed out. I made all of the methods that access or change the property synchronized, but I know that won't synchronize things across JVMs.

Nothing I am doing is really critical. The worst thing that can happen is a file does not get an edl generated.

[tmiranda]

I was thinking about this a little more last night and it occured to me that Sage already has the basic functionality built into the new sageEvent() plugin method. All we would need is a way to define new events instead of just the core events that are now available.

Does it make sense to suggest this to Sage?

[PLUCKYHD]

Originally Posted by tmiranda

I was thinking about this a little more last night and it occured to me that Sage already has the basic functionality built into the new sageEvent() plugin method. All we would need is a way to define new events instead of just the core events that are now available.

Does it make sense to suggest this to Sage?

The MQ method does just that.

Having sage do custom Listeners and the Fire Listeners api I could see causing more problems but would be a nice feature if people used it right.

[Slugger]

You don't need MQ to do this, you can fire custom events with the Sage API already. The SageTVPluginRegistry.postEvent(String eventName, Map<String, Object> args) method is already there and can be used to post any kind of custom event. The only caveat is that eventName should not be the name of any defined core event (though this isn't enforced, from what I can tell, but will break/crash a lot of plugins and probably the core itself if one were to fire a custom event with the same name as a core event and not provide the expected args map). Also, the eventName shouldn't be the same as any other custom event fired by other plugins (and this definitely isn't enforced). To avoid these issues, I simply prefix my custom event names with my plugin id (i.e. all my custom events that are fired by SageAlert are prefixed with "SageAlert_"). Following that simple rule will avoid all the caveats listed above.

The other issue you may run into is I'm not sure if custom events fired by a client are propagated to the server. My gut tells me they're not, but I have never tried it. I'd be surprised if they were (unless the recent change to support this for media playback events in the core was a more general change to just fire all client events on the server as well).

[PLUCKYHD]

Well. Completely missed that in the API an I would bet they are fired on the client as well.

[Slugger]

Client, yes, but I'm not so sure a custom event fired by a client would also fire in the server's JVM. Someone would have to test that and report back (or Narflex could answer that as well). I've had no reason to experiment with that myself so I can't answer it one way or the other.

[jphipps]

I asked that same question to Sage, and they said it only fired in the JVM that the post method was executed in...

Thanks,
Jeff

[Slugger]

Originally Posted by jphipps

I asked that same question to Sage, and they said it only fired in the JVM that the post method was executed in...

Thanks,
Jeff

Was this before or after the recent change in 7.0.12 that fired the media playback events from the client into the server's JVM as well? I guess what I'm wondering is if that change/fix was just for those three core events or was the change more generic such that all client events are now propagated to the server's JVM? My gut says it's the former, but that's purely speculation on my part.

[jphipps]

I don't really recall the version when I had posted the question to Sage. I haven't tried the custom posting of events, but I know from the debug logging in the ortus-mq plugin, that majority of the plugins either fire on the server or client and haven't noticed many that fired on both. I guess we would have to propose the question to Sage again if that has changed.

Thanks,
Jeff

[tmiranda]

Last night I tried creating my own event to see if firing it on the client would fire it on the server. Nope. I'm running 7.0.15.

Tom

[Slugger]

Originally Posted by tmiranda

Last night I tried creating my own event to see if firing it on the client would fire it on the server. Nope. I'm running 7.0.15.

Tom

Kind of figured it'd be that way... if the values of the arg map were mandated to be serializable then adding this support wouldn't be too bad, but since that's not the case, it's no trivial task to serialize the map from the client across to the server JVM. There are other ways to get events across to the server though (MQ, Jetty, etc.). Though the Sage API would be by far the easiest/most intuitive for most plugin devs.

[tmiranda]

Originally Posted by Slugger

it's no trivial task to serialize the map from the client across to the server JVM.

The basic "guts" must be in there already because some events that are fired on the server are also fired on clients. That implies there is a way for the client to tell the server it's subscribed to a particular event, and a way for the server to send that event to the client.

It wouldn't be trivial for Sage to implement, but even if the API only allowed a small number data types, all of which must be serializable, having a built in Sage server to Sage Client mechanism would be VERY useful.

Tom

[Slugger]

Originally Posted by tmiranda

The basic "guts" must be in there already because some events that are fired on the server are also fired on clients. That implies there is a way for the client to tell the server it's subscribed to a particular event, and a way for the server to send that event to the client.

I don't believe this is true. The opposite is true, namely, some events fired by a client are also fired in the server JVM (and those are exactly the PlaybackStarted/Stopped/Finished events). AFAIK, no events fired by a server are ever fired into a client's JVM. With that said, you're still right in that the "guts" are there to allow a client to propagate an event to the server JVM (though the opposite direction does not exist, AFAIK). But I'm assuming it's custom code and specific to the three events in question - probably not much different than what the Ortus MQ plugin was/is doing, but the communication between the client and server is private/proprietary. If whatever serialization is being done were shared then it could possibly be extended to custom events. Perhaps an extension to the Sage API such as SageTVRegistry.postSerializableEvent(String, Map<String, Serializable>) could be added?