Where would YOU put Sage's improvement priorities?

[Skirge01]

Originally Posted by tmiranda

Lesser graphics capability is certainly one issue. The other is that all extenders and placeshifters share the same JVM while each SageClient has its own JVM. Placeshifters and extenders also "run" on the Sage server while SageClients run on a totally separate machine. This means that all custom data needed (i.e. data your plugin needs and is not native to the Sage core) must be sent over the network. There are lots of "developer" plugins out there that help (that's why there are all of those library plugins out there that say "no need to install this directly") but it's still a PITA.

Consider this simple example. Let's say you want to create a music plugin that displays lyrics while a song is playing. Assume the lyrics are either embedded in the MP3 or are stored in a .lyrics file. All of this data is stored on the Sage server, not on the SageClient so you need to create a way (probably a java method) to get those lyrics so you can display them in the STV. Your java code (which is called from within the STV) needs to look like this:

if (running on a SageClient) {
  use some other method to get the lyrics from the Sage server
} else {
  get the lyrics from the machine you're running on (which will be the Sage server)
}

None of this is news to Sage or to any Plugin developers, it's just the way it is.

Thanks for taking the time to explain that. I do have some (very basic) programming experience (VBA mostly), so I do understand that. Does that mean that every data call needs to be an IF-THEN-ELSE (or similar) statement to determine whether the call needs to be made to the server or the client itself?

[Fuzzy]

Originally Posted by Skirge01

Thanks for taking the time to explain that. I do have some (very basic) programming experience (VBA mostly), so I do understand that. Does that mean that every data call needs to be an IF-THEN-ELSE (or similar) statement to determine whether the call needs to be made to the server or the client itself?

No, the API pretty much takes care of that.

[Skirge01]

Hehe... then it shouldn't be a big deal. j/k guys.

[Fuzzy]

toms example wouldn't be the way i'd do it though - it would make more sense to have a server side process that adds the lyrics to the sage database (custom metadata, or even a user record), then it can be accessed from any client side plugin in the same way.

[tmiranda]

Originally Posted by Fuzzy

toms example wouldn't be the way i'd do it though - it would make more sense to have a server side process that adds the lyrics to the sage database (custom metadata, or even a user record), then it can be accessed from any client side plugin in the same way.

I didn't say I'd do it that way, I just said it was an example to show the issues of dealing with extenders.

[stanger89]

FWIW, the two best examples of the difficulties of dealing with Clients are DVD/BD playback, and Comskip imports. If you use extenders, these things "just work", the server can see everything and everything is great.

With clients, you have to make sure the client can see the same paths the server can, otherwise neither works because the client asks the server for file locations and the server only knows what it sees.

[Fuzzy]

Keep in mind, this is also really a result of the current way the comskip plugin is written, and is basically a legacy method from 7 years ago, before sage implemented most of the current database api's. A comskip plugin could just as easily be created that could store the skip points in the sage database, and this would work perfectly fine regardless of ui context.

[stanger89]

True, but it's an example of the extra "thought" that has to go into something that will work on a Client rather than just the server/extenders.