Re: [gentoo-guis] One backend for all portage GUIs

[René 'Necoro' Neumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luis Francisco Araujo schrieb:
> Brian wrote:
>> One of the things that I did was to create a separate db module. In the
>> past much of it was incorporated into our portagelib.  That makes it
>> more difficult to change back-end, package managers and update code for
>> changes from upstream.  So far your catapult back-end is creating a
>> package object for your front-end.  That may be fine for a fully
>> integrated program, but now you are separating it out into it's own
>> process and passing that structure to your front-end.  I don't know if
>> dbus is passing references (pointers) or making copies.  I think that
>> there is potential for large memory leaks that way.  Also portholes
>> definition of a package object is different than portato's as I'm sure
>> kuroo's and himerge's is.  I believe that the back-end should be
>> restricted to only interfacing the front-end to the package manager
>> enquiries along with some utility code for odds and ends to provide a
>> more complete back-end service.  By odds and ends I mean code chunks
>> needed to be able to provide missing features/functions of the different
>> package managers we may support.
>
>
> That's right, different front-ends have different package object
> representation. One of my idea was to write an initial library (probably
> on C so it can easily be used through many languages) , creating a set
> of sharable procedures between front-ends, this also could give us some
> ideas of how far a general package object representation is possible
> between the different front-ends ; i think that'd be a good way to start
> building this project.

This is the thing I'm waiting for atm ... the functions to implement (ie
the API)... I think, that it should be done in a functional way is
general consensus, isn't it?

>
>> I think that pothole's potagelib.py contents is more of what a back-end
>> should provide.  I'll be the first to admit (I'm biased) it needs work
>> and cleanup and there is room for it to grow/improve.  I do not think
>> that it should be providing package structures with embedded package
>> manager calls.  I think it should be restricted to the basic data types
>> returned by the package managers.  Any more complex structures should be
>> handled by the front-end code or any intermediate code it uses.
>
>
> Right, I also agree that this back-end should only generate general data
> that can be easily shared by many front-ends so they can handle these
> objects in whatever way fits better for each one. Now, the question is,
> what kind of data exactly would this be?, it's here where i think the
> library project would help to figure this out. But as to give an initial
> idea, this library could be usable by any kind of portage front-end (no
> only graphical) and should be easily used through different tools.

This is the point where dbus comes in handy ... it can be used by all
languages having dbus bindings (and if you don't have them - use the
ones in C and do some wrapping) -- even in shell scripts (using the
program "dbus-send"). But all depends on one thing: a stable API (sorry
if I'm repeating myself ...).

And we should not forget to implement the API in a way to allow
API-versioning (i.e. to be able to say: "I'm using Catapult-APIv0" and
the provider behaves in the right way).

Regards,
- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHC/ir4UOg/zhYFuARAohJAJ0e7BLLh9M+0csd12XKiqyu44o0VQCdHD1k
4spX4jB9eUN482eICrnSCoM=
=Qbfd
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list