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

[John T. <jd...@ro...>]

My own view is that this is something we should seriously look at, but 
not rush into.  At the moment we're dealing with files that are not 
going to exceed the user's disk space, not even close.  So, apart from 
the processing overhead, it's not really a big deal if each application 
makes its own copy of the data.  With remote URLs, there is the issue of 
multiple downloads of the same data, but the feeling a while back was 
that we can leave the user's cache to deal with this.

If we do decide to do it, then I think it would have to be an optional 
extension of a hub, and accessed by messaging.  In fact, it needn't be 
bundled with a hub - we can define a set of messages for a third-party 
application to "adopt" a file, do the reference counting and clean-up.  
Perhaps this "cache" will be bundled with a particular hub impl, perhaps 
it won't.  The client application will have to deal with its presence or 
absence.

I think we should proceed with some caution (contrary to my usual 
act-first-think-later behaviour!).  As Tony pointed out during our 
meeting (Richard), this sort of thing has been done before and we should 
probably do some investigating.

John


>
> Your ideas are quite reasonable ones, but the reason I'm not very
> enthusiastic about them is that part of the unwritten philosophy behind
> PLASTIC (at least in my understanding) is that it's simple in 
> order to be difficult to break.  For instance, reference counting
> to keep track of temporary resources is clearly the Right Thing 
> to do if you have a controlled environment with reliable object
> destructors etc.  But by its nature a hub is dealing with unreliable
> connections to unreliably implemented clients, and a client that 
> forgets to unregister itself, or its interest in a file, could 
> very easily end up leaving (possibly large) temporary files hanging 
> around for much longer than they ought to be there.  This sort of 
> thing would be fairly easy to track down and fix in a single-process 
> application, but practically impossible when you've got no idea
> what applications you might or might not be talking to and how
> well or badly they might behave.
>
> That's my take on it anyway - by all means other PLASTICkers chip 
> in with your points of view (including, obviously, right of reply
> from Richard); I'm quite open to debating either the general or
> specific points and being persuaded otherwise.  Either way, if we 
> reach a consensus on this it might be a good idea to agree on a 
> kind of explicit Manifesto or Philosophy of PLASTIC document 
> which can be referred to to clarify this kind of debate/suggestion 
> in the future.
>
>   
>   

-- 
------------------------------------------------------------------------
AstroGrid/VOTech
&
Institute for Astronomy, Edinburgh
Skype:johndavidtaylor <skype:johndavidtaylor?chat>

------------------------------------------------------------------------