[haiku-depot-web] Re: Sample Data
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-depot-web@xxxxxxxxxxxxx
- Date: Mon, 30 Sep 2013 16:32:17 +0200
On 09/29/2013 05:39 PM, Ryan Leavengood wrote:
On Sun, Sep 29, 2013 at 5:12 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
That reminds me: Have you already thought about how to read package and
repository meta data from the respective files? Writing a parser for the
HPKG and HPKR formats would be quite a bit of work, so I would suggest to
either make use of libpackage (via JNI or JNA) or parse the output of the
"package" and "package_repo" commands. For the latter the output would need
to be canonicalized -- mainly making sure that strings like the summary and
the description are printed in a way such that they don't make the output
ambiguous and that they can be parsed into their original form again.
I was thinking about this problem as well. The formats do seem a bit
complex, so it makes sense not to reinvent the wheel. I personally
think the idea of parsing the output of commands is a bit messy. For
one thing, can those commands be compiled to run on other platforms? I
certainly wasn't planning on using Haiku as the OS for this web app.
Of course this also applies to libpackage I suppose.
Yes, Haiku's build system can build libpackage as well as the "package"
and "package_repo" commands for any supported build platform. The latter
is already used on haiku-files.org to create the new repository when a
package file changes. This all comes with the context of the Haiku API
emulation -- i.e. libroot_build, libbe_build -- so it isn't particularly
beautiful. But still, it's already there and working and will be
maintained anyway.
Unless there's a way to quasi-automatically generated bindings for the
C++ package kit headers, I would say using the commands and parsing
their output is probably the solution quickest to implement. We could
even add an option to explicitly produce machine-readable output instead
of tinkering with the standard output to make it machine-readable.
What would be ideal is a cross-platform, C-based library which could
be easily connected to from any language we choose. Pretty much
anything can talk to C, whereas C++ can be a bit more tricky (but I'm
not an expert.) Of course I know this library does not yet exist, but
it might behoove all of us to consider this approach and create this
for all our benefit.
Yeah, one can always dream. ;-)
While it might be nice to have such a library, it would not be nice to
write it. At least not for me.
[...]
Lastly I think performance should be considered here as well. Maybe
some of this parsing will be done in the back-end and not ever done in
a web request, but nonetheless being able to parse these files as
quickly as possible would be nice. Is libpackage considered optimized,
or is there still work to be done there?
libpackage has not been specially profiled and optimized, if that's what
you're asking. But (save for a minor optimization that only concerns
updating package content) I'm not aware of anything that should be
optimized -- I usually add TODOs right away when writing code that I
know could/should be optimized.
At BeGeistert Oliver tested updating a repository file on baron and IIRC
the times where about half a second (which included both reading a
repository file and writing a new one) for a current HaikuPorts
repository. The repositories will certainly still grow quite a bit in
size, but unless a repository file is read for every request, I don't
think performance should be much of a concern.
CU, Ingo
Other related posts:
