Summary: | replace mozilla address book parser with a new implementation that doesn't link to mozilla libraries | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Caolán McNamara <caolanm> |
Component: | Database | Assignee: | DavidO <d.ostrovsky> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | dr, ernstke+freedesktopbugzilla, fridrich.strba, lionel, michael.meeks, mst.fdo, sbergman |
Version: | Master old -3.6 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | EasyHack SkillCpp DifficultyInteresting | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 56902 | ||
Attachments: | Screenshot - do not see some non-latin symbols |
Description
Caolán McNamara
2012-06-12 04:32:18 UTC
Recently i made some progress on feature/mork branch. The follow steps are completed: o MorkParser is integrated (some weird problems are fixed, must blog on it, is really funny ;-) o Mozilla stuff is completely pinched off from the build. o Minimal Profile Discovery is shamelessly stolen from mozab driver. o mork_helper executable can discover the local profile, find the address book and dump it. o you can already import your address book: you would see AddressBook table. If you open it, LO crashes in OCommonStatement::parseSql. Question: Currently i am messing around with query parser in OCommonStatement: http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/mork/MStatement.cxx?h=feature/mork#n79 http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/mork/MStatement.cxx?h=feature/mork#n201 What is the best way to deal with it? Do we need here a parser at all? Should one be written von scratch that delegate to MorkParser? Or may be i could import the whole data in shadow sqllite file and forward the address book queries to it? What would be the simplest solution here that püossible would work? (It is not clear how XPCOM driver actually does that magic). Still to do: o MetaData retrieval o Lists facility (you can define list/group in address book) and it should be imported as own table o Query handler/parser o ResultSet population Fridrich, weren't you following this area to try to rid us of the internal mozilla ? :-) do you have thoughts here ? Some progress here: default AdressBook table can already be imported on feature/mork branch. Still to do: import group tables lazy loading (query take place to often now) sorting entry manipulation: add, delete, etc. is this actually needed? Sounds like great progress to me. Re what we need, I'd say we need whatever the writer mail merge can use when you click through its wizard. If that doesn't make use of it then we can probably skip/defer that functionality. hmm.. i'd actually prefer not to have any editing support in there and have the driver be read-only, because we directly access the address book files from the Mozilla profile, and who knows what could happen if you have that open in a running Thunderbird at the same time and perhaps make changes there. for the use case most people have (mail merge) read-only is sufficient. yeah, agreed. (In reply to comment #1) > Question: > Currently i am messing around with query parser in OCommonStatement: > http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/mork/MStatement.cxx?h=feature/mork#n79 > http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/mork/MStatement.cxx?h=feature/mork#n201 > What is the best way to deal with it? Do we need here a parser at all? Well, I haven't looked at it in detail, but I assume the driver needs to parse the SQL statement to know what to return: which columns, which rows, ... LibreOffice already contains a SQL parser: core/connectivity/source/parse/ Rather than reinvent the wheel, maybe you can reuse it? > Or may be I could import the whole data > in shadow sqllite file and forward the address book queries to it? That could be a possibility; sqlite is not necessarily a good choice, especially if the data contains dates/timestamps/... OTOH, you probably don't want to wait until we have a good Java-free embedded database engine, unless you feel like working on that, too ;-) (bug 51781 and bug 51780 and dependencies contain these discussions) > What would be the simplest solution here that püossible would work? > (It is not clear how XPCOM driver actually does that magic). It seems to use its driver's m_xMSFactory member to do the parsing, but that's a ::com::sun::star::uno::Reference< ::com::sun::star::lang::XMultiServiceFactory >, so I'm confused. (In reply to comment #3) > entry manipulation: add, delete, etc. is this actually needed? Making it read-only sounds like a reasonable choice. In this case, please: - return privilege metadata indicating that read-only status (only SELECT privilege) this indicates to the LibO UI not to let the user attempt any modification - if a modification is attempted (e.g. through a macro), throw a SQLException with SQLSTATE set to 2F002 and Message set to some descriptive user-friendly text; something like "the LibreOffice Mozilla address book driver is read-only" should do. ErrorCode is the driver's domain; just set it to a fixed unique value that is different from other situations in which you throw an SQLException. Another progress here. It was not lazy loading, but infinite loop. It was really hard to find/debug, because LO grabbed the mouse and keyboard ;-) @Michael Stahl thank you again for your help! @Caolan, what do you mean by saying: [...] Re what we need, I'd say we need whatever the writer mail merge can use when you click through its wizard. If that doesn't make use of it then we can probably skip/defer that functionality. [...] I have no idea, what are you talking about. Another progress here. Done issues: sorting queries with complex expressions error handling (exceptions forwarded to UI) TODOs: Group tables are ignored (only AddressBook Table is imported). SQL column aliasing is not implemented (select FirstName as name from AdressBook produces error). SQL regexp query expression is not implemented. ScalingWeb.com License is only copied into connectivity/source/drivers/mork directory. re "@Caolan, what do you mean by saying: [...] Re what we need, I'd say we need whatever the writer mail merge can use when you click through its wizard. If that doesn't make use of it then we can probably skip/defer that functionality. [...]" My belief is that the biggest and more useful usecase for address book integration is mail merges, so whatever features are required to make writer->tools->mail merge wizard->next->email message->select address book-> etc. functional are the important bits and everything else is gravy (In reply to comment #11) > > My belief is that the biggest and more useful usecase for address book > integration is mail merges, so whatever features are required to make > writer->tools->mail merge wizard->next->email message->select address book-> > etc. functional are the important bits and everything else is gravy mail merges/meat: it just works. gravy: regexp is not implemented, if query has something like that 'where name like "foo*bar" ' error is thrown group/list tables are not implemented. Working on it. history.mab is not implemented (only abook.mab is processed). Would be not a big deal. Question: i have seen link on this page http://wiki.documentfoundation.org/Development/Build_System/Module_status to this issue: "please do not convert moz, it is going to be replaced; see bug fdo#51004" i doubt, that we should track replacement for Outlook (Express) data provider for Windows in context of this issue. Moz ist still needed to access it. We should probably file a new bz entry for that. Xubuntu 12.10-64 Rus Thunderbird 17.0.3 1) Cannot see some non-latin symbols (see screenshot in attachment). 2) Worked only with main address book ("Personal Address Book") - not with user created. Created attachment 75955 [details]
Screenshot - do not see some non-latin symbols
(In reply to comment #13) > Xubuntu 12.10-64 Rus > Thunderbird 17.0.3 > > 1) Cannot see some non-latin symbols (see screenshot in attachment). > > 2) Worked only with main address book ("Personal Address Book") - not with > user created. LibreOffice 4.0.1.1 (ID: 400m0(Build:1) (In reply to comment #13) > Xubuntu 12.10-64 Rus > Thunderbird 17.0.3 > > 1) Cannot see some non-latin symbols (see screenshot in attachment). > > 2) Worked only with main address book ("Personal Address Book") - not with > user created. Please open new bugs for each of these different *new* issues / bugs instead of reopening a *different* bug, and mixing two issues in one bugzilla entry. As to non-main address book (user-created address books), did it work before? Thanks in advance. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.