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.

Changing QA Contact from Grace to Jimmy.

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?

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

What does it mean to "trigger" a jar?

"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).

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

waiting for a cache story.

moving after beta.

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.

this same behavior is in 4.x

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.

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

marking as INVALID! :-) bug meeting 3/20/2000

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