(speaking solely for myself, not Cincom)

I don't think any sort of strict clean-rooming would be necessary. Even if 
it was impossible to get Cincom to open-source Store outright (and I don't 
think it's impossible, just slow and painful), I can't see that Cincom 
could claim ownership of the schema or would have any objection to 
interoperability.

The one concern I would have with open-sourcing Store at the moment is that 
there's not a really good domain/GUI/DB separation, so porting it to 
another dialect would almost certainly wind up forking most of the code. 
I'd almost prefer to wait until we could get some cleanup done.

I made a stab in the same general direction as a clean-room implementation 
with GLORP, by looking at the Store schema and trying to see what would be 
involved in reading/writing it from GLORP. There was only one really tricky 
bit, which is the, um, interesting way that long bits of source are stored 
(There's a code field, if it's value is 1, then the blob is a string, if 
it's 2 it's a double-byte string, and 3 and 4 also mean something. If it's 
a negative number, then that number *-1 is a foreign key to some more of 
the source). The objective was to be able to build a bridge, so that e.g. 
from a VisualAge image you could look at a Store repository and load in 
code that would appear as ENVY applications, and publish ENVY apps into the 
Store database. Ditto for Dolphin packages, Squeak modules, and so forth. I 
managed to get the basic source thing working, but since then I haven't had 
time to finish it off. (It's in the Cincom public Store repository under 
the name of GlorpStore, or I'd be happy to send anyone the code)

Finally, note that Cincom has officially dropped the silly mixed-case 
acronym, so the name is now just Store, not StORE.

At 06:26 PM 5/11/2002 -0700, Avi Bryant wrote:
>On 10 May 2002, Cees de Groot wrote:
>
> > I don't want to spoil your fun, but since I've started working with StORE
> > (on VisualWorks), I find the other stuff unbearable and I rather just
> > shift changesets around when working with Squeak. Maybe we should beg
> > Cincom for the StORE sources ;-)
>
>Ah, well, I agree that something like StORE is very nice; however, being
>able to integrate with the flat-file world is very useful.  I'll be doing
>some work soon with a company whose work flow is currently very based
>around CVS, and since I'm helping them migrate to Smalltalk, I thought I'd
>see if I could get reasonable integration between Squeak and CVS to ease
>the transition.
>
>As for StORE, even if we can't get it open-sourced, couldn't we cleanroom
>a system that used the same DB schema, so that Squeak and VW could share
>repositories?
>
>Avi

--
Alan Knight [|], Cincom Smalltalk Development
knight at acm.org
aknight at cincom.com
http://www.cincom.com/smalltalk