Difference between revisions of "Performance/Meetings/2008 05"

Revision as of 06:45, 15 December 2009

Performance/Meetings/2008/05/22

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Performance Project

Date: 2008/05/22
Time: 16:04– 15:02
Meeting No.:

Agenda:

(16:04:26) mhu: Hi all, sorry for being late (traffic again)
(16:04:36) yugq: hi
(16:04:38) kuangl: hello
(16:04:44) liangjun: mhu: hello
(16:05:19) LiHeng: mhu:hello
(16:07:31) LiHeng: mhu:did you receive the mail of agenda and weekly report?
(16:09:47) mhu: sorry, yes I received your email (I was just looking it up).
(16:10:26) LiHeng: do you have some topics to discuss?
(16:11:58) mhu: Not more than you already suggested; the MID looks interesting...
(16:12:34) LiHeng: BenQ will sale thire MID in Eurpean
(16:13:00) LiHeng: first maybe Italic
(16:13:43) mhu: yes, I have heard rumours of this
(16:13:56) LiHeng: but OO in MID is slow
(16:15:14) LiHeng: Okay, we start from "Details of configtuining00 design", yugq and liangjun will talk about details of configtuning00
(16:15:18) mhu: yes, I can imagine that; do you have a (detailed) machine specification (cpufreq, memory, disk, ...)
(16:15:36) mhu: okay, yes lets start with cws...
(16:15:47) yugq: liangjun: please.
(16:16:22) LiHeng: mhu:yes, I will send specification to you
(16:16:26) LiHeng: ;)
(16:16:47) mhu: LiHeng: okay, thanks (16:19:10) yugq: OK, we want to refactor the configmgr completly. The main idea is to move some layer-merge-operation before application runtime.
(16:22:14) mhu: okay, I think we talked about this last time...
(16:22:16) yugq: re-construct the layer data struct using our simpler file format. and we will offer some tool to convert the file between which is used now and the new style file.
(16:23:41) mhu: I think you can do that, as long as you maintain the possibility to have multiple layers (e.g. a branding layer in addition to a share and a user layer).
(16:24:15) yugq: mhu: yes.
(16:24:41) yugq: and another idea is to merge the ini files.
(16:25:11) mhu: I think I understood last time, that you wanted to store the merged result in the users merged layer / home directory. ?
(16:25:57) yugq: mhu: yes.
(16:26:06) mhu: If stored in the users home directory, what size of the merged data (per user) do you expect?
(16:27:03) mhu: so, what i mean is: the size that is now used once (share) is then used for every user.
(16:27:36) yugq: mhu: actually, the size is almost the same with we using now.
(16:28:08) liangjun: mhu: I think the result of the default data merged to the share directory. and when user first use OO, we will copy the result to user home .
(16:28:13) mhu: but then times the number of users, instead of only once? or you mean the user-cache?
(16:28:39) yugq: because the share layer data is in the form of cache file in the user home directory.
(16:28:41) mhu: ...user-cache instead of shared xml?
(16:29:10) mhu: okay, understood. you are right, I forgot about the current cache. Good :-)
(16:29:21) yugq: ;-)
(16:29:43) mhu: okay, size is no problem then.
(16:30:01) liangjun: en ?
(16:30:11) liangjun: :)
(16:30:30) mhu: so, what about access control to elements that are marked "final" in the now "share" layer? How would that be maintained?
(16:30:36) LiHeng: shared xml for creating new users, and user-caching for search , modify, and ... at runtime
(16:30:42) yugq: and we will re-designed the xml file to a more effective style.
(16:31:42) mhu: as long as you maintain the logical structure (hierarchy of nodes), I think you can divide that up into different files on disk, yes.
(16:32:38) yugq: mhu: do you mean the default readonly data?
(16:32:52) mhu: yes, for example readonly data.
(16:33:21) LiHeng: mhu:more ndividual files maybe cause lots of I/O
(16:33:29) mhu: but some things might be "locked" by an administrator (security setting e.g.)
(16:33:50) liangjun: oh , I than we can set the attribute to identifier the data that is added or removed and the default data
(16:33:58) mhu: LIHeng: yes understood, number of files that need to be read is an issue
(16:34:04) LiHeng: sorry ndividual/individual
(16:34:05) liangjun: than/ thank
(16:35:04) LiHeng: yes, we want to reduce user-caching files
(16:35:39) yugq: data in share layer and user layer are seperated. and when run the application, user layer works and the modification to config data only affect the user layer.
(16:36:06) mhu: yugq: yes, that is how it is today, right?
(16:36:23) yugq: mhu: i think yes.
(16:37:03) mhu: okay, so how do you think you can maintain this property that the user cannot change some configuration data items?
(16:37:59) yugq: user can maitain the configuration data, but it is in user layer.
(16:38:14) mhu: I fact, my question is not really fair, because with todays cache, there is a theoretical method that the user can binary edit the config.
(16:38:44) yugq: Every user has it's own user data, and maintain the data of their own.
(16:38:54) mhu: yes, but...
(16:39:20) LiHeng: mhu:if some item is about security setting ,we can separate them to another files
(16:39:31) mhu: ...what I mean is a security hole: user shall not (and cannot change share layer)...
(16:39:58) mhu: ...if that is merged / cached and stored in the users home directory ...
(16:39:59) yugq: mhu: I see what you mean ...
(16:40:27) mhu: ...the user can change the data, even though an admisnstrator thinks he cannot do that.
(16:41:21) mhu: okay, but as I said, in realilty we have this problem today already with the cache.
(16:41:56) yugq: mhu: yes.
(16:42:58) mhu: and, if at all possible, we should design something that does not have this problem.
(16:43:12) LiHeng: mhu: In my opinion, if we don't want user to modify some config, we must create files which they don't have promissions
(16:43:15) yugq: mhu: and is this security hole serious?
(16:44:08) liangjun: I thank we can split some data about the security to new role ?
(16:44:11) mhu: well, I know of some customers ("paranoid" customers) which think this is a serious issue.
(16:44:12) yugq: we did not consider this before.:P
(16:44:48) mhu: yugq: no problem, the designer of the current cache also did not consider this :-)
(16:45:08) yugq: :)
(16:45:44) mhu: and, if we cannot be better than the current design, than we are at least not worse; but I would like to improve the design if possible.
(16:46:31) yugq: mhu: I think we can put the share cache in share directory.
(16:46:40) mhu: and, I would like you to understand the multitude of requirements that exited in the past, and that made the config so complicated.
(16:47:15) mhu: LiHeng: but the user cannot write to the share directory (no permission) ?
(16:48:02) LiHeng: how do you feel about we create a security caching file for every user , and deliver it to a safe place, and other settings can put into the normal caching file
(16:48:04) liangjun: I thank we can let the administrator can write to the share directory.
(16:48:42) mhu: We only need to provide a method to safely store "Locked down" / readonly config settings...
(16:48:43) liangjun: and some data about safe data we use new role .
(16:49:06) mhu: liangjun: yes, that would mean during installation, right?
(16:49:19) liangjun: no
(16:49:45) liangjun: mhu: after installed. I thank.
(16:49:51) mhu: so, when should an admistrator write to the share directory if not during install?
(16:50:25) mhu: usually, an administrator is involved only during installation ?
(16:50:56) liangjun: thank / think . sorry.
(16:50:57) LiHeng: mhu: I agree ,Maybe we append some idea for security control.
(16:52:05) mhu: LiHeng: okay, thank you. we should not forget that this security aspect exists, and that it is not correctly solved today.
(16:52:49) LiHeng: At first, we send a description of security to you, in next weekly report.
(16:53:15) mhu: okay
(16:53:35) yugq: I suggest two cache. One is in user layer, and the other is in share layer. When load the cache , we merge them. But this merging is a cache merging.
(16:53:51) LiHeng: please,check it, therefore , we must return to discuss more about it next week.
(16:54:40) mhu: yes, I think we will discuss this from time to time / review the design against this topic.
(16:54:43) LiHeng: yugq:take it easy, we need more work on it.
(16:55:02) yugq: LiHeng: yes. :)
(16:55:25) mhu: also, remember: one problem is solved, the size of the data in the users home directory :-)
(16:55:52) LiHeng: mhu:yes, we will be careful
(16:55:54) liangjun: yes :)
(16:56:17) LiHeng: mhu:now , we discuss next topic simply,OO performance job for MID or other cheap device.
(16:56:33) mhu: okay.
(16:57:06) LiHeng: do you think it necessary for do something for cheap device now?
(16:58:03) LiHeng: Mobile Internet Device will grow and user will increase more and more
(16:58:26) mhu: well, I think a build of OOo with sufficient performance on such a device would need to be built against (on) that platform.
(16:59:35) mhu: other than that, I think I need the machine spec first. performance (startup) usually is a product of cpufreq * memory * diskspeed
(16:59:48) LiHeng: parts of, MID by Lenovo , we only build it on RedFLag Desktop Version
(17:00:03) mhu: so optimization in all dimensions are probably necessary
(17:00:17) LiHeng: mhu:do we also establish simulative envaroment to test subsequent versions of OO for MID machine
(17:01:05) mhu: a simulator? I only know of valgrind. can't we test on a real device?
(17:01:50) LiHeng: no , it's not enough basic for run some tools
(17:01:54) mhu: valgrind = instruction cache simulator
(17:02:46) yugq: yes, i think valgrind like a virtual cpu.
(17:02:54) mhu: maybe plus "iogrind" if that is useful (haven't looked at it personally, only Michael Meeks has demonstrated it to me)
(17:03:26) LiHeng: oh.....
(17:04:11) yugq: I remember iogrind is developed by Michael Meeks.
(17:04:32) mhu: but to really see why OOo is slow on the device, we would need to measure some data on the device itself, if only to establish a realistic simulation.
(17:04:32) LiHeng: sometimes, MID have special hardware and different liberary
(17:05:13) mhu: LiHeng: that is what I meant with "detailed specification" :-)
(17:06:04) LiHeng: yes, i will gather them into a report and to send to you.
(17:06:43) LiHeng: it's a new job, for us, we also need more and more topic for it
(17:06:50) mhu: okay, thanks. It will not be an easy task to do, but if done right on MID, it will improve for all devices incl. desktops.
(17:08:00) mhu: I think it is also an interesting job; the idea being that every device should have an OOo installed :-)
(17:08:50) mhu: even factory preinstalled :-) :-)
(17:09:01) yugq: :-D
(17:10:10) LiHeng: that all today
(17:10:23) mhu: okay, I don' thave more also.
(17:11:01) LiHeng: mhu:please help us to check plan of security
(17:11:20) mhu: LiHeng: yes, of course I will help you.
(17:11:40) LiHeng: okay, bye.
(17:11:55) mhu: bye all, see you next Thursday.
(17:12:05) yugq: bye.
(17:12:15) liangjun: bye.

