GWorkspace metadata service - state of the codebase

[Ivan Vučica]

Hi,

tl;dr Reading metadata service code made me sad. I'd like to make some
changes. I don't think they'll impact performance, but they might.
Tell me what you think.


I was applying an inbound patch from Debian devs into GWorkspace.
  
https://github.com/gnustep/apps-gworkspace/commit/497e0c07119c46485440b2fc28f727de855a2651

I was trying to wrap my head around it and came up with a small cleanup commit.
  
https://github.com/gnustep/apps-gworkspace/commit/628d0d172068370e132c673778a76d532b6c9843

The experience made me slightly sad.

(1) A bunch of functions defined in gmds.m are copied (!) into
mdextractor.m. These seem to be functions called back from sqlite3 so
their results can be used in SQL queries.
(2) C seems to be the norm instead of ObjC, even in string
manipulation. Even if we want to stay in C land, str{,n}cat() is not
used when it could be.
(3) I am very surprised that gmds creates user-defined SQL
functions... and triggers... which seem to be applied onto temporary
(i.e. in-memory) tables... and call seem to be used in calling back to
the user-defined SQL functions? Or something? I am confused why this
is seemingly so upside-down. Anything wrong with using usual
Foundation observers? Why this complicated use of triggers and custom
functions? Why not use SQLite merely as a storage layer?
(4) mdextractor.m uses an ObjC wrapper around SQLite... but gmds.m doesn't? Why?

However... the other stuff makes me feel like it might be sacrificing
readability to get some performance. I'm intuitively thinking that
this tradeoff is not worth it.

What I'd like to do to (or, if someone feels like doing it instead,
see it done):
- (1) Move path_moved() and other reused functions injected into
sqlite3 into a reusable library.
  - Alternatively, if there is some *important* function call overhead
when sqlite3 calls back into this code, I could just move it into a
header?
- (2) Rewrite path_moved using NSString (and its own NSAutoreleasePool).
  - Alternatively, rewrite that path append using strncat().

- I don't think (3) is addressable without a fundamental rewrite,
which I am not motivated to do. (I'd have to first become very
familiar with this part of the ecosystem.0
- (4) I'm not very concerned about. If someone feels like fixing it,
it seems trivial. It's just a curiosity.

Do people actively using GWorkspace and gmds see any *important*
performance reasons why any of this would not be done?



Oh, and not related to patches: GWorkspace is currently crashing for
me in -[FSNIcon setNodeInfoShowType:]. (Specifically in
objc_msgSend_fpret().) I happen to have just built and installed
latest libs using clang 3.8 and ng-gnu-gnu triplet. I run it under i3,
and obviously with --enable-gwmetadata (as I was trying to test
whether I broke gmds). Any thoughts?

The crash doesn't hurt me much except that I couldn't test gmds. I'm
probably going to rebuild everything with gnu-gnu-gnu later just to
confirm whether this is affected by a compiler/runtime misinteraction.