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

Brian schrieb:
> On Mon, 2007-08-10 at 19:52 +0200, René 'Necoro' Neumann wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> At the beginning of next week, I'm planning to make portato use this new
>>> amazing backend :). We'll see if this is going to work... (Rumors say
>>> that currently dbus times out on the first connect...)
>> As promised, I finished a portato version which is using the new
>> catapult backend... (Btw - the rumor has been proved being wrong ;))
>>
>> You can get the code doing:
>> svn co https://svn.origo.ethz.ch/portato/trunk
>> or you can install portato with catapult support:
>> 1. layman -o http://portato.sourceforge.net/layman.xml -f
>> 2. layman -o http://portato.sourceforge.net/layman.xml -a portato
>> 3. USE="catapult" emerge -av "=portato-9999"
>>
>>
>> Now another question occurs: Am I the only one interested in this
>> project? Because there is nearly no feedback/suggestions/discussions
>> (except with bheekling in IRC)
>>
>> Regards,
>> - - Necoro
> 
> No, I am interested in working with you to develop an (hopefully)
> universal back-end.  Like others have said, I have been busy and not had
> more time to work on it.  I also need to finish some things and a few
> bug fixes to get a release out.  Any new back-end support will need to
> wait for a future release.

Yeah - sorry me =| ... I've been a little too impatient :)
> 
> 
> I almost sent a reply early this weekend, but you did say you would not
> be starting until this week and that you wanted to do some testing to
> prove or debunk some rumours as to it's performance.
> 
> I am glad that you have been able to debunk them :)
> 
> Now for some more nitty gritty things.  So far we have not
> discussed/decided which of the models you laid out we would base this
> new back-end on.
We decided (where "we" means: bheekling, araujo and me) to use (try?)
the structure mentioned here [1] as "No Daemon".

> So far it is just portato's existing back-end wrapped
> in dbus.  I think it is great for initial testing without expending a
> lot of effort in restructuring any front-end code.  But I do not think
> it would be usable for me at all.  Porthole has grown so much over the
> years that it's code was getting somewhat like portage's, huge files.
> For this next version I have spilt things up quite a bit, modularizing
> things better.  Have cut down memory usage quite a bit and sped things
> up quite a bit in the process.
> 
> 
> So far your catapult back-end is creating a
> package object for your front-end.  
Wrong... basically the "Package" and "System" classes are just a bunch
of functions. They do not behave in an object-oriented manner (ie. you
have to provide a CPV (cat/pkg-ver) for each call to the Package
object). So this really is functional. Perhaps they can be merged into
one object - just wanted to structurize a little bit.
I thought of doing it really object-oriented, i.e. creating a
dbus-object for each package in the tree (so you would then have for
example: "org/gentoo/catapult/packages/sys-apps/portage") but this kinda
screwed up dbus ;).

Portato (which supported switching backends for some time already) is
wrapping these functional calls into its own objects... see the
CatapultPackage object [2] as an example.

> 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.
Does not apply -- see above :)

> 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.

Yes - this is what we want to achieve.
What we need is a stable API - so that we can say: All backends have to
provide the following functions: ...

> 
> 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.

See 3 above ;)

> Anyway... my thoughts so far.  How about the others?  What do you see as
> your needs of a back-end?
>  
> 
> Another question, I have subscribed to the gentoo-guis list.  Is
> everyone else that is interested also?  Should we just use that list for
> now?  So I/we don't get 4 or five copies of an email from different
> directions.

I already removed you from the CC list. Should the Portato-Developers be
removed too?

> 
> As for IRC, I'm not that big on it.  Also I'm in the Canada/US Pacific
> time zone,  Necoro I believe is in Europe.  That usually means when I'm
> going to bed, he's just coming online and vice versa.
> 
*stabs the freaking timezones*

Regards,
- - Necoro

[1] http://catapult.origo.ethz.ch/wiki/structure
[2]
http://svn.origo.ethz.ch/wsvn/portato/trunk/portato/backend/catapult/package.py
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHC26Z4UOg/zhYFuARArXYAJ47EhHSWgynsdsDzYPc+XBGOvedPQCghYQj
10G/yRYmYS0Ukd1Q+wAYEDo=
=0TFY
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list