Performance/Meetings/2008/05/16

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2008/05/16
Time: 16:00– 16:52
Meeting No.:

Agenda:

(16:00:10) LiHeng: hello everyone, sorry i'm later
(16:00:42) LiHeng: anther meeting before this was delay :(
(16:00:44) mhu: Hi LiHeng, I think you are just in time (accourding to my clock, at least)
(16:02:16) LiHeng: mhu:for a long time I want to talk about veiw tools and creating a database to store raw data of profiling or other tests
(16:02:39) mhu: yes, I read this on the agenda
(16:03:43) LiHeng: there no tool can persist raw data and veiw them in good format ,in current satuation
(16:04:58) LiHeng: all test tools and profiling data are in its specail format ,and all of developer need install a lots of tools to view and analysis them
(16:05:07) mhu: yes; at best the persistent is file based in a text format (so that other tools or a human can read it).
(16:05:13) LiHeng: but no comparision
(16:06:35) mhu: and "analysis" often only means "look at data" :-(
(16:06:39) LiHeng: we also can support to export text and xml format
(16:08:15) mhu: yes, please continue; I did not wanted to interrupt you
(16:08:24) LiHeng: in fact, we just start to create a database to search and compare test result in different versions
(16:09:20) LiHeng: this project would be developed by Release Dept , Testing Dept and my Dept CH2000
(16:09:53) mhu: yes, collecting and making available data sets in a database sounds like a good idea.
(16:10:39) LiHeng: two month ago, i talk to you about test all version and report its effective in Beijing by CH2000,
(16:10:57) mhu: yes, I remember.
(16:11:38) LiHeng: i have thought how to get versions and publish test report
(16:12:05) mhu: yes?
(16:12:30) LiHeng: at last , i decided to create a database maybe a good way
(16:12:51) mhu: yes, I think so too.
(16:13:29) mhu: I'm not a database expert, but I think most people will understand this approach.
(16:14:26) LiHeng: we create a webserver , all people interested in performance of OO can veiw report and chart on web, that can couse more and more people to join sa
(16:14:45) LiHeng: sorry sa/us
(16:14:49) LiHeng: ;)
(16:14:50) mhu: maintaining all the test / analysis data manually only leads to "chaos", in that after some time noone remembers where all the data and result are / came from.
(16:15:32) mhu: yes, a web frontend is probably the best access method more most developers.
(16:16:09) LiHeng: at first, we can only maintain the raw data of performance test and profiling
(16:16:14) mhu: ...and get interested and join, as you say.
(16:17:04) mhu: yes, all beginning is with raw data
(16:17:32) LiHeng: so, we will create web view tools for profiling tools, tuning tools and other preformance tests
(16:17:32) mhu: ...that is natural, and no problem I think.
(16:17:56) mhu: good !
(16:18:24) LiHeng: :)
(16:19:42) LiHeng: ok,i will send the list of tools we want to you, please check it.
(16:19:55) mhu: okay, will do.
(16:20:04) LiHeng: second....
(16:20:16) LiHeng: Start to collect Representative documents and define benchmark for all test documents
(16:20:59) LiHeng: i talk about performance problem with our end user
(16:21:18) mhu: have you received any documents from Malte, or talked to Malte about documents that we are using internally here in Hamburg?
(16:22:14) mhu: ah, okay, understood. A set of sample "real live" documents similar to what users have, right?
(16:22:26) LiHeng: yes , i have. it's the tuning tool and document
(16:22:30) mhu: s/live/life/
(16:22:58) mhu: yes, the document(s) for the automated cws performance test tooling.
(16:23:10) LiHeng: in performance wiki, have a section to arrange the test document
(16:24:17) LiHeng: three categorization in it
(16:24:29) LiHeng: but Representative documents
(16:24:33) LiHeng: is empty
(16:25:26) LiHeng: so , i want get some from our and user and put them into performance project
(16:25:52) mhu: yes, to have such documents available on the wiki is fine I think.
(16:25:53) LiHeng: but i don't know are there some rule for test-case in OO?
(16:26:22) mhu: what kind of rule are you thinking about?
(16:27:28) LiHeng: some standart or basic requirment
(16:27:30) LiHeng: ?
(16:28:19) mhu: Not sure I know what you mean, but ...
(16:28:50) mhu: ...any document that shows real life / user problems is a good / valid test case...
(16:30:04) mhu: ...any document that a developer constructs to exercise some aspect of a problem might be a good test case...
(16:30:06) LiHeng: oh, i means, Are there some standards for test-case or document?
(16:30:23) LiHeng: ok, i see
(16:31:04) mhu: ...for example Niklas Nebel once has constructed a spreadsheet that takes very long to load but is very simple.
(16:31:50) mhu: ...so, it depends: when you want to otimize xml loading, take ODT, ODS, ...
(16:32:04) LiHeng: understand! thank you
(16:32:10) mhu: ..when you want to perfect MS import, take .DOC, XLS, ..
(16:32:15) mhu: okay, fine :-)
(16:32:40) LiHeng: yugq:do you have some problem you mentioned before?
(16:32:49) mhu: I just didn't know what you were asking, hence the long answer :-)
(16:33:34) LiHeng: mhu: but just answerd it:)
(16:33:47) yugq: LiHeng, yes
(16:33:53) LiHeng: please
(16:36:54) mhu: yes?
(16:37:09) yugq: mhu: I found Meeks wrote a piece of unit test code in configmgr(some thing like benchmark). But the benchmark I wrote is not using the CppUnit.
(16:38:36) mhu: well, CppUnit is for unit tests as you know; do you see a problem in not using it for your benchmark? I don't see a problem.
(16:38:55) yugq: I just want to know which way be better.
(16:39:02) yugq: :)
(16:39:37) mhu: As usual, it depends: when you it to be included into unit testing, then make it a unit test...
(16:40:22) mhu: ...if you only want it executed manually for a developer working on the module (and the test takes very long) make it a separate test program.
(16:41:00) yugq: OK, I think I know the point now. Thank you very much!
(16:41:28) mhu: I think it is okay, to start as you did. I you later have a good idea for a unit test, then we can make that later.
(16:41:51) mhu: s/I you later/If you later/
(16:42:03) LiHeng: mhu:anther thing about test documents
(16:42:11) mhu: yes
(16:42:17) LiHeng: We found some exercise document in WIKI but there are not some regular test and benchmark can confirm that problem have been dealt
(16:42:28) yugq: And I think a separate test program may be better. Because unit test generally test functional case, but benchmark test performance case.
(16:42:58) LiHeng: mhu:How do you feel about define some benchmark and test-case for every test document?
(16:43:18) mhu: yugq: yes, for a performance test case, you often do need an external driver program.
(16:44:11) yugq: mhu: yes. Just as I do now. Thank you!
(16:44:17) mhu: LiHeng: yes, if that is a "good" document, good := helpful..., then we probably should make a test around it.
(16:44:59) mhu: also: maybe "good" can mean "reference"
(16:45:37) mhu: ...can also mean...
(16:46:22) LiHeng: okay, when we gather Representative document , we will convert them to exercise document for performance project
(16:46:48) mhu: okay
(16:47:09) LiHeng: that all for me, today
(16:47:34) yugq: no more for me.
(16:48:05) LiHeng: mhu:do you have some topic you want to talk?
(16:48:06) kuangl: no more too
(16:48:27) mhu: I think that is all from my side also.
(16:49:22) mhu: maybe, how about xiuzhi? he does not attend our meeting for quite some time now?
(16:49:23) LiHeng: mhu: see you next week
(16:50:04) LiHeng: he is in a holiday
(16:50:11) LiHeng: fitment his house :)
(16:50:19) LiHeng: today
(16:50:29) mhu: oh, then I wish a good holiday...
(16:50:44) mhu: okay, then see you next week. Bye all.
(16:50:50) yugq: bye.
(16:50:52) kuangl: bye
(16:50:59) liangjun: bye
(16:51:07) LiHeng: oh , see you next week!
(16:51:09) LiHeng: bye

