On 2011/05/04 5:05, Alexandro Colorado wrote: > yep also "live content" would be nice. OOo supports many protocols maybe a bit old for this web 2.0, it still have many good ones like webdav and xmpp. > Modern enhcements such as webhooks could do the trick.
That sounds nice! On 2011/05/04 5:59, Mathias Bauer wrote:
Don't underestimate the performance overhead created by file access etc. Notebook applications usually give instantaneous access - you won't reach that with single ODF documents.
To improve system wide performance, I would like to stick on a hierarchical directory (folder) structure. The StarOffice, the grandmother of OpenOffice.org, was born in the mid of 1980s. The current OpenOffice.org has internally lots of DNA, i.e. code fragments, derived from her. One of them is that the "open(), malloc(), and read()" strategy (a). That could be replaced with "open(), mmap()" strategy (b) to improve system wide performance. With the strategy (a), 1. The OS assigns physical memory pages to receive data from a disk device via Direct Memory Access (DMA). 2. The OS assigns physical memory pages to hold tremendous number of processed, chunk data, e.g. OUString. With the strategy (b), 1. The OS assigns physical memory pages to receive data from a disk device via Direct Memory Access (DMA). 2. The OS maps the physical memory pages to virtual memory pages. The application accesses the contents via its virtual memory. With (a) 2, the memory pages becomes "dirty" and are "private." With (b) 2, the memory pages remains "clean" and are "publicly sharable." Pros and cons. In general, strategy (a) consumes memory of twice size of target file and each instance of application consumes own memory. In contrast, strategy (b) consumes memory of the same size of target file and every instance of application shares the single memory. Therefore, for the Notebook application, I would prefer a set of simple files rather than a single zipped file which requires own, dirty memory pages. To improve response time, I would like to incorporate on-demand content retrieval. Imagine that when you want to see the only first sheet in a Calc file, you might not expect the Calc application to expand entirely the zipped Calc file into the memory and to parse completely its internal XML data including other sheets. What I want to do for this Notebook application would be: (1) no zip (2) directly mapping the only interesting set of file "content.xml" and corresponding XML files into virtual memory. (3) read the only interesting portion of XML file through the virtual memory. (1) and (2) would be easy, but (3) might be hard, though. The Notebook file might look like a set of a single file "sample.odn" and a directory (folder) named "sample_files," which resembles a set of "index.html" and "index_files." Anyway, our goal is to keep inspirations, memorandum, and attachment files somewhere in a greatly easy way and to share them with some small number of PCs and users.
If we restrict ourselves to Writer documents, the closest you can get to that "snappy" appearance is a container like a glossary file.
Right. That's the reason why I would say "development." Don't you think the concept of "Data - Group and Outline - Hide Details" in Calc could be also applied to Writer? Is it hard to incorporate the similar user interface of http://www.tiddlywiki.com/ into Writer's HTML Document? Several exciting challenges are waiting for us. :-) Best regards, Tora -- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help
