gstep-base Re: [OGo-Developer] OGo Invoice Application

[Helge Hess]

On 27.12.2007, at 08:03, Sebastian Reitenbach wrote:
> sogo is using with gnustep-base, so sope is known to work with it.

So what, SOGo was built something like 8 years after OGo and is a  
significantly smaller codebase, and is currently developed on top of  
gstep-base.

> But I know, there are still subtle compatibility bugs regarding ogo,  
> e.g.
> memory management...

Exactly. As I mentioned, Cocoa works quite fine, so its not really OGo  
specific.

>>
> But I have no real idea, what exactly you mean with *proper* FHS  
> layout.

Well, what is the FHS layout you accomplished? Do the server binaries  
properly live in sbin. Are binaries properly versioned and can be  
installed in multiple versions?

> Is there a document that states, what would be a acceptable layout  
> or not?

The wished for layout is the one we currently have (more or less what  
is required by FHS/Debian?!).

> I've no idea how my sope makefiles would work together with cocoa on  
> a Mac.

That shouldn't be an issue.

> In my eyes, this point b is the easiest to solve, and I'd go update  
> my sope
> gnumakefiles, and create some for ogo

Yes, it would be very nice if we could move SOPE and OGo to gstep-make  
2.0.

> but it would really really help, if  there is a document that  
> states, how a good layout would look like.

That would be the FHS standard. Its probably easiest to look at the  
current layout ... But actually its rather simple:

   ROOT/
     sbin/
       ogo-webui-x.y
       ogo-zidestore-x.y
       ...
     bin/
       ogo-account-add-x.y
       ...
     lib/
       libOGoABC.x.y.z
       sope-x.y/
       zidestore-x.y/
       opengroupware-x.y/
         commands/
           ...
         datasources/
           ...
         webui/
           PersonsUI.lso
           ...
     share/
       sope-x.y/
       zidestore-x.y/
       opengroupware-x.y/
         templates/
           ...


>> c) make gstep-make/base API stable. Doing that once is easy because
>>    we could just make a vendor branch and use it. But the vendor
>>    branch would need maintenance as well, and a fork in general
>>    s***s. This is an inherent gstep issue and I would be
>>    massively surprised if it would go away ;-/
> again, sogo is based on gnustep-base, so in my eyes, it cannot be  
> such a big
> deal.

I fail to see how your eyes work then, its rather obvious :-)


> Well I have no idea, how much time is spent to keep sogo compatible
> and working with gnustep-base. As I am subscribed to the CVS changes  
> of
> gnustep-base, I see the changes that happen day by day. It's not that
> overwhelming ;)

The issue is that certain important things are quite unstable, eg KVC.  
Subtle changes are done and few people really care about backwards  
compat.
Even non-subtle, large changes are done w/o upgrade pathes, eg just  
consider how much work the gstep-make 2.0 brought to us!


>> Personally I would prefer to focus on getting JOPE compiled and
>> working with the GCC Java compiler (GCJ).
> Personally I have a hate against Java (I know it's a bit stupid

Yes, it really is ;-)

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/