Performance/Meetings/2008/05/08

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2008/05/08
Time: 15:53– 17:24
Meeting No.:

Agenda:

(16:08:36) LiHeng: english,please!!!!
(16:08:38) LiHeng: :(
(16:08:39) LiHeng: :(
(16:08:39) LiHeng: :(I
(16:08:40) LiHeng: :(
(16:08:41) LiHeng: :(
(16:08:43) LiHeng: ::(
(16:08:46) yugq: OK
(16:09:02) LiHeng: chinese
(16:09:12) yugq: mhu is late again.
(16:09:30) LiHeng: traffice is very hevry
(16:09:39) yugq: :-D
(16:09:45) LiHeng: heavy / hevry
(16:10:12) yugq: Beijing more heavy
(16:10:41) LiHeng: much most
(16:11:36) yugq: LiHeng: Please talk about XML more detail.
(16:13:19) LiHeng: ok, i want to cache the handle of XML file, and parse it when it's using
(16:14:09) LiHeng: build a tree model with fast naming index
(16:14:43) yugq: Does it influence current Object Model?
(16:14:43) LiHeng: mainly, support XPath access
(16:15:00) LiHeng: maybe no
(16:15:33) yugq: Does current implemention support XPath?
(16:15:34) LiHeng: but after this work , it will support DOM3 interface
(16:15:45) LiHeng: a little
(16:16:01) LiHeng: and is not standarty
(16:16:16) liangjun: LiHeng: What to do about configmgr, continue or stop ?
(16:16:22) LiHeng: it's unformly
(16:16:27) yugq: DOM3 is inventing now, it seems not fully designed yet.
(16:16:52) LiHeng: liangjun:must continue, go go go
(16:17:06) LiHeng: why do we stop?
(16:17:27) yugq: He need a command:-D
(16:17:40) LiHeng: yugq:but some feature is useful!
(16:18:28) liangjun: Oh , can I write some code test it ?
(16:18:30) LiHeng: commands will be need only for stop or cancle,
(16:18:33) yugq: You did not mention XML parse
(16:18:43) LiHeng: liangjun,yes,yes
(16:19:32) LiHeng: liangjun:according to Benchmark ;)
(16:19:47) liangjun: ok , I try to do .
(16:19:56) LiHeng: yugq: did not ?
(16:20:04) yugq: LiHeng: I mean the parse model.
(16:20:22) mhu: Hi all...
(16:20:28) LiHeng: hi mhu,
(16:20:31) yugq: Hi
(16:20:36) liangjun: mhu: hi
(16:21:10) mhu: sorry, again I got stuck in a traffic jam (there was a car accident on the "Autobahn" from home to office)
(16:21:17) kuangl: hi
(16:21:24) mhu: hi all
(16:21:42) LiHeng: mhu: never mind
(16:22:09) LiHeng: traffic is a general problem all of the world
(16:22:47) mhu: maybe I need a few more minutes to prepare...need to look into my email...dig out your email...
(16:23:02) LiHeng: maybe we can fly in the future:)
(16:24:13) LiHeng: there is a attachment about benchmark of configmgr
(16:30:02) mhu: okay, now I've read the agenda, and the "benchmark.odt", and I'm ready to start.
(16:30:19) LiHeng: ok,1. Benchmark defination for ConfigMgr
(16:31:18) LiHeng: did you think the benchmark can view all change of configmgr?
(16:31:31) mhu: yes, the document looks good; structured approach to the problem. The only remaining question, as I understand it, is how to measure memory?
(16:31:51) yugq: mhu: yes
(16:32:00) mhu: yes, I think it describes the interesting observables.
(16:33:09) mhu: the time for individual items vs depth maybe more for your own interest (see that your caching works)...
(16:33:11) LiHeng: yes, we surely need measure memory
(16:33:45) yugq: One way is define a NEW macro, in which we do some memory measuring, instead the default new operation. And when benchmark the application we can build OOo with the NEW macro available.
(16:33:49) mhu: but measuring the conribution to module start time of course it a macroscopically observable measure
(16:34:08) LiHeng: conribution?
(16:34:21) LiHeng: what means conribution?
(16:34:26) mhu: s/conribution/contribution/
(16:34:34) mhu: sorry
(16:34:50) mhu: typing too fast a ttimes
(16:34:59) mhu: (and again :-) )
(16:35:25) mhu: as to memory...
(16:35:54) yugq: mhu: yes. But I think we just need a comparison to different versions or different implemention, so macroscopically maybe ok.
(16:36:03) mhu: ...under Linux, we could use the builtin memory manager (in module sal: rtl/alloc_*)
(16:36:43) mhu: yugq: yes, that is what I wanted to say, sorry if I was unclear.#
(16:37:05) LiHeng: we will add memory check into our benchmark
(16:37:37) LiHeng: and that will be use to measure 'configtune00'
(16:38:16) mhu: okay, please let me know if you need help with the sal/rtl/source/alloc* memory manager.
(16:38:56) LiHeng: thank you,
(16:39:10) yugq: mhu: yes
(16:39:24) LiHeng: by the way, did you receive last email about analysis of configmgr?
(16:40:16) mhu: oh yes, I've received that email. But I think, I have not yet read all of it. I'm trying to do that in parallel now.
(16:41:16) LiHeng: there are some vision of configmgr from us.
(16:43:09) LiHeng: i will send new benchmark plan with memory measuring in weekly report next tuesdays
(16:43:24) mhu: okay, do you mean the Weekly report document that you sent out on May 6 ?
(16:44:01) mhu: I have read that now; I think your analysis is approximately correct.
(16:45:05) mhu: and, as long as you maintain the basic functionality, I think you are free to simplify the implementation as much as you can / want / improves performance.
(16:46:35) LiHeng: yes, if we have a simplify base, we can trace more problems
(16:47:36) mhu: for example, different layers (now: {product / shared} and {user}) are probably needed, but the implementation can of course be changed.
(16:48:44) LiHeng: yes, we want to move some implementation before installation
(16:50:12) mhu: okay
(16:50:15) LiHeng: and while run under multi-user condition, we can provide a set of tools to deal it
(16:51:40) mhu: oh, I think the multi-user case is in fact the standard case, even on Windows ?
(16:51:52) mhu: we shoul
(16:51:56) mhu: sorry
(16:52:44) LiHeng: No , on windows we don't need multi-user
(16:52:48) mhu: we should probably not optimize for the uncommon case of a single user installation; that's probably only developers doing that (and knowing about the possibility).
(16:53:44) LiHeng: fine (16:54:27) mhu: but even under windows, you install into c:\\program files\... which is a multi-user installation, even if only one user uses the computer
(16:54:30) LiHeng: yugq:how do you think?
(16:55:15) LiHeng: yes,
(16:55:37) yugq: LiHeng: I think we could not modify the user requirment.
(16:56:04) LiHeng: ;)
(16:56:08) LiHeng: okay
(16:56:52) mhu: and for security reasons, many windows computers distinguish "Administrator" (installing the software) and "Me (unprivileged) User" (using the software).
(16:57:18) liangjun: mhu:Every user has his result data . I think .
(16:57:32) mhu: I don't know if I really understand what you both mean with "user requirement" ?
(16:58:00) mhu: liangjun: yes, that "result data" is the merged view in memory (or in users folder)
(16:58:01) yugq: mhu: Exactly multi-user case.
(16:58:25) yugq: :)
(16:58:39) mhu: so, do we then agree that we need (at least) the two layers of "share" and "user" ?
(16:59:25) mhu: (and maybe a "brand" layer in the future, when different brandings of OOo share the same base installation)
(16:59:45) yugq: I agree.
(16:59:50) liangjun: mhu: the result data is in users folder and view in memory.
(17:00:03) LiHeng: mhu:yes but the data in "share" only use to create new "user"
(17:00:10) mhu: liangjun: yes that is what I wanted to say also
(17:00:48) liangjun: mhu: ok :)
(17:01:04) mhu: LiHeng: okay, now I seem to understand; yes, I agree, the share is of course readonly and thus can be seen as a template for each user.
(17:01:39) LiHeng: :)
(17:01:42) yugq: :-D
(17:02:12) mhu: okay, with this my understanding I see where you are aiming at; maybe that is indeed a good Idea...
(17:02:33) yugq: some operations done before application runtime
(17:03:06) mhu: the only thing that comes into my mind is disc space consumed for each and every user in true multi-user environments (in megabytes per user).
(17:03:36) yugq: mhu: yes. This is a fallback.
(17:03:57) LiHeng: ok , we understand each other
(17:04:00) LiHeng: :)
(17:04:03) LiHeng: mhu:do you have time to discuss tools set, or i send plan in next weekly report?
(17:07:36) LiHeng: mhu:do you have time to discuss tools set, or i send plan in next weekly report?
(17:21:21) LiHeng: maybe network have some trouble again:)

Go back