[vlc-devel] [PATCH] GSoC: lua services discovery, take two

[Fabio Ritrovato]

> An input_item_t is what represents path. But it can even represent more
> complex item with meta data. It makes sense to use it here.

What I meant by waste was, with your method, I'd have to first create
an input item with the local path, pass it to the function, and then
create another one with the new path, instead of passing a string a
simply...
Also, if the SD is one of those who needs a parameter string,  holding
that in an input item will require a lot more space...

> We want to refrain that, so that it closely match what the user would
> expect.
>
> Hum. Wait, after re-reading your mail SaveItem is actually SaveItems!
> The ideal user scenario is:
> - You add a lot of item to the SD
> - You expect it to be in the SD as soon as you add them.
> I guess that we can't achieve the ideal user scenario gracefully with what
> you have (right?).
> Then, the name I would pick would be SynchronizeItems(), or
> FlushAddedAndDeletedItems() instead of SaveItems().

Ok, you totally lost me on this :)
ItemSave is to save a single item from the SD, but since they can be
strange items, you can just right click-save as you would do with the
usual ones...
For example, in the MTP SD, to transfer a file from the device to your
computer, you will have to pass by libmtp, so ItemSave does just that,
define a way for the item to be saved...
Another example (not implemented, but could be), would be saving
youtube video, ItemSave will find the url of the .flv, and save it on
your pc...
If you already got that, then it's me that i don't get what you want to do...

> oh! So far, after re-reading your patch:
> - This parameter function doesn't really belong to the services_discovery
> API. It should pobably be some kind of helper in lua sd I believe. From what
> I understand this is just a convenience so that all lua SD can describe
> their hierarchy, and the associated query.
> - All the tree hierarchy that you will end up creating, should be done by
> adding a node input_item_t.
> Can this work?

You mean, using input_items to hold the parameter tree?
Isn't that a waste of space, using a structure that holds lots of data
i don't need, instead of mine that holds just the 3 strings i use?
Also, I think it'll primarly be used for lua SD, but as it is rigt
now, nothing stops one to use it in a C SD too...