This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Down and Dirty - the Store BOF
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Monday, noon - a bunch of us gathered for a Store BOF while the rest of the conference enjoys lunch. Goo set of questions, comments, and conversations. Let's see what I can jot down:
Issues (Terry Raymond/SOOPS) - Automated Builds, Merging, need lineups
Moving Classes between packages - sometimes confuses Store?
Renaming clases after a move (above) - ditto
Change Event for add/remove instance variables
Overrides within Bundles - we deferred this, but it's a huge point of contention
Specifying pre-reqs - very ugly. Have to type in the names
Difference loading is much slower than loading clean? I'm (personally) not sure on that, but many people concurred. It's a large problem over high latency links
preload/postload (etc) blocks - should be methods, not just strings.
Clean up the UI silliness - menus that differ between tools, tools that don't make a lot of sense, etc.
Unchanged methods should not cause add/remove doits to show up.
Replicator: To do - get the Store replicator into the base. If you use the replicator, push from the slowest (network) to the fastest system. It would be nice to be able to preserve user names across a replication
Merge tool: Alan - "The merge tool stinks". Trying to do more than a 2 way merge is a bad idea.
Niall would like to see some success/failure stories for Store usage, so he can see what development patterns work and don't work.
Keywords would be a nice thing for searches
Diana Merry-Shapiro has a nice method history tool that can show the sources of all methods - i.e., where they come from, etc (which Store DB, the change file, which parcel, etc.)
Schema of the DB - Optimizing the db is in process during this release. we would prefer not to break backwards compatibility. Bruce Badger suggests doing a whole new tool?
Martin McClure (Gemstone) - would like to see an object model so that Gemstone could be a back end. Terry agrees, and would like to see a fuill ST server on the far end, not just a db. A server back end could improve high latency connections. Policies could be server based (easier to share). Could make change notification easier (note that we have RSS). Extends benefits of no client db libs to non-Postgres users.
Properties should be stored binary (BOSS)
DB specific optimizations should be more accessible, even if they are not integrated by Cincom Engineering. Issue - they need testing and verification before we bless them
Package Comments are not easily visible past the specific version in which they were published. This makes large repositories (like the public store) hard to view and use.
Doc for newbies? There's Alan's presentation from StS 2002. There's the Store docs. Cincom Wiki Store notes.
Cees de Groot published a lineup tool for Store in the public Store. TOIStoreExtensions
Travis comments that new information on Store (as opposed to, say, Pollock) is not forthcoming. Can we get more and better information out?
Automating Builds - everyone builds their own - we should provide something. Headless, scriptable Store? Very hard now. The Store connection dialog should not come up on start, ever.
Bundles - One should be able to delete bundles as easily as packages
Ease of Use for neophytes - the base development image should be easier to get going with Store. Get the base Store image to have the read-only connection to the public store pre-set
Previous Topic
