OGo Directions / Java

Hi,

from the doc list:
---snip---
I dislike talking about thing being done before they are actually  
done, but at least I am shifting most OGo developments to JOPE/Java.
...
What this implies should be discussed on discuss, just wanted to raise  
the point that the existing codebase might be become important for  
starters in the future ;-)
---snap---

Anyways. Feel free to ask any questions ;-)

The current situation is that I have rewritten a big part of OGo Logic/ 
DocAPI in Java in 2007. I have a few custom play-stuff apps running on  
top of that (eg a HighRise like UI) and I'm currently doing a midsize  
project which uses that.
Most likely I'm going to commit the code to a public repository  
beginning of next year. Its much more performant than LSLogic (not  
because its Java, but because its designed from scratch ;-) and also  
has some neat enhancements.
There is no real UI yet, but something which resembles the "old" OGo  
should be pretty easy to do.
[Note: my work so far attempts to be fully compatible with ObjC OGo,  
ie database schema and doc storage]

It could be the basis for something like OGo 6.0 ;-)

Hence, most likely I won't put a lot of effort into the Objective-C  
parts besides maintenance until JOPE replicas work.
One of the biggest issues I have with ObjC is that the Apple version  
and the GNU ones are bound to diverge (eg Apple with GC and ObjC 2.0  
features ...), and that gnustep-base goals do not match my  
requirements on API stability and OS integration (and lF is a dead end  
anyways).

I'm not perfectly happy with all this but I think for 'developers'  
things will get much easier. Machines are fast enough for Java now and  
Java itself is now GPL, removing that dependency.


Well, as mentioned, feel free to ask any questions ;-)

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/
-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss