I prefer BOSS to Omnibase

OmniBase may be great but I never have learnt to use it easily. Though BOSS is
limited in function but it's easy to use and I don't have to worry about the
design as whether it can fit into storage.

I hope CinCom would continue develop on it and make it an object db.

Any others have the same feeling?

Best Regards,

Jim G

Yes, BOSS is great. I did find it had problems when the number of objects gets to high.

David




--
David Long
Wakefield Operations
Savant Connect Technical Services
CEO, Satellite Forces
ph) 613 796 3048
e) [hidden email]
http://wakefieldcomputer.com
http://savantconnect.com
http://satelliteforces.ca


_______________________________________________________________________

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations.
Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

Well,

we ran into problems with BOSS when we wanted to use it as a persistent
storage for our domain objects. The problems arose when we modified classes
of our objects (made a new version of the format) and still wanted the old
ones to load and function properly...

Long story short, we left BOSS and developed our own machinery built
on top of XMLParser which seems (so far) to suit our needs better.

Ladislav Lenart

David Long wrote:

Probable indeed a long story short, but still I would like to know what issues you encountered. Especially with functionality that is currently part of BOSS regarding migration of class format. I expect you used things like representBinaryOn: and binaryReaderBlockForVersion:format:? In what way did that not do what you needed?

I also have problems with BOSS, trying to read back an export with the
Obsolete* objects got serialized. Reading such exports cause an UHE and
I didn't yet find a way to solve that problem. It is a very big problem
if you use BOSS for backups and after a while realize, that you cannot
restore anymore...

Janko

Rob Vens wrote:
--
Janko Mivšek
Svetovalec za informatiko
EraNova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

Rob Vens wrote:
> Probable indeed a long story short, but still I would like to know what
> issues you encountered. Especially with functionality that is currently
> part of BOSS regarding migration of class format. I expect you used
> things like representBinaryOn: and binaryReaderBlockForVersion:format:?
> In what way did that not do what you needed?
Well,

generally speaking, the BOSS mechanism of ensuring backward compatibility
is what is wrong with BOSS (from my perspective). So as long as you don't
need to ensure backward compatibility of your structure, you are OK with
BOSS. But when you do, think twice before using it. And now the isssues...

Each time you add/remove/rename instance variable, move it up or down in
inheritance hierarchy, rename class, you have to change reading from BOSS
of this class and *all* its subclasses, because their BOSS structure
changed as well. To do this, you can override method:
   * binaryReaderBlockForVersion:format:
where you can play with slots of anArray not all of which are initialized
at the time the block is evaluated. This array will later become your domain
object. Suppose you already have two versions and now you are about to deal
with the new one. Now you have the following conversions:
   * 1 -> 2.
And you have to make these:
   * 1 -> 3,
   * 2 -> 3.
I hope you get the idea...

Furthemore, these conversions generally can not do any calculations or use
any methods of future domain object, because you have to be able to deal with
anArray containing nil slots.

So in order to perform these calculations you still need to implement some
kind of #recoverAfterLoad on your domain structure...

And finally, when you deal with problems in BOSS, you can not simply edit
the corrupted BOSS file because of its binary nature.

We solved all these issues by moving from BOSS to our own XML-based serialization
framework that takes care of reading values of particular type (boolean, string,
number, ...) and it also supports forward references. The big win is that we have
separated serialization of domain object to its XML mirror object. The XML mirror
object implements behavior necessary for generating XML and for reading it back.
You can also check whether a reference points to something that it can point
to and so on. All this during the read phase from XML. The XML objects can also
support multiple versions and are able to migrate themselves from actual version
to the next one. And finally, the resulting XML is quite readable so you can
tweak some problems by hand...

Basic scheme of serialization/deserialization of domain structure using our
framework is:

[Writing]
Domain structure -> XML structure in the latest version -> XML stream

[Reading]
XML stream -> XML structure -> XML structure in the latest version -> Domain structure

Ladislav Lenart

I think the main problem here is the popper use of tools.  If one has a
hammer very soon everything start looking as a nail.  Another analogy -
you can use a microscope to hammer a nail to the wall, but I doubt if
you can use  a hammer to see very small objects :-)


The BOSS is best to use to store complex object structures. But then one
can use other means of serializations of your objects structures like
XML, #storeOn: , etc

The Omnibase however is an object database which allows you to store and
then search your objects without necessarily  bringing them all into the
memory.

If your intended use is one off fileout /filein - then the BOSS is your
  tool, but if you have dataset big enough and you do any amount of
searches then you should look at Omnibase, Gemstone or whatever other
DBMS is available.



jim wrote:

At 05:15 PM 10/23/2006, Ladislav Lenart wrote:
>we ran into problems with BOSS when we wanted to use it as a persistent
>storage for our domain objects. The problems arose when we modified classes
>of our objects (made a new version of the format) and still wanted the old
>ones to load and function properly...

FWIW, OmniBase figures out if the number or position of instance variables
changes and maps them into place appropriately.

M

Unless you want support, reliability, and scalability, and then you should look elsewhere.