Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-guis
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-guis@g.o
From: René 'Necoro' Neumann <lists@...>
Subject: Re: One backend for all portage GUIs
Date: Tue, 09 Oct 2007 23:54:51 +0200
-----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


Replies:
Re: One backend for all portage GUIs
-- Brian
References:
One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for all portage GUIs
-- Brian
Re: One backend for all portage GUIs
-- Luis Francisco Araujo
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: One backend for all portage GUIs
Next by thread:
Re: One backend for all portage GUIs
Previous by date:
Re: One backend for all portage GUIs
Next by date:
Re: One backend for all portage GUIs


Updated Jun 17, 2009

Summary: Archive of the gentoo-guis mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.