Hello, I am really sorry for that. I think I have misunderstood the documentation about the AppStream mailing list. I will use the right list for now on :).
But about the YAML and XML file, yes, I must definitely think about how the format will look like. I will start to set my environment today for developing to libappstream, and I will begin to verify what should be included on the new metadata format as well. Best regards, Lucas Moura On Tue, May 3, 2016 at 9:20 PM, Matthias Klumpp <matth...@tenstral.net> wrote: > 2016-05-03 23:14 GMT+02:00 Lucas Moura <lucas.moura...@gmail.com>: > > Hello, > > > > My name is Lucas Moura and I am Google Summer of Code Student working for > > the Debian project. My summer project is related to AppRecommender, a > Debian > > package recommender system: > > > > https://github.com/TCC-AppRecommender/AppRecommender > > > > This application works by creating an user profile based on the user > > installed packages, this profile is basically the most significant terms > on > > all user packages. With this profile built, AppRecommender uses Xapian to > > query for Debian packages and display the closest ones with the query. > > > > Currently, this application can only be used via terminal access. > However, > > my gsoc project is to change that, and allow AppRecommender to be > integrated > > into graphical package managers: > > > > https://wiki.debian.org/SummerOfCode2016/StudentApplications/LucasMoura > > > > I have already discussed about this idea on the PackageKit thread, but > since > > this approach is now related to AppStream, It is best to change for the > > appropriate mailing list. The original thread can be seen on: > > > > https://lists.freedesktop.org/archives/packagekit/2016-April/026411.html > > > > In that thread, I have proposed the idea of creating a lib that would use > > AppRecommender as a backend application, and the lib would just be an > API to > > the application. However, Mr. Matthias Klumpp and Mr. Richard Hughes > raised > > some concerns over this approach, specially considering the speed from C > > > > python > C translation and the difficulties of maintaining a new library. > > > > One proposed approach was to implement the algorithm directly on one of > the > > libappstream projects. Although this can be done, I am just afraid of > having > > to maintain the same code on different projects.This would be a problem > if I > > decide to change one of the recommendation algorithms, since the > algorithm > > would need to change on two different places and in two distinct > languages. > > > > However, upon reading AppStream docs more carefully, I think my original > > approach was really flawed. Now, I think that instead of calling directly > > AppRecommender from the lib, the new function on libappstream would just > > read the content generated by AppRecommender, that should be able to > provide > > its recommendations as a valid XML format for AppStream. Therefore, what > I > > could add to libappstream is way to manage recommendations. Therefore any > > recommender system that wants to be integrated with AppStream would just > > need to generate a proper recommendation file and place it in an specific > > place, so libappstream can read it and manage it. > > That actually sounds like a solid plan :-) > > > I think that this approach would not add any new dependencies on > > libappstream. But I would like to ask if that is a good approach to > follow, > > or maybe the path is really to implement the recommendation strategies > > directly into libappstream. > > This should work easily, some details would be needed on what the new > metadata YAML or XML format would look like (adding it to the > AppStream data would only work server-side in a safe way). > > Btw, I think you've meant to send this mail to appstr...@lists.fd.o, > so I added it to CC. > > Cheers, > Matthias >
_______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/distributions