[BlueOnyx:11402] Re: Fund-raising for a modern BlueOnyx theme

Tjerk Hacquebord lists at hqmatics.nl
Tue Sep 25 04:25:09 -05 2012


I understand it would be a lot of work because that's basically the whole
system.
EAV is great but maybe a little bit of overkill for the amount of data. One
could also do with a table of properties I guess. But let's just forget
about that for now. Great to see all this development being planned.


Tjerk

-----Oorspronkelijk bericht-----
Van: blueonyx-bounces at mail.blueonyx.it
[mailto:blueonyx-bounces at mail.blueonyx.it] Namens Michael Stauber
Verzonden: dinsdag 25 september 2012 11:08
Aan: BlueOnyx General Mailing List
Onderwerp: [BlueOnyx:11400] Re: Fund-raising for a modern BlueOnyx theme

Hi Tjerk,

> Good to see the layout is going to be renewed. I like it so I did a 
> small donation and encourage everyone to do so.

Many thanks! Much appreciated.

> In terms of renewing.. would it be an idea to drop CODB when 
> implementing the new design?
> CODB has a way of getting corrupt and its actual data is 'invisible' 
> to most users. Why not use something like a separate MySQL local admin 
> server to generate all the config files etc?
> It has advantages in backup, error detecting, inserting, editing data..
> I know it has nothing to do with the design but maybe when 
> implementing the new design it is a good time to look at the other end
too.

Yeah, we have discussed this on the developer's list. I'll quote parts of
what I said there:

---

Sure, CODB is a hog. It's basically an archaic database with single user
capability, is slow, ugly and prone to generate database artifacts which are
very difficult to repair. Greg and I talked about the possibility of
eventually replacing CODB with a MySQL database that supports the
"entity-attribute-value model" (see:
http://en.wikipedia.org/wiki/Entity-attribute-value_model).

While this would be awesome, the problem there would be that we'd need to
pull off some heavy duty C programming to hack a MySQL compatible interface
into CCE to provide a client- and server-interface so that Sausalito can
talk to the new MySQL database layer instead of using CODB. But that is
something that I can't code.

Most pre-made frameworks [we also talked about switching the GUI entirely to
a pre-made framework such as Zend, Yii or Kohana] already have some kind of
database backend. That may be SQLite, MySQL, Postgres, or something else.
And while that may be good for storing things in
general: We really need the "triggers" that CODB provides to fire off
handlers on certain database events as defined in our module config files.

I understand that this can also be done with MySQL to some degree. But as
said: It's like going back and starting the whole project off a blank page
with nothing but some enthusiasm and some weird ideas.

---

So let me say this in closing: Yes, in the long term it would be beneficial
if CODB was also replaced with something else. However, that would a massive
undertaking which is a bit beyond what we can do at the moment. Let us take
this one step at a time and during the first step we'll see a much more
modern GUI. That will also give us the chance to dust off some of the core
code of BlueOnyx and to streamline and modernize it. CODB however will have
to remain as it is for now.

--
With best regards

Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx




More information about the Blueonyx mailing list