Closed Bug 20222 Opened 25 years ago Closed 20 years ago

implement RDF resource pseudo-aggregation in mailnews

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
All
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 211804
Milestone:
Future

People

(Reporter: scottputterman, Assigned: sspitzer)

References

Details

(Keywords: memory-footprint) 

convert mailnews to use new RDF resource aggregation.
Status: NEW → ASSIGNED
Target Milestone: M13
marking M13
Scott, is there a beta-stopper issue in here somewhere?
If we don't do this, then mail resources get instantiated before they need to be
used. Such as in bookmarks and when reading in localstore.rdf. This can lead to
a number of problems that we've been working around in the past.  This is
something that needs to be done.  If we wait until after beta it will be 3
months worth of code harder to change.  The changes will be risky.  My guess is
that if I don't do this before beta, these changes will never get made.
Target Milestone: M13 → M14
m14.
Too scary for B1. M16
Target Milestone: M14 → M16
Target Milestone: M16 → M18
Well, I think my comments from 12-20 proved prophetic.  Sorry about that.  
Moving to future milestone.
Target Milestone: M18 → Future
I think we should re-consider this. Of course, we need to do some evaluation,
but it may keep us from loading the messenger DLLs on startup.
Keywords: footprint, nsbeta3
I just verified that if localstore.rdf does not refer to any "imap" (or "news",
etc.) URLs, that no messenger DLLs are loaded.
*yikes* I just saw the thread that showed msgimap getting pulled into the
browser on startup because of this problem. That's a hefty dll to be pulling
into memory (over 400K on windows).

I'm sure footprint and bloat teams would give this a hard look.

What's the level of difficulty for doing this scott?
I really don't think we want to do this. We have to make a lot of changes to the 
mailnews datasources and front end.  It's risky and it's been risky for a long 
time. We should do this at the start of the next project in my opinion.

And this is probably a simplistic view of things, but if the user isn't a 
mailnews user then they won't see this problem.
I have to agree with putterman - this is a risky thing to try to do at this 
point... just so everyone understands - every place where we QI() to go back and 
forth between a resource and a mail object (like a message or a folder) is a 
place that must be changed.. so we have to grep for every instance of 
QueryInterface in mozilla/mailnews/*, examine what it's doing, and figure out if 
we need to switch to GetResource or GetDelegate.


- per mail triage
Whiteboard: [nsbeta3-]
reassigning to sspitzer and nominating mail1
Assignee: putterman → sspitzer
Status: ASSIGNED → NEW
Keywords: mail1
Blocks: 17392
marking nsbeta1-
Keywords: nsbeta3 → nsbeta1-
Whiteboard: [nsbeta3-]
QA Contact: lchiang → stephend
Woohoo, delegates to the rescue.

*** This bug has been marked as a duplicate of 211804 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
umm what is bug 211804 about? /me have not access :(
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.