Applications Messaging Standard

[John Taylor]

On 15 Feb 2007, at 20:34, Tony Linde wrote:

> > I had to use the the API that gave me the location of the  
> Desktop, and
> > then append "/.." which is not really satisfactory.  On C++ I  
> seem to
>
> Maybe that should be an indication that you're not supposed to put  
> stuff there :)

I think you could well be right.  It's not a perfect solution, but it  
is simple and workable.

For what it's worth, I think we've got it wrong in PLASTIC.  The  
format of the .plastic file is too java-centric.  But that's  
something we can fix.




>
> T.
>
> John Taylor wrote:
>> Hi Mike - your reply didn't go to the apps list (I don't think),  
>> so the stuff below might be out of context.
>> On 15 Feb 2007, at 18:40, Tony Linde wrote:
>>> > I think even the suggestion of using the Windows registry violates
>>> > the first comment above (can somebody point me to a Fortran
>>> > interface to the registry?).   As has been pointed out before, the
>>> > current .plastic file (and the suggested .ivoamsg file) is not the
>>> > reason for your demo problems and so long as apps play nice with
>>> > the host system, the use of dot files is not ground-breaking  
>>> technology.
>>> > Likewise, using the java properties is nice for java, but....
>>>
>>> I wasn't suggesting that we use the windows registry - I said  
>>> that the registry is the obvious solution in windows but that  
>>> since linux does not have an equivalent facility (don't know  
>>> about macs), the common file seems to be the lowest common  
>>> denominator.
>>>
>>> One point since we're mentioning languages: do other languages  
>>> have the concept of a 'home' directory? We know that it'll work  
>>> for java and .net languages, but do python, perl etc have  
>>> commands to get the 'home' directory which will return the same  
>>> directory as java does?
>> Python and perl certainly do.  As far as I can tell C# appears not  
>> to - I had to use the the API that gave me the location of the  
>> Desktop, and then append "/.." which is not really satisfactory.   
>> On C++ I seem to remember that I had to get the environment  
>> variable "HOME", but this often wasn't set on Windows.  Perhaps  
>> Marco can say how it's done properly in C++.  It also looks like  
>> it can be done in Ruby.
>>>
>>> > the first comment above (can somebody point me to a Fortran
>>> > interface to the registry?).   As has been pointed out before, the
>>>
>>> If there is a windows Fortran compiler then it'll have access to  
>>> the win32 libraries which make registry access relatively simple.
>>>
>>> T.
>>>
>>> Mike Fitzpatrick wrote:
>>>> On 2/15/07, Tony Linde <Tony.Linde at leicester.ac.uk> wrote:
>>>>> Hi John,
>>>>>
>>>>>  > whatever solution we choose should be platform and
>>>>>  > language neutral.
>>>>>
>>>>> agreed.
>>>>>
>>>>>  > Unfortunately, there's no way
>>>>>  > for Python, Perl and everyone else to use it.
>>>>>
>>>>> I'd be surprised if there weren't libraries for getting the  
>>>>> windows
>>>>> registry info - not sure what java does so don't know about that.
>>>> I think even the suggestion of using the Windows registry violates
>>>> the first comment above (can somebody point me to a Fortran
>>>> interface to the registry?).   As has been pointed out before, the
>>>> current .plastic file (and the suggested .ivoamsg file) is not the
>>>> reason for your demo problems and so long as apps play nice with
>>>> the host system, the use of dot files is not ground-breaking  
>>>> technology.
>>>> Likewise, using the java properties is nice for java, but....
>>>> I also think we're agreed that a well-known file, a separate  
>>>> name server, a
>>>> "hub" or somesuch is needed and is an implementation detail.   
>>>> For this
>>>> exercise we should concentrate on what information needs to be  
>>>> written
>>>> to establish the connection and pass messages.  Does the XPA name
>>>> server do something the PLASTIC hub doesn't?  If so, do we need  
>>>> it and
>>>> what does that look like in our new protocol (i.e. a dedicated  
>>>> administrative
>>>> message or some generic functionality) ?
>>>> -Mike
>>>
>