ExecuteWidgetChain() in server startup class

[dflachbart]

Currently I am starting certain background threads from 'ApplicationStarted' in the STV code. Does anyone see any potential problems with starting them during server startup time by writing a java runnable (load_at_startup_runnable_classes) which executes the existing STV code with ExecuteWidgetChain() ?


Dirk

[GKusnick]

I wouldn't regard ApplicationStarted and load_at_startup_runnable_classes as interchangeable. Consider the case of a SageTVService serving multiple Placeshifter and Extender clients. load_at_startup_runnable_classes happens just once when the service initializes. There may not be any STV loaded at all at that point. ApplicationStarted, in contrast, fires each time a client connects. If your widget threads interact with the UI or have any per-client state, then ApplicationStarted is the right place to fork them. If they need no UI or per-client state, then they probably shouldn't be widget code in the first place. Just code them in Java and launch them from load_at_startup_runnable_classes in the usual way.

[dflachbart]

Originally Posted by GKusnick

I wouldn't regard ApplicationStarted and load_at_startup_runnable_classes as interchangeable. Consider the case of a SageTVService serving multiple Placeshifter and Extender clients. load_at_startup_runnable_classes happens just once when the service initializes. There may not be any STV loaded at all at that point. ApplicationStarted, in contrast, fires each time a client connects. If your widget threads interact with the UI or have any per-client state, then ApplicationStarted is the right place to fork them. If they need no UI or per-client state, then they probably shouldn't be widget code in the first place. Just code them in Java and launch them from load_at_startup_runnable_classes in the usual way.

Hi Greg,

yeah I am of course aware of the differences between the startup classes and the ApplicationStarted hook. The threads do not interact with the UI, and do not have any per-client state. In fact, moving them to the server startup should solve the problems of 1) making sure that only one thread is started even if multiple clients are running, and 2) ensure that the thread is started even if no UI is running at all. But you are right, the thread code should have been all in java in the first place. There are just two reasons I hesitate to do this:

- it's quite a bit of code, so it would require a lot of re-coding (lazy )
- the current widget code contains a "hook" location for other STVis to link to. This would get more complicated.

If the server is run as a service, does it have access to the STV code at all (does it 'load' the STV specified in Sage.properties) ? The approach obviously wouldn't work if not...

Dirk

[GKusnick]

Originally Posted by flachbar

If the server is run as a service, does it have access to the STV code at all (does it 'load' the STV specified in Sage.properties) ?

My guess is that it does not. Seems to me that last time I tried it, GetUIContextNames() returned an empty list for a service with no clients connected. Without a UI context, GetAllWidgets() and friends aren't going to do anything useful. But it should be easy enough to test by writing a runnable startup class that calls some of those APIs and DebugLogs the results.

On the laziness issue, you could do what I'd probably do in a case like that. Instead of rewriting all that code in Java, write a Java app that loads the XML as a DOM document, walks the widget tree, wraps the text of each If or Action widget in a Java statement, and writes it all out to a text file. That should get you about 90% of the way there. It may not actually be any less work that rewriting the code by hand, but it would be more fun.

(My laziness problem is just the opposite: I hardly ever write more than a dozen consecutive lines of pure If and Action widgets if I can write a Java subroutine instead.)

I'm not sure what to tell you on the STVI hook issue without knowing more about what problem you're trying to solve with it.

[Opus4]

Originally Posted by flachbar

If the server is run as a service, does it have access to the STV code at all (does it 'load' the STV specified in Sage.properties) ?

No, the service does not load or use an STV at all, since it has no UI. If you want something to run on the server regardless of whether there is any client UI connected, then I believe you would have to go the java route.

Forked threads on the server for a remote UI don't automatically end when the remote client UI disconnects, so it will keep running until your code ends that forked thread. I would suggest perhaps using one of them to do what you need, but then you would have to 1) have a remote UI start at some point and 2) have a reliable way to note that your code is currently running so another copy doesn't start.

This is for firing your automatic favorite conversions, isn't it?

- Andy

[dflachbart]

Originally Posted by GKusnick

But it should be easy enough to test by writing a runnable startup class that calls some of those APIs and DebugLogs the results.

Yep, at the time of posting my server wasn't available to test this out (recording...). But now that Andy confirmed it, I guess I have no choice anyway

On the laziness issue, you could do what I'd probably do in a case like that. Instead of rewriting all that code in Java, write a Java app that loads the XML as a DOM document, walks the widget tree, wraps the text of each If or Action widget in a Java statement, and writes it all out to a text file. That should get you about 90% of the way there. It may not actually be any less work that rewriting the code by hand, but it would be more fun.

So since you are familiar with laziness, your code isn't by any chance written so generically that it would work with any XML ?

(My laziness problem is just the opposite: I hardly ever write more than a dozen consecutive lines of pure If and Action widgets if I can write a Java subroutine instead.)

Yeah, as I progress with Sage programming I tend to do the same lately...

I'm not sure what to tell you on the STVI hook issue without knowing more about what problem you're trying to solve with it.

One of the threads implements the auto-compression functionality in SageMC (which uses the default compression of the Sage core). It is written in a way that you can alternatively use EP's external compression plugin, his import links its code to a specific location in the widget code, and will be called by the thread in the same way as the standard code.

I guess there is no way to achieve this if there is no UI loaded on the server...

Dirk

[dflachbart]

Originally Posted by Opus4

This is for firing your automatic favorite conversions, isn't it?

Yeah, it's for the SageMC auto-compression of favorites, and the other thread is for the automatic generation of .my files...

Dirk

[JREkiwi]

Dirk, there are some other pluses and minuses.

The code would be available for any STV. I'm all for that, I'm a firm believer that different STVs should provide different form rather than different function.

Once it's out of the STV, would there only be the big binary control? (Shut down server, edit Sage.Properties, Start Server)

The STVi hook issue is something that interests me. How am I supposed to take advantage of your great code? The way it is at the moment, I can steal your code with ease and make additions to it. I have to win the laziness competition

I'll leave it to you to determine which are the pluses and minuses.

John

[nielm]

Originally Posted by flachbar

Yeah, it's for the SageMC auto-compression of favorites, and the other thread is for the automatic generation of .my files...

Dirk

I already have a java runnable class for writing the XML files (and deleteing them after the mediafile is deleted) if you want to copy parts of it

[dflachbart]

Originally Posted by nielm

I already have a java runnable class for writing the XML files (and deleteing them after the mediafile is deleted) if you want to copy parts of it

Thanks Niel, I'll have a look at this if I should decide to start on that. Well, I guess now I will first have to spend some time on integrating your new RSS code

Dirk

[dflachbart]

Originally Posted by JREkiwi

Dirk, there are some other pluses and minuses.

The code would be available for any STV. I'm all for that, I'm a firm believer that different STVs should provide different form rather than different function.

Once it's out of the STV, would there only be the big binary control? (Shut down server, edit Sage.Properties, Start Server)

The STVi hook issue is something that interests me. How am I supposed to take advantage of your great code? The way it is at the moment, I can steal your code with ease and make additions to it. I have to win the laziness competition

I'll leave it to you to determine which are the pluses and minuses.

John

John, you are right on this having up- as well as downsides, and I'll have to think about it a bit longer...

Dirk