Review Request 125797: protocoltojson application
Alex Richardson
arichardson.kde at gmail.com
Tue Oct 27 12:52:17 UTC 2015
> On Oct. 26, 2015, 5:27 p.m., Alex Richardson wrote:
> > The protocoltojson program will have to read the plugin metadata.json file to insert the "KDE-KIO-Protocols" to that json file as it is not possible to embed more than one JSON file into a Qt plugin.
> >
> > I am not sure whether we need a CMake macro, to me this is a conversion that should be done once and then we store the JSON file in the repository so that we don't increase the build time.
>
> Christoph Cullmann wrote:
> Actually ioslaves have atm no other json stored, this would be the only meta data added to them, I think no ioslave is at all a qt plugin and to stay compatible, I would only add a dummy class there with this json embedded to have the meta data available. But perhaps I am mistaken.
> For the one time conversion: I am not sure that the .protocol files will be deprecated, I thought to do it like ATM for the .desktop files for the plugins for which we kept the .desktop files, too.
>
> David Faure wrote:
> IIRC we kept .desktop files because there was no other way to translate them, back then.
>
> But that's not an issue anymore, and not an issue for .protocol files anyway.
>
> So when converting an ioslave to json, rather than just change its cmakelists, we could also just convert the .protocol to json, either with a one-time conversion tool (now that you wrote it...) or by hand, reading some documentation on the format.
> Seems simpler than more cmake magic.
>
> KIO will need to keep being able to parse .protocol files anyway, for compat reasons, that's unrelated.
>
> Christoph Cullmann wrote:
> Ok ;) That makes its easier, no cmake foo needed, cool.
> For the second issue: I am right, or? There is no other meta data we need inside the io slave?
>
> Christoph Cullmann wrote:
> My idea would be to add some:
>
> /**
> * Pseudo plugin class to embedd meta data
> */
> class KIOPluginForMetaData : public QObject
> {
> Q_OBJECT
> Q_PLUGIN_METADATA(IID "org.kde.kio.slave.http" FILE "http.json")
> };
>
> to each slave that then uses the meta data json as above.
>
> Moc will then embedd that like needed and no more stuff is needed to have the protocols meta data in the .so files, at least that seems to work for me.
Ah I thought there was already some JSON embedded. This makes it much simpler.
I don't think any of the default KPluginMetaData values are useful for KIOSlaves (e.g. Icon can be different for each protocol) so only having these JSON keys should be fine.
We can always add KPlugin { foo: "" } later if we need it.
- Alex
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125797/#review87444
-----------------------------------------------------------
On Oct. 26, 2015, 5:03 p.m., Christoph Cullmann wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125797/
> -----------------------------------------------------------
>
> (Updated Oct. 26, 2015, 5:03 p.m.)
>
>
> Review request for KDE Frameworks, Alex Richardson and David Faure.
>
>
> Repository: kio
>
>
> Description
> -------
>
> Application to convert multiple .protocol files into on json map.
> If this is acceptable my next steps would be:
>
> 1) use this, to generate json files and embedded them in io slaves
> 2) extend the protocol factory to search in the embedded files
>
> That would make the protocol factory parts of: https://git.reviewboard.kde.org/r/125778/ not needed.
>
>
> Diffs
> -----
>
> src/CMakeLists.txt f65ad8e
> src/protocoltojson/CMakeLists.txt PRE-CREATION
> src/protocoltojson/main.cpp PRE-CREATION
>
> Diff: https://git.reviewboard.kde.org/r/125797/diff/
>
>
> Testing
> -------
>
> Feed in http slave files:
>
> ./protocoltojson -o http.json /local/cullmann/kf5/src/frameworks/kio/src/ioslaves/http/*.protocol
>
> We get mapping:
>
> {
> "http": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "output": "filesystem",
> "protocol": "http",
> "reading": true,
> "writing": true
> },
> "https": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "config": "http",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "output": "filesystem",
> "protocol": "https",
> "reading": true,
> "writing": true
> },
> "webdav": {
> "Class": ":internet",
> "Icon": "folder-remote",
> "X-DocPath": "kioslave5/webdav/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleteRecursive": true,
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "listing": [
> "Name",
> "Type",
> "Size",
> "Date",
> "AccessDate",
> "Access"
> ],
> "makedir": true,
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "moving": true,
> "output": "filesystem",
> "protocol": "webdav",
> "reading": true,
> "writing": true
> },
> "webdavs": {
> "Class": ":internet",
> "Icon": "folder-remote",
> "X-DocPath": "kioslave5/webdav/index.html",
> "config": "webdav",
> "defaultMimetype": "application/octet-stream",
> "deleteRecursive": true,
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "listing": [
> "Name",
> "Type",
> "Size",
> "Date",
> "AccessDate",
> "Access"
> ],
> "makedir": true,
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "moving": true,
> "output": "filesystem",
> "protocol": "webdavs",
> "reading": true,
> "writing": true
> }
> }
>
>
> Thanks,
>
> Christoph Cullmann
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151027/15766eb7/attachment.html>
More information about the Kde-frameworks-devel
mailing list