[AppStream] <suggests>

[Lucas Moura]

Hello,

No problem for me. I think the other GSOC student will start working on
this new strategy this week. Therefore, I can keep in touch with him about
this feature on AppStream.

Cheers,
Lucas Moura

On Mon, Jul 25, 2016 at 11:16 AM, Matthias Klumpp <matthias at tenstral.net>
wrote:

> 2016-07-21 17:07 GMT+02:00 Lucas Moura <lucas.moura128 at gmail.com>:
> > Hello,
> >
> > After speaking with the other GSOC student working on AppRecommender,
> this
> > format may work for the work his is developing. His is work is to
> implement
> > an strategy in AppRecommender that recommends packages to the user just
> > after the user install a package. For example, if the user is installing
> vim
> > and uses git a lot, AppRecommender can recommend vim-fugitive to the user
> > after the install process is complete.
> >
> > Although this is not the usual scenario for AppRecommender, the suggests
> tag
> > can work for this new strategy. However, if you think it is better to
> think
> > of a new tag that encapsulates both approaches no problem. Either way, I
> > have sent a MR containing the implementation of the suggests tag. I have
> > implemented this feature like the first approach commented by Richard,
> using
> > a single suggests tag, but his idea for the tag name makes sense to me,
> so I
> > can change my implementation if that is necessary.
>
> This is actually very good news, because it means we can likely get
> rid of the more complicated and additional augmentation format
> proposed in the other thread.
> Having a dedicated merge component is much cleaner.
> So, if you can live with something like that, we can move forward with
> specifying the <suggestions/> or <suggests/> tag (whatever it will be)
> and resolve this feature request.
>
> Cheers,
>     Matthias
>
> > On Thu, Jul 21, 2016 at 11:40 AM, Matthias Klumpp <matthias at tenstral.net
> >
> > wrote:
> >>
> >> 2016-07-20 16:58 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> >> > Hi all,
> >> >
> >> > I've been trying to add <suggests> into appstream-glib. I've got a few
> >> > questions:
> >>
> >> Please don't implement that yet - this feature doesn't really work
> >> well for tools like AppRecommender, where apps are not the source of
> >> the recommendeation, which reduces its usefulness to just a way for
> >> upstream projects to recommend stuff.
> >>
> >> I would like to have some time to flesh out the details further,
> >> especially in the light of the new AppStream curation metadata
> >> proposal, which I am going to make.
> >> The sprint is taking quite some of my time though, that's why I
> >> haven't written down the proposal yet.
> >>
> >>
> >>
> >> > Is it supposed to be:
> >> >
> >> > <component>
> >> >   <suggests type="upstream">
> >> >     <id>org.example.Bar.desktop</id>
> >> >     <id>...</id>
> >> >   </suggests>
> >> >   <suggests type="some-other-method">
> >> >     <id>org.example.Baz.desktop</id>
> >> >     <id>...</id>
> >> >   </suggests>
> >> > </component>
> >> >
> >> > or:
> >> >
> >> > <component>
> >> >   <suggests type="upstream">
> >> >     <suggest type="upstream">
> >> >       <id>org.example.Bar.desktop</id>
> >> >       <id>...</id>
> >> >     </suggest>
> >> >   </suggests>
> >> > </component>
> >> >
> >> > To me the former makes sense, but the tag name doesn't -- in the other
> >> > tags a plural means we nest singular terms. Would doing this make more
> >> > sense:
> >> >
> >> > <component>
> >> >   <suggest type="upstream">
> >> >     <id>org.example.Bar.desktop</id>
> >> >     <id>...</id>
> >> >   </suggest>
> >> >   <suggest type="some-other-method">
> >> >     <id>org.example.Bar.desktop</id>
> >> >     <id>...</id>
> >> >   </suggest>
> >> > </component>
> >> >
> >> > I don't see the need in a <suggests> parent, although I'd be up for
> >> > that if you think it would make sense. Thanks!
> >>
> >> The idea was exactly what you proposed last, but as said, I am not
> >> sure that having this is a good idea at time, before we have a
> >> consistent story for how suggestions are handled in AppStream.
> >>
> >> Cheers,
> >>     Matthias
> >>
> >> --
> >> Debian Developer | Freedesktop-Developer
> >> I welcome VSRE emails. See http://vsre.info/
> >> _______________________________________________
> >> AppStream mailing list
> >> AppStream at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/appstream
> >
> >
>
>
>
> --
> Debian Developer | Freedesktop-Developer
> I welcome VSRE emails. See http://vsre.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20160728/9e03f332/attachment.html>