6292 - [BLOCKED] Triggering jars creates "cache" folder with copies of triggered jars

Status: VERIFIED INVALID

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

Description

[Jimmy Lee]

Build: 5/11/99 Seamonkey

1. This may be related to http://bugzilla.mozilla.org/show_bug.cgi?id=6103
2. Trigger any jar file (You may use http://jimbob/trigger.htm to trigger from
   http://jimbob/jars)

RESULT:
Triggering any jar results in a subdirectory, cache, getting created from the
current seamonkey build.  Within this subdirectory, a copy of the jar and
trigger can be found with names like M1ljgs24.jar and M15m39mr.htm,
respectively.

EXPECTED RESULT:
Copies of jars and triggers are not copied to this subdirectory, cache.  I am
not sure if there is a need to create this subdirectory.

Comment 1

[Jimmy Lee]

Changing QA Contact from Grace to Jimmy.

Comment 2

[Doug Turner (:dougt)]

This *should* go away with necko.  We need a way to say "Don't Cache" this file
when opening a URL with a listener class.

Adding warren and dp.  Is this something that necko will deliever?

Comment 3

[Cathleen]

Reassign to warren.  Need Necko to support option for not store files in cache
(especially for install files).

Comment 4

[Warren Harris]

What does it mean to "trigger" a jar?

Comment 5

[Daniel Veditz [:dveditz]]

"Trigger" is XPInstall lingo. We call netlib routines to get a file and pass
you a stream listener, and write out the file ourselves. We need a way to tell
you not to cache it also.

We don't want two copies of these potentially very large files, and we don't
want to leave a copy behind when we're done. If there's no way to skip the
caching, then we need 1) a way to prevent you from flushing the cache until we
tell you it's OK (one 10Mb install may overflow someone's cache) and 2) a way
to make sure the file's gone from the cache when we're done (gov't wants us to
make sure the encryption upgrade is not left around).

Comment 6

[Cathleen]

Doug volunteered to bug Jud/Warren about this bug...  :-)
reassign to doug, per today's bug meeting.

Comment 7

[Doug Turner (:dougt)]

waiting for a cache story.

Comment 8

[Doug Turner (:dougt)]

moving after beta.

Comment 9

[Cathleen]

saw Warren at the staff meeting today, and cache is still in for Beta.

If cache works by beta, we need to make sure that we don't retain copies of jar
installs triggered by XPInstall.

I'm going to set the bug to M12 for now, and depending on cache feature to be
in SeaMonkey bug 8305.

Comment 10

[Doug Turner (:dougt)]

this same behavior is in 4.x

Comment 11

[Cathleen]

since we're not doing 128bit for beta, this is a less concern for beta 1 that
high encryption installer or patch can be cached.

Comment 12

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 13

[Cathleen]

marking as INVALID!  :-)

bug meeting 3/20/2000

Comment 14

[Jimmy Lee]

Build: 2000-03-21-05-M15-nb1b(MAC), 2000-03-21-06-M15-nb1b(WIN),        
2000-03-21-05-M15-nb1b (LINUX)

Marking Verified.