File with all program that are LDraw relevant

[Michael Heidemann]

Hi,
I often faced the problem to get the locations of other LDraw related applications like LDView, MLCad or LDDP, just to name the most popular in the past.

It would be great if we could have one file that stores all these informations.

This information file, lets call it maybe "LDrawTools.xml" should be stored in the LDraw base folder. So if I got the information from the enviroment variable %LDRAWDIR% I also know where all the other apps are located by reading just this single file.

Any new application should add its own entry in this file once it is started the first time.

What do you think?

Suggestion for the structure of the "LDrawTools.xml":

Code:

<LDrawApps>
    <Apps>
        <App>
            <Name>
                MLCad
            </Name>
            <Location>
                c:\Programm\MLCAD\mlcad.exe
            </Location>
        </App>
        <App>
            <Name>
                LDDP
            </Name>
            <Location>
                c:\Programm\LDDP\LDDP.exe
            </Location>
        </App>
        <App>
            <Name>
                LDView
            </Name>
            <Location>
                c:\Programm\LDView\LDview.exe
            </Location>
        </App>    
    </App>
</LDrawApps>

[Tim Gould]

I like your idea. Although in practise I'm not sure how widely it would be used. Still...

For consitency with the parts xml format you and I use I'd suggest:

Code:

<LDraw-Applications>
    <App>
        <Name>
            MLCad
        </Name>
        [<Description>
            An LDraw part editor.
        </Descripton>]
        <Location>
            c:\Programm\MLCAD\mlcad.exe
        </Location>
    </App>
    <App>
        <Name>
            LDDP
        </Name>
        <Location>
            c:\Programm\LDDP\LDDP.exe
        </Location>
    </App>
    <App>
        <Name>
            LDView
        </Name>
        <Location>
            c:\Programm\LDView\LDview.exe
        </Location>
    </App>    
</LDraw-Applications>

[Alex Taylor]

Any new application should add its own entry in this file once it is started the first time.

Dangerous. If two or more apps attempt to access the file simultaneously and one of them is writing to it then - at best - the others won't see what they need to, and if more than one app is writing to the file then there will be data-loss and/or corruption.

This idea sounds a lot like something that would benefit LetGUI and nothing much else :-) And since it would rely on the user having run each program at least once before LetGUI could see it, I don't think it's any easier than having the user add the programs manually.

[Michael Heidemann]

It's definitely not LETGui that I had in mind when I was writing that lines!

Code:

Dangerous. If two or more apps attempt to access the file simultaneously and one of them is writing to it then - at best - the others won't see what they need to, and if more than one app is writing to the file then there will be data-loss and/or corruption.

I can not see this problem. Given the following situation:
That file is already in place. Someone created a new application. Let's say LDFind. The Author like to give you as the user the possibility to open the file found with MLCad. With the new file he just needs to read the entries in that file for MLCad entry and use the found value. If nothing is found the author can not show you the button to use MLCad.
On the first start of LDFind it will open the file for reading (is my own entry in the file) if not the file is opened for writing and the value for LDFind is written to the file. I can not really imagine that two application at the same time are doing that.

[Alex Taylor]

The scenario is this: you have two applications, both of which need to add themselves to the file. The following operations occur in order:

1. Application A reads the file into memory.

2. Application B also reads the file into memory.

3. Application A, having added itself to the list, writes the file back to disk.

4. Application B adds itself and writes back to disk.

Whatever Application A added to the file has now been lost, because Application B doesn't know about it.

You are running on a multi-tasking system, and in all probability a multi-core system, so the above scenario is not only possible, it is highly likely to occur.

[Roland Melkert]

We need a LDraw traffic manager service / daemon

Just kidding, but would be kinda cool.

[Alex Taylor]

There are ways of making this work, but they have at least two disadvantages: they would require each and every application which wants to read/write this file to implement access to it in exactly the same way; and they are not usually cross-platform compatible.

[Travis Cobbs]

What you're describing is a "race condition".

I know that on Windows you can open a file in "exclusive mode" so that no other process can read or write the file by setting dwShareMode to 0 in the call to CreateFile(). (It allows finer granularity than that, but that is the safest setting in this context.) If all applications are required to do this any time they read or write the file, and are also required to retry opening the file for (say) one second if an open attempt fails, then the race condition goes away.

[Travis Cobbs]

Note: I believe that similar functionality can be achieve in Linux (and probably Mac OS) using flock(), and passing LOCK_EX | LOCK_NB to request an exclusive lock while not blocking the application.

Ideally if we decided to go with something like this, I think someone should write the code to access the file in a safe way, and then share that code for everyone else to use, because it's only useful if everyone does it properly.

[Alex Taylor]

My point exactly: this can only work if everyone plays by the rules. That's not going to happen - anyone can write LDraw-compatible software, and there's no way to ensure that they all follow this pattern.

The timeout idea you suggest is workable, although the actual timeout would have to be random and not a fixed number otherwise you're back to the race-condition. OTOH, it's also a bad code-smell :-)

It isn't possible to have a single implementation of the code, because this is an OS-specific thing to do: we'd need (at the least) an implementation for Windows, one for Linux, one for MacOS, one for Android, ... Not to mention that it would likely be necessary to have implementations for languages such as Java, C# and so on.

This whole idea currently sounds to me like a solution in search of a problem.

[Michael Heidemann]

Code:

This whole idea currently sounds to me like a solution in search of a problem.

Definitely not! I like to assist the user. Currently you have to set for each application the path for other applications by hand. I am coding very special applications that should use the special purpose of other applications.
I think this would be a big value for the user, but if we can not find a way to solve this then I need to ask the user where the apps are located on his system like we have done for years now.

[Alex Taylor]

But you still need to know exactly how to launch each application. This is not something that you should be building in to your code - the user must specify any command-line options themselves, because applications change. And your idea still relies on the user having run each application in order to get it to 'register' itself.

[Michael Heidemann]

You are right on what you say.

But for that reason, input from others, I mentioned my idea.

So this idea is not going to be practicable!

- CLOSED -