Re: [Plastic-devs] Temporary files and IDs for loadFromURL

[John T. <jon...@gm...>]

Mark Taylor wrote:
>   
>> The solution is to adopt the same argument list as 
>> ivo://.../votable/load and have a second argument specifying the ID.   I 
>> suggest we make this second argument optional (but strongly recommended) 
>> to avoid breaking existing apps, and if it's missing assume that the 
>> id=url as we have now.
>>     
>
> After thinking about it for a while, I agree, but subject to the 
> following comment.  I seem to remember that the, or at least a
> reason we decided to use the URL for the table ID was that 
> it meant if the table had some persistence (i.e. it was a non-temporary
> file in the filesystem, or something on a remote server) then two
> applications could know they were talking about the same thing even
> if they picked it up independently rather than one having got it from
> the other through PLASTIC.  So for a file which is (expected to be) 
> persistent the URL is a good choice for the identifier.
>   
I don't remember the discussion, but the idea seems pretty sensible.
> [snip]

>   
>> On the subject of optional arguments.  I think it might be a good 
>> pattern that any optional args go into a struct tacked on after the 
>> mandatory arguments.  That way they can be referred to by name rather 
>> than position.
>>     
>
> Hmm, interesting thought.  My initial feeling is that for arguments
> which are optional but strongly recommended like the one you've 
> suggested above (i.e. ones we should have put in in the first 
> place but didn't realise until too late) there's not much advantage
> in this.  However, if some commands end up with a forest of options 
> it could be a good plan.
>   
I think the id parameter falls into the category of "should be mandatory 
from now on", so I agree, specifying it by position is easier and 
clearer.  I was really thinking on the lines of (e.g.) if someone wanted 
to do something very app-specific such as send a color=blue parameter in 
with the showObjects message, though my original post isn't very clear.