On Jan 9, 2012, at 19:47 PM, Karl Pauls wrote:
> On Mon, Jan 9, 2012 at 6:22 PM, Marcel Offermans
> <[email protected]> wrote:
>> On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>> 
>>>> As of R4.3, we do have a framework ID spec, so we could do this, but it
>>>> would still only solve case (2) above. As long as that is your case, then 
>>>> it
>>>> would work.
>>> 
>>> Yeah, we should use the framework ID. Please open a bug for this.
>> 
>> You're referring to 4.2.8 that defines a Framework UUID I guess?
>> 
>> As far as I understand from the implementation (Util.randomUUID()) the 
>> framework gets a "new" unique ID every time it starts. We might want to 
>> consider holding on to it (in our bundle cache) to at least keep it as 
>> "constant" as we can.
>> 
>> Why?
>> 
>> I can see some value in a URL not changing, and if we include it in the 
>> bundle: URLs we generate, we might want to do our best to ensure they are 
>> valid for longer than the current framework run.
> 
> I agree that there is some value to it but at the same time, we
> already have that problem as we need to encode the revision number in
> the url which might be invalid/changed after a refresh/restart...
> 
> Making assumptions about the bundle: urls is a problem not matter what :-).

Good point, so unless we somehow manage to "fix" other issues with this URL, 
one should not rely on them to stick around for longer than the life cycle of 
the framework itself.

Greetings, Marcel

Reply via email to