[GSOC] Integrating AppRecommender with AppStream

[Lucas Moura]

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 <matthias at tenstral.net>
wrote:

> 2016-05-03 23:14 GMT+02:00 Lucas Moura <lucas.moura128 at 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 appstream at lists.fd.o,
> so I added it to CC.
>
> Cheers,
>     Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/distributions/attachments/20160504/c6fdd3d5/attachment.html>