RemoteMaster setup.exe: Making install dir read-only

[mdavej]

...As an experiment, I just uploaded a new version, which

- contains Maps/Images as well as RDSs, optionally installable in directory Program Files\Common Files\JP1\[rdfs,maps]. (No other location possible.)
- Fixes the icon problem
- Makes file associations optional
- If maps and/or rdfs was installed, a rudimentary properties file will be generated (actually, lines are appended to an existing or nonexisting properties file) so that the user does not have to locate rdf/map files at the first start.

Tell me how you like it.

Got java working and tried this version. Works as advertised. Thanks. I like where this is going.

[gfb107]

I threw together a prototype of the "download and update RDFs, Maps, and Images from SVN" concept. I used SVN Kit. Was pretty simple to do and works.

Some things about how I see this progressing if we all agree this is a good idea.

• I don't want RM keeping track of the versions of files associated with a particular remote signature. I think the SVN client does that well enough, only downloading the missing or modified files, and warning about locally modified files. Checking the entire set of files periodically (automatically at start up on a regular interval, or on user demand) should be sufficient.
• We have a number of users who want all of RM contained in a single folder (and sub-folders). They may have these files on an external or network drive, and use the same installation on a number of different computers. For these users, ALL RM files, including those created and reads and writes must be kept within that single installation folder. They don't want anything anywhere else. In this case the "RM Home" folder must be the installation folder in which RemoteMaster.jar exists, which should also be the working directory when RM runs (as determined by the Java system property "user.dir")
• Other users want a more standard install where the core files are placed in the standard "Programs" folder which under normal conditions is not writable. The files that RM writes cannot be kept in this folder, they must be kept somewhere else. I propose that the "RM Home" folder for these users be a child of the user's home folder (as determined by the Java system property "user.home", which should provide the correct values for any OS). I would name this folder ".RemoteMaster".
• The installer should be able to accommodate either type of user
• Within the "RM Home" folder, RM will use the "remotes" sub-folder and run SVN checkout/update to the SVN URL https://controlremote.svn.sourceforge.n ... k/remotes/
• We'll need to come up with a scheme for migrating existing users who already have RM installed and have downloaded the RDFs and Maps manually.

[vickyg2003]

I've been reading this, and have a stupid question.

What is SVN?

[vickyg2003]

Another question.

For those of us that use IR and RM, will this mean that in the future I am going to have two sets of RDFs?

[eferz]

I've been reading this, and have a stupid question.

What is SVN?

Apache SubVersioN (SVN) is the software versioning and a revision control system that they use on SourceForge.

[gfb107]

You should still be able to share a single folder containing the RDFs.

The point is that RM will periodically check (or at your request) to see if you have the latest, and offer to download the latest version of the ones that are missing or are old. It will also be able to detect if you are using a modified version of any file, and offer to replace it with the official version.

We do have to keep in mind that there are users who use both RM and IR and are already sharing the RDF folder. We should make it easy, if they want, to continue using the same folder for the RDFs. In that case, RM might not be able to track the files unless it downloads the latest official set, replacing what is already there. We might have to offer to download to a different folder, and provide the location so you can set the RDF path in IR to that folder.

Another question.

For those of us that use IR and RM, will this mean that in the future I am going to have two sets of RDFs?

[Barf]

I threw together a prototype of the "download and update RDFs, Maps, and Images from SVN" concept. I used SVN Kit. Was pretty simple to do and works.

Nice. I also came to the conclusion that SVNKit would be the best solution, being pure Java as opposed to the official JavaHL jni-based solution.

• I don't want RM keeping track of the versions of files associated with a particular remote signature. I think the SVN client does that well enough, only downloading the missing or modified files, and warning about locally modified files.

Agreed, pretty much the same as in my previous post.

Checking the entire set of files periodically (automatically at start up on a regular interval, or on user demand) should be sufficient.

Even less is sufficient, namely to check by usage, cf my previous post with pseudocode. Of course, an option, for example selectable from menu "check all RDFs" is possible, however not that essential.

• We have a number of users who want all of RM contained in a single folder (and sub-folders). They may have these files on an external or network drive, and use the same installation on a number of different computers. For these users, ALL RM files, including those created and reads and writes must be kept within that single installation folder. They don't want anything anywhere else. In this case the "RM Home" folder must be the installation folder in which RemoteMaster.jar exists, which should also be the working directory when RM runs (as determined by the Java system property "user.dir")
• Other users want a more standard install where the core files are placed in the standard "Programs" folder which under normal conditions is not writable. The files that RM writes cannot be kept in this folder, they must be kept somewhere else. I propose that the "RM Home" folder for these users be a child of the user's home folder (as determined by the Java system property "user.home", which should provide the correct values for any OS). I would name this folder ".RemoteMaster".
• The installer should be able to accommodate either type of user
• Within the "RM Home" folder, RM will use the "remotes" sub-folder and run SVN checkout/update to the SVN URL https://controlremote.svn.sourceforge.n ... k/remotes/

