baseclient getListing does not return metadata

[michielbdejong]

looking at the code, getListing returns the itemsMap straight from either node.common or node.local, but the docs say it returns the metadata for each item. we should either restore the behavior as documented and as it was in 0.9, or introduce a getMetaData function (since retrieving the metadata for each item may be costly for large folders, and it is actually quite seldom that you need to know ETags and contentTypes).

in any case, items with a value false in node.local should be removed from the itemsMap before returning the getListing result

[raucao]

It should return meta data. It literally says "get my the listing", which is filenames plus x (depending on spec).

[michielbdejong]

sure, but speed is also important.

[raucao]

... which is why meta data should probably be cached in the directory nodes. I don't understand why that's not the case anyway. For remote listings it doesn't change anything, though.

Another option would be to have a metadata=false parameter.

[michielbdejong]

OK. It was moved because the metadata can now be different for the common, local and remote versions of a single node, and we have to keep track of all of them in parallel, so there is no good way to represent that at the parent node.

For remote listings it is still necessary to check all children for unpushed local changes.

[raucao]

For remote listings it is still necessary to check all children for unpushed local changes.

Not when using no-cache like e.g. in Sharesome. And from an app developer's point of view I really don't understand why you'd do that with FLUSH. When you don't cache stuff, you usually want the listing of what's stored, not of what's going to be stored.

[michielbdejong]

Right, but in the -nocache build I think getListing already just returns simply always exactly what comes in on the wire, so there it's not broken afaik.

I don't agree that you want getListing to return the current value when a change is being pushed out. Imagine you add an item to a todo list, and then do getListing to redraw the view immediately afterwards. I can't speak for other app developers, but I would like to see the item already added there, then.

[raucao]

That's what I'm saying. I haven't seen people using getListing or getAll do redraw. You'd usually use the successful promise of the storeObject and then a getObject at most. When I use getListing or getAll in my apps, I always want what's stored, and never the change queue, and from what I've seen in the wild when I helped with upgrading most known apps recently, I'm fairly sure that's what most app developers do and want.

[michielbdejong]

OK, apart from whether it should return with or without local changes, we still didn't fix this issue.

Let's

• remove the : false entries,
• make it return metadata again by default, the way it is documented since 0.9
• add an option to disable potentially costly metadata retrieval when not needed

[michielbdejong]

proposed a half-fix in #720

[michielbdejong]

to make it clearer what this "half-fix" is, I split off the part about "no way to query metadata in current master" into #721, so that we still have an open bug for that even if #720 gets merged.