JP1 Remotes

eferz wrote:Still think checking for individual updates and downloads is the better solution than one big file, especially for bandwidth concerns. Instead of checking the RDFs per use, it could check the entire repository once per day, per start up, per user intervention, or whatever. Individual updates will then be offered with a check list system so the user can decide to download all or specific RDFs.

SVN is smart. It will only download the files that have been changed or added to the repository since the last update. It will also delete files that have been removed from the repository, or rename files that have been renamed in the repository. In fact, for text files, it doesn't download entire changed files, it downloads a diff of the changes made, and applies those.

So in that sense the downloads will be much more efficient. Before actually updating, we can show a list of the files that will be impacted.

While it would technically be possible (fairly easy, even) to allow the user to select which files (s)he wants to update, I'm not sure we want to go down that path, as unwitting users might think they only need to update the RDFs for the remotes they actually use, when we know it is essential that they have up to date RDFs for any remote that might be used by a KM or RM device upgrade file they download, or even an RMIR file if people start sharing those.

Dealing with files that are modified by the user is a little more complicated. SVN will try to merge the changes from the repository into the modified file. This usually works very well, unless the user has made changes in the same parts of the file that were changed in the repository. That is called a conflict, which must be resolved and the user is asked to resolve the conflict. I think we can reasonably offer to

1. keep the user's version, ignoring the changes from the repository,
2. discard the user's version and use the version from the repository,
3. tell the user to resolve the conflict outside of RM.

vickyg2003 wrote:I have no problem with a "per user intervention" search and downloads, but as soon as you go into automated searches when online you cause all sorts of problems for us people with poor internet connections. I know I'm not the only one with connection issues. Just last year one of regulars was still on dial up.

Sure - it should be a menu option you can permanently turn off - but it should be on by default. The 99% shouldn't suffer because of the 1%

xnappo

gfb107 wrote:Dealing with files that are modified by the user is a little more complicated. SVN will try to merge the changes from the repository into the modified file. This usually works very well, unless the user has made changes in the same parts of the file that were changed in the repository. That is called a conflict, which must be resolved and the user is asked to resolve the conflict. I think we can reasonably offer to

1. keep the user's version, ignoring the changes from the repository,
2. discard the user's version and use the version from the repository,
3. tell the user to resolve the conflict outside of RM.

Seems awesome enough to me. But, may I request an additional line item? Sending a small electrical current between the user's keyboard and chair.

xnappo wrote:The 99% shouldn't suffer because of the 1%

Yeah, they should if there's a Zombie Apocalypse or some other pandemic. How else are they going to "spread the love".

xnappo wrote:

vickyg2003 wrote:I have no problem with a "per user intervention" search and downloads, but as soon as you go into automated searches when online you cause all sorts of problems for us people with poor internet connections. I know I'm not the only one with connection issues. Just last year one of regulars was still on dial up.

Sure - it should be a menu option you can permanently turn off - but it should be on by default. The 99% shouldn't suffer because of the 1%

xnappo

Well that would do it. I don't want to make people suffer. I just want to be able to use RM without it reaching out to the tenuous internet connection and stalling for a few minutes. I use RM extensively, often having 4 or 5 sessions open at once.

It doesn't seem that the RDF's, Map's and Images are updated all that often, and I'd hate to see my machine hanging up all the time checking for something that happens once every 3 months or so.

vickyg2003 wrote:
Well that would do it. I don't want to make people suffer. I just want to be able to use RM without it reaching out to the tenuous internet connection and stalling for a few minutes. I use RM extensively, often having 4 or 5 sessions open at once.

It doesn't seem that the RDF's, Map's and Images are updated all that often, and I'd hate to see my machine hanging up all the time checking for something that happens once every 3 months or so.

I definitely think that power users would have it turned off most of the time.

I think it will be great though for new users not to have to deal with downloading and installing the RDFs/Maps!

One question Greg - are you going to download all of them, or only on demand based on the signature?

xnappo

xnappo wrote:One question Greg - are you going to download all of them, or only on demand based on the signature?

All of them. That's always been my position. I thought I was very clear about that.

But because we are using SVN to do the downloading, only the files that have actually changed will be downloaded.

gfb107 wrote:

xnappo wrote:One question Greg - are you going to download all of them, or only on demand based on the signature?

All of them. That's always been my position. I thought I was very clear about that.

But because we are using SVN to do the downloading, only the files that have actually changed will be downloaded.

I give a big thumbs up on the differential or incremental updates. Since that would help people who are on less than optimal internet connections. Like Vicky and whoever that she was referring to that is still using Dial-Up.

Barf wrote:I implemented a fix putting the properties file in the user's home directory, staring with a period, as is the common convention on Unix/Linux. Remains the error output file rmaster.err. I implemented a simple fix, putting it in the "system temporary directory" (java.io.tmpdir), amounts to /tmp on Unix/Linux and %HOME%\AppData\Local\Temp on Windows.

