How big are your paragraphs? Are we talking 10K here, total? 1K? 100K? How long does it take to send 10K over your network? How many people are going to be requesting data simultaneously?
The first rule of optimization is you find out where things are actually bogging down. Unless your users are on really slow dialup, AND you're sending more than 10K data per request (under version 1), or # simultaneous requests * data size > 1 MB / second, I think you're going to find your bottlenecks elsewhere. Greg On Jan 18, 12:31 am, zixzigma <zixzi...@gmail.com> wrote: > Take GMail for example. > in the Inbox, you have a list of received emails, > > in addition to the mail Subject, there is a sentence from the opening > of the email. > in other words we have Subject + MAIL_BODY.substring(0, LENGTH) > > what is the best way to implement this feature ? > > if we were dealing with non-String objects, it made sense to just > fetch the fields that are necessary, > like a summary view, and provide detail as user required. making it two > + step process. > > but in this particular case, we have a list of paragraphs, and want to > provide a one line summary of each. > to prepare this one-line summary, we need to retrieve the entire text, > and then call substring, to get the one line summary. > > I have 3 solutions, but appreciate if you weigh in on how you would > implement this particular usecase. > > Solution #1 > > 1- get the text from the DB > 2- extract the first X characters (one-line summary) [do this on the > server] > 3- send this one-line summary to the client > 4-when client decides to see full text, sends a request > 5-this time send the full text > > Pros: - less data over the wire (instead of pargraphs after > paragraphs, only one line is sent) > Cons: - subsequent client requests would result in additional network > roundtrip > - string manipulation/extraction to produce the one line > summary results in delay > > Solution #2 > > 1-get the text from DB > 2-send the entire text to the client > 3-when displaying, show only the first sentence, > do this by extracting first X characters, doing this on the client > > Cons: transfering so much data can cause delay > Pros: - after initial load, fewer network roundtrip to fetch more data > - text manipulation on the client, > means no delay as a result of waiting for the server to do > the manipulation > > Solution #3 > > having a bit of redundancy, > add an additional field/column to hold the one-line summary. > in other words instead of making one-line summary derivative attribute > (which can be extracted by processing the entire text), we do it once > and store it in the Datastore. > upon user request, we grab this one-line summary column/field. > if user required complete paragraph, we get the column/field > containing the full text. > > Cons: redundancy might result in inconsistency, additional work to > keep data consistent > - when user requests for full paragraph, this results in a > server call, which > is not going to happen with Solution #2 > Pros: - no repeated processing overhead (text extraction/manipulation) > - best use of bandwith, never sending anything thats going to > waste. > > I am thinking of chosing Solution#3, > based on an advice by Google, > that basically stated Storage is cheap, but Bandwith is not, > and user attention span is short therefore no delay ! : ) > > have you implemented this functionality ? > whats your thought on this, > what would you do ? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
