[packagekit] handling input

[Richard Hughes]

On Tue, 2008-01-01 at 15:11 -0500, Matthias Clasen wrote:
> On Jan 1, 2008 2:57 PM, Richard Hughes <hughsient at gmail.com> wrote:
> 
> > Well, it's an artificial restriction. If you removed the check and used
> > a package_id with a space then everything would still work. The point is
> > _why_ - can and should a package name ever contain a space?
> 
> I have no issue with this restriction on package names; I stumbled over it
> when I tried to set up a repository named "PK test" ...

Ahh gotcha. The name can be anything you want, but I think package_id's
and repo_id's should remain with no spaces.

> > > - update descriptions are artificially forced to be a single line by
> > > means of s/\n/;/. This looks, smells and feels like a bug introduced
> > > by the choice to funnel the frontend-backend communication through
> > > single lines on stdout...
> >
> > Yes, we have to do this to keep everything abstract for the non-compiled
> > backends. We have to work with backends written in python, perl, sh or
> > whatever. stdout is the lowest common denominator and also allows us to
> > test stuff trivially.
> 
> Sure, of course, if you bend down to the lowest common denominator, you get
> to do all the higher-level fun yourself, like string escaping,
> encoding issues, etc
> etc

Yes, indeed. It's a design decision which we can come back to later; I
think a private dbus connection is overkill here.

> > Why is s/\n/;/ a problem? Are there any other issues with this?
> 
> it is a problem because
> 
> <description>
>   Test update; see if this works.
>   Line two.
> </description>
> 
> Comes out as "  ;  Test update; see if this works.;  Line two.  ;"
> which will leave the poor user wondering about the package maintainers
> writing skills...

Sure.

> If you are really willing to swallow the "everything must be forced
> through a single line of ASCII" mantra, at least choose a
> transformation that can be undone in the frontend. The ';' is not a
> save choice for that, as the example shows.

Okay, what about if we encode everything with HTML, i.e. a new line
becomes <br>. I guess g_markup_escape_text might be a good converter
here. Ideas welcome.

Richard.