Here I differ. There need to be a user possibility to select the RDF directory and the Maps/Images "arbitrarily". (The present installer uses Program Files\Common Files\[RDF,Maps] unconditionally; this need to be fixed (reasonably easy).) Having this possibility is all we need, sensible defaults should be provided, that is all. "Different installation types" is not needed here.

• We'll need to come up with a scheme for migrating existing users who already have RM installed and have downloaded the RDFs and Maps manually.

Not a big issue, only a few power users are involved. They can be supported in the forum.

Greg, did you find my catalog concept useful?

Just to write down my thoughts:
Things we should not do:

• Try to re-implement tortoise, i.e. implementing functionality outside of the core usecases discussed in previous postings. commit, merge,... can be done with other tools. Possibly a diff would make sense though.
• Searchlist of several repositories.

[vickyg2003]

The point is that RM will periodically check (or at your request) to see if you have the latest, and offer to download the latest version of the ones that are missing or are old.

It would have to be "at my request" for me, since I "go dark" for long periods, when I don't have regular internet access.

Quote:


* We'll need to come up with a scheme for migrating existing users who already have RM installed and have downloaded the RDFs and Maps manually.

Not a big issue, only a few power users are involved.

What?

[gfb107]

I was trying to suggest that we don't need a catalog file. When we do a status or update, we always do it for everything in the rdf and map folder. That way we don't have to maintain a catalog file, and we have less code to write. SVN does the work for us. SVN will only download any new or updated files so it'll be pretty efficient

[Barf]

I have uploaded a new version of the setup-per, where the user can select the locatiion of the RDFs and the maps arbitrarily -- Greg argued that this was needed.

I was trying to suggest that we don't need a catalog file. When we do a status or update, we always do it for everything in the rdf and map folder. That way we don't have to maintain a catalog file, and we have less code to write. SVN does the work for us. SVN will only download any new or updated files so it'll be pretty efficient

There are actually two different approaches: I envisioned having individual files checked/updated as needed (see my post with the pseudo code) (making it possible to have only the rdf/maps you actually use), while Greg's concept holds a complete checkout, and updates the whole of it when needed or desired. The first solution is the technically more advanced, but also requires more work, like a catalog. But both are really ok; who cares for, say, 10MB "unnecessary disk space wasted" these days?

The subject of the thread, making the installation directory read only, has not received much attention. So I checked in the diff in the first posting (rev 1081) , since no-one objected.

[vickyg2003]

There are actually two different approaches: I envisioned having individual files checked/updated as needed (see my post with the pseudo code) (making it possible to have only the rdf/maps you actually use), while Greg's concept holds a complete checkout, and updates the whole of it when needed or desired. The first solution is the technically more advanced, but also requires more work, like a catalog. But both are really ok; who cares for, say, 10MB "unnecessary disk space wasted" these days?

How would you use an RDMU file or KM file created by someone else if you didn't have the RDFs? You ABSOLUTELY must have the complete set of RDFs to use RDMU and KM files.

RM vomits if you don't have the required Maps and Images, so you typically need those too, but I suppose RM could be recoded to not be so unhappy about missing maps and images.

[mdavej]

I vote for a complete checkout because when you pull device upgrades from this site, they could come from any remote, so you really need all rdf/maps at all times in order to be able to open them. Fetching the required rdf/map on demand as you open upgrade files is also fine but seems needlessly complex and makes working offline impossible. Being forced to work online is one thing I dislike about other remote software like harmony and OFA/Xsight.

Somewhat related to fetching rdfs, an interface to browse/search/download device upgrades would be a great addition as well. It's probably a huge amount of work, and the infrastructure/maintenace is probably a big can of worms, but I just wanted to throw that out there for consideration in the future. A good start that would be fairly simple (I think) is a new tab in RMIR that had a browser window that went straight to our file section.

I don't have an opinion the read-only install.

EDIT: I see vicky posted the same concern at the same time.

[vickyg2003]

EDIT: I see vicky posted the same concern at the same time.

Yes and you raised one that I should have.

Being forced to work online is one thing I dislike about other remote software like harmony and OFA/Xsight.

While I haven't encountered those, I would HATE to be forced to work on line. I need to be mobile with my JP1 gear.

[eferz]

While I haven't encountered those, I would HATE to be forced to work on line. I need to be mobile with my JP1 gear.

I honestly don't see why it would have to change the way we use it now. We have the RDF files needed for IR and RM zip archive for the bulk download of the RDFs. The SVN system would enhance the way we keep our individual RDFs up to date while online. The difference is that you will have a mechanism to alert you and offer to download the respective update when it is available.

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.

Kind of like an App Market for RDFs.

[vickyg2003]

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.