Clients

[CollegeProject]

I have a question on how clients operate. I have a implementation class and it works fine on the server (it saves information to a folder and updates on a timer).

What is the preferred method to give client computers access to that file? I am guessing I need to put a IfClients on the implementation class and just copy the file from the server. My questions is do implementation classes call Run() when clients are started?

Sorry I don't run clients and just trying to grasp how they work without having to setup a VM.

[Fuzzy]

There are a couple different file access API calls. Some will access files in the 'local' filesystem (which on the server or miniclients/extenders, is the server's filesystem; on a client this would be the client's filesystem). There are other API calls that access the file on the server's filesystem, regardless if called from server or client.

[tmiranda]

Originally Posted by CollegeProject

I have a question on how clients operate. I have a implementation class and it works fine on the server (it saves information to a folder and updates on a timer).

What is the preferred method to give client computers access to that file? I am guessing I need to put a IfClients on the implementation class and just copy the file from the server. My questions is do implementation classes call Run() when clients are started?

Sorry I don't run clients and just trying to grasp how they work without having to setup a VM.

Communicating between SageClients and the server is always an issue. What I normally do is use the "standard" plugin and then check in the start() method if it's running on the client or the server using the IsClient() API. If it's running on the server I do whatever startup needs to be done. If it's on a client I just return.

To pass data between the client and server I generally use the UserRecord API because it stores data in the wiz.bin which is accessible from client or server.

Depending on what I am trying to do I either use polling or a SageEvent to let the server know the client needs something to happen.

Be very careful accessing files, a Fuzzy mentioned sometime the APIs give you paths that work only on the server. You also have to remember that the client and server may be different operating systems which use different path separators. It gets messy real fast

Let me know what you are trying to do, maybe I can give you more detailed "do and don't" information.

[CollegeProject]

I think that gives me what I needed thank you. I basically write a JSON file to a server location and I just need to copy that JSON file to the client pc shouldn't be a big deal just have to get the code done to do it.

Now keeping it updated and such will require checks against modified time should be fun

Thanks for the pointers not having a client but supporting it is proving tricky.

[Fuzzy]

Alternatively, the JSON may not actually be the best method to use either. There are some capabilities for storing user database information in the main sagetv database, which would then handle this all for you, and actually caches data on the clients in a smart and high performance way.

http://sagetv.com/api/index.html?sag...RecordAPI.html

[EnterNoEscape]

Originally Posted by Fuzzy

Alternatively, the JSON may not actually be the best method to use either. There are some capabilities for storing user database information in the main sagetv database, which would then handle this all for you, and actually caches data on the clients in a smart and high performance way.

http://sagetv.com/api/index.html?sag...RecordAPI.html

I can't agree more with this approach. SageTV already has very solid and efficient protocols to communicate between the client and server. I don't recommend trying to re-invent this. If you have a special case that you don't think the API adequately supports, I highly recommend extending the core API by contributing to the v9 project on Github.

[CollegeProject]

Thanks for the feedback I don't choose JSON it's what my external service gives me to work with. I originally stored the Jason into custom java objects and used the userrecord API. The problem was the source I am using requires me to update any changes data a min of every 24 hours. Using the api key wasn't very efficient for my use case but I'll give it another look. I am not looking to add to the core api right now outside of my scope for this project maybe after. It would be over 18k objects I'll look at userrecord.

Storng in Json since that is what I receive in and retrieving into custom java objects is extremely fast and efficient and also min in space. I have read many forums about people complaining about their sagedb sizes creeping up and was trying to avoid contributing too that as well. As with all programming more than one way to slice and it's always interesting to get other ideas.

Thanks again

[jusjoken]

You could just have the client perform the function itself rather than sharing between the server and clients for this data as long as its not too intensive.

Or use a central folder concept like fanart does.

k

[CollegeProject]

Originally Posted by jusjoken

You could just have the client perform the function itself rather than sharing between the server and clients for this data as long as its not too intensive.

Or use a central folder concept like fanart does.

k

Ya the central fanart concept may be best I'm going to look at some options this week with userrecord just seems excessive to store that much in there.