That might be fine for Unix/Linux but it is DREADFUL for Windows. I now have to navigate to this obscure directory and find rmaster.err amongst a whole lot of incomprehensible system junk that seems to go there. I use this file frequently. It MUST be put somewhere more acceptable. The same place as RemoteMaster.properties, which is <user>/AppData/Roaming/RemoteMaster would be better, because although that is still obscure, it does belong to RM and only has the one other file in it.

Edit: I don't think this change of Barf's is in a public version yet, but as a developer I am using the source files from SourceForge and so am experiencing this great inconvenience already.

That might be fine for Unix/Linux but it is DREADFUL for Windows.

Dreadful, oh how polite and English sounding. Let me ditto that.


I've been working with the RMIR Alpha as well. I have RMIR installed in C:\remotejp1\rmir I'm running on an older operating system, on my box that still has a parallel port for my parallel interface. rmerror.err is no place to be found even with a search. On the other hand remotemaster.properties in my C:\remotejp1\rmir\ folder is still being updated.

I 'm all for making RMIR more Linux friendly, but not to the point of forsaking Windows.

When looking at the JP1-Lookup Tool Statistics, I see that 77% of the users are Windows users, 16 % are Mac Users and 5% are linux users and of those Linux users half of them were Google Android users. The number of hits from wind95,98,and ME combined is about equal the Ubuntu statistics. So if those statistics reflect the RM users in general, Linux is a really small portion of the total number of users.

One of these Linux specific changes seemed to be used to change the order of interface tests. This test broke Autodetect that used to work for all interfaces in Windows. Now Autodetect has been made to be JP1.2/3 only, it no longer finds any of my EEPROM remotes. Wouldn't it have been better just to force Linux users to use a specific choice? After all that is what Windows users have to do now. Does Autodetect even work on Linux? That is, does it find any EEPROM remote?

Just for clarification, Vicky has had private updates from me that contain the Barf change. There isn't yet any version in the forum files that has this change, and I sincerely hope there will not be. As Vicky mentions, a search for rmaster.err fails to find it anywhere, as the temp folder into which it now goes appears to be excluded from the Windows Explorer search engine.

I've just committed a change to keep rmaster.err in the same folder as RemoteMaster.properties.

mathdon wrote:Just for clarification, Vicky has had private updates from me that contain the Barf change. There isn't yet any version in the forum files that has this change, and I sincerely hope there will not be. As Vicky mentions, a search for rmaster.err fails to find it anywhere, as the temp folder into which it now goes appears to be excluded from the Windows Explorer search engine.

While we are on the subject.. How about making RM-IR pop up a box saying an error has occurred with a path to the file?

Agreed that it should still go to where it always has...

xnappo

mathdon wrote:

Barf wrote:I implemented a fix putting the properties file in the user's home directory, staring with a period, as is the common convention on Unix/Linux. Remains the error output file rmaster.err. I implemented a simple fix, putting it in the "system temporary directory" (java.io.tmpdir), amounts to /tmp on Unix/Linux and %HOME%\AppData\Local\Temp on Windows.

That might be fine for Unix/Linux but it is DREADFUL for Windows. I now have to navigate to this obscure directory and find rmaster.err amongst a whole lot of incomprehensible system junk that seems to go there. I use this file frequently. It MUST be put somewhere more acceptable. The same place as RemoteMaster.properties, which is <user>/AppData/Roaming/RemoteMaster would be better, because although that is still obscure, it does belong to RM and only has the one other file in it.

What is the intention for using Roaming folder? I would think using the Local folder equivalent would be better for everyone, especially those who might use the program in an Windows Domain/Workgroup environment. Windows uses the Roaming folder for application specific data (such as custom dictionaries) which are computer independent and should roam with the user profile. These files are copied to local computer and from the network home directory when a user logs into their network account.

Personally, I think Barf's implementation is better because it is using the java.io.tmpdir variable. This makes it more portable and empowers Remote Master to run on the java platform for any operating system. This variable can also be set on run time using "-Djava.io.tmpdir={path}" should either the user or developer deem necessary. This is analogous to how we already use "-rm" switch to bring up Remote Master instead RMIR.

gfb107 wrote:I've just committed a change to keep rmaster.err in the same folder as RemoteMaster.properties.

This doesn't work. It is now looking for remotemaster.properties in my install directory.

eferz wrote:Personally, I think Barf's implementation is better because it is using the java.io.tmpdir variable. This makes it more portable and empowers Remote Master to run on the java platform for any operating system. This variable can also be set on run time using "-Djava.io.tmpdir={path}" should either the user or developer deem necessary.

Oh, that's really wonderful. Make Windows users run through hoops to get sensible behaviour, just so Linux users get a nice default behaviour.