Using Binary Packages Like Java Jars?

Hi folks,
Well, with the help of this community over the last year, I made the
transition from the C++ and Java world to Smalltalk (and hopefully
won't have to look back anytime soon!)

I'm currently thinking about refining my application, and would like
to "componentize" things more. Is there a way, using Dolphin, to
deliver incremental chunks of an application, much like I would do
using Java Jar files?
I'm thinking maybe using binary packages might be the way to go, but
am looking for feedback from any of you who have actually done this.
Currently, the app is a ToGo application, and I'd like to keep it that
way, so I guess I'd like to load pieces of the application from binary
packages at startup time (like VW parcels???), thereby allowing me to
also do incremental upgrades in the future.

Is this making any kind of sense, or am I looking at binary packages
the wrong way? And, if I'm correct, is it _really_ that simple (Jars
are pretty easy to work with), or am I missing some significant
"gotcha" here?

As usual, thanks for the assistance,

KeithB

Keith,

> Well, with the help of this community over the last year, I made the
> transition from the C++ and Java world to Smalltalk (and hopefully
> won't have to look back anytime soon!)

Welcome aboard!


> I'm currently thinking about refining my application, and would like
> to "componentize" things more. Is there a way, using Dolphin, to
> deliver incremental chunks of an application, much like I would do
> using Java Jar files?

Two thoughts: (1) IMHO, componentizing sounds good but causes trouble that
you can avoid (see below); (2) the last I recall reading, OA was not willing
to commit to support binary packages in future versions of Dolphin.  I would
like to see a viable web deployment kit, but would understand if, given
Microsoft's actions, OA discontinues it.  Hopefully, they will see binary
packages as a separate technology, and keep them around.  However, you
should look for that committment before betting the farm on binary packages.

With that said, let me try to talk you out of componentizing your software.
My experience is that you would be much better off spending your time
writing unit tests, automating your builds, and getting familiar with
InnoSetup, such that you can confidently deploy new executables when need
arises.  InnoSetup, driven from Dolphin, should be able to create very
reliable installers with good compression.  Dolphin builds very compact
executables: remember that a small Smalltalk program is "big" (if you
consider 1 MB +/- to be big), but a much larger Smalltalk program (in terms
of function points) is not much larger on disk and in memory.


> I'm thinking maybe using binary packages might be the way to go, but
> am looking for feedback from any of you who have actually done this.

I considered using binary packages as you describe, but soon realized that
components have boundaries, and the boundaries are a _real_ pain.  Further,
my programs simply were not that large, and while my feature counts have
soared, the executables are no bigger (often smaller) thanks to improvements
in Dolphin's stripping.

I looked briefly at web deployment, but was concerned about the (at the time
at least) inability to bind to a particular version of the VM.  Being forced
to find another way, I lost my remaining interest in binary packages.


> Currently, the app is a ToGo application, and I'd like to keep it that
> way, so I guess I'd like to load pieces of the application from binary
> packages at startup time (like VW parcels???), thereby allowing me to
> also do incremental upgrades in the future.

It would, but I _really_ suspect you will make much more work for yourself
than is necessary, and you and your users would be better off if you put the
extra effort into: writing tests, automating builds, and automating and
idiot-proofing your setup building and distribution.  InnoSetup can be a
huge help with the latter.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"ksbag" <[hidden email]> wrote in message
news:[hidden email]...
... ...

I would tend to agree with Bill here, using binary packages may introduce
more complexity without adding a lot of value.  Making sure different
versions of different packages work together could be added work.  I like
knowing that I can test the same image my users will be running.  If file
size is really important (often it isn't) then you might consider not using
a ToGo EXE.  That way you could deploy an initial setup program with the
required DLLs, and then just include a smaller non-ToGo EXE in upgrades.
The GUIToGo stub looks like it adds about 200k to the non-ToGo stub, so you
might save 200k on each upgrade.

If your interest in binary packages is from a debugging perspective then you
might consider providing a way to load a block from an STB file.  I
currently have a way I can send users a debug script that they can run in
the deployed application.  It has been very handy for scripting simple
things.

Chris

Bill and Chris, thanks for your feedback.
I agree that InnoSetup is a great way of packaging an installation,
and currently use it for my application. Additionally, I agree that
Dolphin's size for applications with a lot of functionality is very
reasonable; currently my app size is about 1mb or so, and as you
indicated, it doesn't change a whole lot as I add features.

The one thing I didn't mention in my original post is one of the
"futures" I'm thinking about. I'd like to be able to offer different
"optional" plug-in features, sort of like OA did early on with their
different kits for DB, Web development, Sockets, and such. So, a user
would be able to start using the "base" system, then simply add
feature X by getting the appropriate binary package from me (which the
application would check for at startup, and load if appropriate). So
while I've managed the upgrade issue via a combination of InnoSetup
and winzip, I'd really like to support a different style for this type
of incremental delivery.
One other thought: for other reasons, my users have the compiler in
their deployment. Would I be better off sending the incremental source
code, and filing-in, then compiling on the fly? Would that mitigate
any of the problems the two of you mentioned in your posts?

Bill, you mentioned that OA hadn't committed to binary packages in the
future, but IIRC, I thought I saw a post indicating binary packages
would definitely be in D6. Of course, I could be wrong.

Last general question: is this idea of componentization just a foreign
thing to Dolphin, and if so, why? Although I'm new to Smalltalk
development, I've lurked the newslists for a number of years (living
vicariously through you folks who were having the REAL fun :-). I seem
to recall VW parcels, VA image components and VSE (with SLL) all doing
something like this. So I don't think it's something foreign to the
Smalltalk community, right? Although binary packages may not have been
originally intended for such usage, it seems like a little  continuing
commitment by OA is all that's needed to fit the bill? Forgive me if
my ignorance is over-simplifying the situation, but I guess I'm just
wondering "why not"?

Thanks again for the help....

KeithB
"Christopher J. Demers" <[hidden email]> wrote in message news:<c4vcqu$2mji77$[hidden email]>...
> "ksbag" <[hidden email]> wrote in message
> news:[hidden email]...
> ...

ksbag wrote:

> Hi folks,
> Well, with the help of this community over the last year, I made the
> transition from the C++ and Java world to Smalltalk (and hopefully
> won't have to look back anytime soon!)

Hi Keith,

        you might want to look at VisualWorks Smalltalk's parcel system.  This
is binary, fully-supported and much more powerful than Java Jar files.
It supports three features not found anywhere else

1. overrides; the ability to redefine a method and/or class on parcel
load and have that redefinition revert to the previous definition on unload.

2. partial loading; the ability to defer loading class extensions,
either methods or subclasses, that can't be loaded because the classes
so extended are not yet present in the system, until subsequent parcel
loads bring those classes into the system.

3. reload; the ability to reload a new version of a parcel, updating the
current system to match the contents of the new version.

These facilities make packaging and deploying extremely easy.
There's more info in the online doc.

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Keith,

How about incremental activation?  Give them the code, but absent an
decryption key or other secret, the individual pieces won't run.  You could
send the customer an encrypted and binary filed policy object that tells the
program what to allow to run.

DolphinSure might provide what you need.  Failing that, or if you simply
want to roll your own, OpenSSL has some tools that I can probably help you
use.  Eventually, I hope to release a fairly complete wrapper for OpenSSL.
For now, I am limited (for various reasons) to handing out individual
classes and methods, as well as advice.  Post here if you decide to dive in,
and I'll help where I can.


> One other thought: for other reasons, my users have the compiler in
> their deployment. Would I be better off sending the incremental source
> code, and filing-in, then compiling on the fly? Would that mitigate
> any of the problems the two of you mentioned in your posts?

Theoretically, that should work, but test it.  I tried that a while ago and
could not get it to work because much of the development system was gone
from the deployed executables.  IIRC, I was trying to add classes and
methods, and it's not been since D3 (or earlier!!) that I tried it.


> Bill, you mentioned that OA hadn't committed

The last time I tried to pin them down, I was unable to get a response,
hence my caution to you.


> to binary packages in the
> future, but IIRC, I thought I saw a post indicating binary packages
> would definitely be in D6. Of course, I could be wrong.

I see no reason for them not to continue support for them.  Web deployment
is another matter, but binary packages have independent uses.  It is very
possible that they have since committed to supporting them in D6 and beyond.
Blair?


> Last general question: is this idea of componentization just a foreign
> thing to Dolphin, and if so, why?

I don't see it that way, but I do think it is largely unnecessary, and (I'm
quite confident here) more trouble than its worth.  Working in
VB/C/C++/Java/Java flat minor (oops, I meant C#<g>) requires small armies to
get anything done, and boundaries are everywhere, so adding a few more is
not a big deal (well it is, but they don't get noticed).  Smalltalk allows
you to move beyond those constraints; componentizing takes away a lot of
that freedom.


> Although I'm new to Smalltalk
> development, I've lurked the newslists for a number of years (living
> vicariously through you folks who were having the REAL fun :-).

Humor aside, don't underestimate the way that eats at (overly) cautious
business types - we _do_ have fun, and they sometimes see us as
undisciplined.  Add to that one of their trusted static language jocks
telling them that all of those untyped variables are going to cause the sky
to fall, and we get a bad name.


> I seem
> to recall VW parcels, VA image components and VSE (with SLL) all doing
> something like this. So I don't think it's something foreign to the
> Smalltalk community, right?

Not at all.


> Although binary packages may not have been
> originally intended for such usage, it seems like a little  continuing
> commitment by OA is all that's needed to fit the bill?

True.  I hope they will continue to support them, and they would work for
you.


> Forgive me if
> my ignorance is over-simplifying the situation, but I guess I'm just
> wondering "why not"?

The best reason I can think of is that it is more trouble than it's worth.
Your energies would be much better spent getting very good at
testing/deploying/distributing a monolith with activation policies taking
care of your incremental sales.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"ksbag" <[hidden email]> wrote in message
news:[hidden email]...
> The one thing I didn't mention in my original post is one of the
> "futures" I'm thinking about. I'd like to be able to offer different
> "optional" plug-in features, sort of like OA did early on with their
> different kits for DB, Web development, Sockets, and such. So, a user
> would be able to start using the "base" system, then simply add
> feature X by getting the appropriate binary package from me (which the
...

I currently support add-ons for my program.  There are two ways I do this.
Currently there is only one EXE, and it includes all the code for all
add-ons.  If someone wants to use an add-on feature then they need to be
using a version of the program that supports it.  Ideally one wants one's
users to be using the latest version anyway for support purposes, so this is
not a problem.

The first way I support add-ons is via a dynamically generated menu.  I load
menu items from the registry.  The registry entry contains the command text
and the symbol of the message that launches it.  This method must be marked
as "must not strip".  I could deploy the program in a special setup program
that includes the required registry entries to activate the add-on.  One
might use #include in InnoSetup to wrap an existing script in a script that
adds the new add-on tool registry entries.  Additionally one could create an
InnoSetup script that just adds the registry entries but contains no files.
This setup file could be used to activate the add-on tool for existing
users.  I tend to use this approach with experimental features, and also as
a way of hooking into development functionality for me.  For example one of
my add-ons opens an inspector on my model.

The second approach can work in conjunction with the first way, or on its
own.  Our program uses a license file for copy protection and expiration.  I
coded this myself using DolphinSureCrypt.  I have a field for options.  By
including certain strings I can make the program license support different
enhanced features.

> Bill, you mentioned that OA hadn't committed to binary packages in the
> future, but IIRC, I thought I saw a post indicating binary packages
> would definitely be in D6. Of course, I could be wrong.

For some reason I had the same feeling regarding the uncertainty of future
Binary Package support as Bill, but Andy said, "It is likely that the binary
package mechanism will remain in D6." here
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3eba26da%241%40news.totallyobjects.com .
Maybe Bill and I both misread that sentence, or maybe there was a another
post with differing comments.  I will leave this for others to clarify.

No, componentization in Smalltalk has been around for a while.  I had to use
it (the details are foggy) in VSE.  Your mention of SLL almost triggered
flashbacks of bad memories for me. ;)  It was getting close to a deployment
date and I was trying to create a deployable version of our application.
There were a lot of little SLLs and DLLs I was supposed to include.  But
there were also some development files I was not allowed to include.
Additionally I think I was only supposed to include files my program
actually used.  Their documentation was buggy and had some typos and given
that the file names were not exactly friendly (8.3 style names with names
that tried to convey a lot of information via letters and numbers) it was
unpleasant to deal with.  An additional complication was that we had applied
a patch, and that required some different versions of SLLs with different
names, and editing some kind of binding config file.  That experience almost
drove me crazy.  I ended up doing a lot of trial and error, and eventually
resorting to a file reference monitor utility to try to figure just what
files it thought it needed.  I don't remember the details any more (thank
goodness!), but I think that VSE added to the image via SLLs rather than
stripping it down like Dolphin does.  I also remember some stress involved
in assembling an IBM VAST deployment.  Once again I had to deal with a lot
of files, it was worse though because I also had stripping problems (it took
more than half an hour to strip, that was a long night).  That was when I
moved to Dolphin.  It was actually faster for me to port from VAST to
Dolphin (only took a few hours) than it was for me to get VAST to deploy.
At the time the application was 99% classes and 1% GUI and only proprietary
flat file databases so that made it easy to port.  I haven't looked back
since.  Sorry for the tangent, but yes, what you describe is not unusual to
do in Smalltalk.  I never felt I had a need to do it in Dolphin Smalltalk.
I have often thought that some of the other Smalltalk's are more complex.
They can tout a lot of buzz words that might impress IT VPs.  For the kind
of development I do now I find that I don't need most of the features other
Smalltalks include.  I used to think of VAST and VW like 747 jets, big,
powerful, and complex; I thought of Dolphin Smalltalk more like a private
jet, or these days maybe even more like a jet fighter. ;)  I think the
design philosophy of Dolphin tends to avoid unnecessary complexity.  I think
other Smalltalks have a greater tolerance for complexity.  There are
different tools for different jobs.  I think that currently Dolphin
Smalltalk is easily the best Smalltalk for Windows PC workstation based
applications.

Certainly you are not going to create a bazillion binary packages, so you
probably won't make as many problems for yourself as I mention above.
However I suppose it does demonstrate the added complexity of using
components.  If your components are very clearly defined and not likely to
need to be refactored across different packages then components may work
fine for you.  If you do use components we would love to hear about how it
works out after you have some experience with them.

Chris

Chris,

> > Bill, you mentioned that OA hadn't committed to binary packages in the
> > future, but IIRC, I thought I saw a post indicating binary packages
> > would definitely be in D6. Of course, I could be wrong.
>
> For some reason I had the same feeling regarding the uncertainty of future
> Binary Package support as Bill, but Andy said, "It is likely that the
binary
> package mechanism will remain in D6." here
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3eba26da%24
1%40news.totallyobjects.com .
> Maybe Bill and I both misread that sentence, or maybe there was a another
> post with differing comments.  I will leave this for others to clarify.

With appologies to Andy, and noting that perhaps I simply spend too much
time listening to what US politicians say and subsequently watching what
they do, "it is likely..." and "we are determined to continue support
for..." are very different statements.  Before making a design decision that
depends on binary packages, I would want to see the latter form.

To Andy's credit, he was probably trying to avoid making a statement that
might turn out to be untrue for reasons beyond his control.  However, I
suspect that binary packages are the last thing that an outside entity could
take away against OA's wishes.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hmmm - I use a base image and binary packages (parcels) to distribute
BottomFeeder (http://www.cincomsmalltalk.com/BottomFeeder).  Now
admittedly, that's VW, and I don't know Dolphin's package system.
Having said that, so long as you can attach version information to a
Dolphin package, you should be able to track information quite nicely
- I can tell what version of Bf an end user has via the Help>>About
dialog, which lists all the packages and their versions.  I would
think doing the same thing in Dolphin would be only slightly different


On Tue, 6 Apr 2004 18:58:46 -0400, "Christopher J. Demers"
<[hidden email]> wrote:

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Jim,

> Hmmm - I use a base image and binary packages (parcels) to distribute
> BottomFeeder (http://www.cincomsmalltalk.com/BottomFeeder).  Now
> admittedly, that's VW, and I don't know Dolphin's package system.
> Having said that, so long as you can attach version information to a
> Dolphin package, you should be able to track information quite nicely
> - I can tell what version of Bf an end user has via the Help>>About
> dialog, which lists all the packages and their versions.  I would
> think doing the same thing in Dolphin would be only slightly different

Agreed, but Chris and I are asking what you actually gain for your trouble.
My experience (and associated fond memories and regrets) suggests that the
real trick is be able to confidently and reliably build and deploy
monolithic executables.  Arrange to sleep well with that approach, and the
rest starts to look like wasted effort, at least IMHO.  At a minimum, I
suspect that most people wanting to componentize want to do so because it is
familar to them, not because it ever did anything for them - kinda like
using statically typed languages :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

<snip>

Well, I started with a monolithic image, and went in this direction
purposely.  Why?  

-- Addressing bugs.  If I shipped a monolithic image, addressing a bug
meant shipping a new image and hoping that all end users would get it

I first added a patch tool, taking advantage of the fact that VW
parcels can override existing code in the image.  The problem was in
keeping track of patches - it's very hard, and, IMHO, error prone

I changed that to a base image with parcels (pre-loaded).  Again,
taking advantage of the override capability, I now ship patches as new
versions of individual components.  The application can check for and
download those - which makes it easy for me to ask "are you up to
date"

Personally, I've found it a lot easier to track what people are using
this way, and easier to update than with a monolith.

>Have a good one,
>
>Bill

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Thanks to all who replied to my postings. You've made a lot of good
points, and cleared up many of my questions.....

<Chris said...>
> The second approach can work in conjunction with the first way, or on its
> own.  Our program uses a license file for copy protection and expiration.  I
> coded this myself using DolphinSureCrypt.  I have a field for options.  By
> including certain strings I can make the program license support different
> enhanced features.

Based on your discussion, and the ideas Bill put forth, I think I'll
try the "monolithic app with activation" route. That approach really
does seem to simplify distribution, and overall maintenance by not
having to keep track of multiple binary package versions, etc. Plus,
it doesn't preclude the use of "logical components" for a separation
of concerns, even though I'll deploy physically as one big app.


>
> No, componentization in Smalltalk has been around for a while.  I had to use
> it (the details are foggy) in VSE.  Your mention of SLL almost triggered
> flashbacks of bad memories for me. ;)  <snip>

Hope the discussion doesn't end up sending you to therapy (I noticed a
bit of a twitch as you typed your response) :-)
Seriously, I guess it's like Bill alluded to: Marketing Smalltalk
components to VP types is one matter; actually using them is a whole
'nother set of difficulties. I think if I was working in a team
environment, it would make more sense to persue the component route
(through binary packages). But, given it's just me (and given the fact
that there's no *explicit* supporting mechanism [and process] in
Dolphin expressly designed to facilitate physical componentization),
I'll go with the monolithic app.

Finally, thanks again to everyone who contributes on this group. Andy,
Blair, Ian, Bill, Chris U, Chris D, and everyone else (this is not an
Oscar presentation, so I'll cut it short there - no offence to anyone
not explicitly mentioned...). I've learned SO much, just by popping my
head in here now and then; hopefully, I'll build a similar level of
expertise where I can also contribute (usefully) rather than just
sucking information from you all. Regardless, thank you all again -
your contributions are GREATLY appreciated.
This group definitely rocks!

KeithB

Keith,


Sorry for the delay in replying but I've been busy on other things over
the last few days.  In short, I think that BinaryPackages maybe exactly
what you need if you wish to do binary distribution of Dolphin classes,
either for application partitioning or for automatic update.

There has been some confusion over whether BinaryPackages will continue
to be supported in Dolphin in version 6 and beyond.  I think this is
because of our announcement some time ago to discontinue support for
Web Applets. In fact, we fully intend to carry on supporting
BinaryPackages even though the applet mechanism for which they were
originally designed is being phased out.

So, in answer to your question, I would say that if you can get binary
packages to do what you want then, by all means, go-ahead and use them.
You may wish to "roll your own" solution of course but first of all,
take a look at the "Smalltalk WebStart" thread that I'm just about to
post to the newsgroup.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Component support is a must for enterprise level development.   At the
same time Dolphin is not marketed for Enterprise development...


On Wed, 7 Apr 2004 19:27:02 -0500, "Bill Schwab"
<[hidden email]> wrote:

Sergei,

> Component support is a must for enterprise level development.   At the
> same time Dolphin is not marketed for Enterprise development...

Please define "Enterprise development".

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> Please define "Enterprise development".

Overpriced.

Or, if you prefer to get into the nitty-gritty of detailed definitions:

*Way* overpriced.

    -- chris

I don't really want to start some flame here with my comment on
Enterprise Development.  Enterprise Development for me is when:
- Many developers are involved on several interconnected products.
- Many separate components are written.  Components have independent
lifecycle.

I just thought that companies like to know that they can purchase a
component for the development purposes.  Companies don't want to
update an entire image of the product.  They like to isolate an update
to one file.  It is because each file has its dependency graph and
this dependency graph defines the scope of the regression testing and
so on.

At the same time:

I found a lot of truth in the words that multiple components with many
versions create a very difficult problem of figuring out which
combination is guaranteed to work.  We use C# and as you know C#
promises a lot in the versioning land.  I find that in the end the
safest way for us is to deploy one set of assemblies and not to try to
support lots of versions.

I don't have my mind set on a particular solution, but many people
will not be that easy to convince to use monolithic image or one set
of dlls.

On Sun, 11 Apr 2004 12:30:54 -0400, "Bill Schwab"
<[hidden email]> wrote:

Sergei,

> I don't really want to start some flame here with my comment on
> Enterprise Development.

Fair enough, but it's a buzzword of glossy ad fame, and as such requires a
definition, if only for the current conversation.


> Enterprise Development for me is when:
> - Many developers are involved on several interconnected products.
> - Many separate components are written.  Components have independent
> lifecycle.

This is analogous to the static vs. dynamic linking concerns of "the dark
ages" (when Java was a beverage, etc.<g>).  Things are simpler, and
therefore more robust, in the static case.  Dynamic linking can save space,
but only with large components with high fanout.  I suspect that the
benefits are seldom realized, and risks are always with us.



> I just thought that companies like to know that they can purchase a
> component for the development purposes.  Companies don't want to
> update an entire image of the product.  They like to isolate an update
> to one file.

The component iself, or one source file?  Your average C* programmer will
read the latter, and a big part of Smalltalk's power comes from transcending
that limitation.


> It is because each file has its dependency graph and
> this dependency graph defines the scope of the regression testing and
> so on.

Which is much simpler with a monolith, right?  That way, there is no


> At the same time:
>
> I found a lot of truth in the words that multiple components with many
> versions create a very difficult problem of figuring out which
> combination is guaranteed to work.  We use C# and as you know C#
> promises a lot in the versioning land.  I find that in the end the
> safest way for us is to deploy one set of assemblies and not to try to
> support lots of versions.

Applying C* design and deployment strategies to Smalltalk is likely to
dilute Smalltalk's advantages.


> I don't have my mind set on a particular solution, but many people
> will not be that easy to convince to use monolithic image or one set
> of dlls.

That might be, but I can almost guarantee you that most people asking for
components don't need them, and would be better off without them.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message news:<[hidden email]>...
> Sergei wrote:
> > I don't have my mind set on a particular solution, but many people
> > will not be that easy to convince to use monolithic image or one set
> > of dlls.
>
> That might be, but I can almost guarantee you that most people asking for
> components don't need them, and would be better off without them.
>
Components and CBD address more than just deployment; it is a
development approach that (at least in theory) allows for a higher
level of abstraction, modularity, and "pluggable parts". While I agree
many smaller developers may not need components, many larger-scale
development efforts can certainly benefit. For instance, certain
multi-year DoD projects (like Anti-ballistic missle systems) being
performed by multiple vendors, using parallel development can
definitely benefit from a component-based approach. Now, I'm no where
near a Smalltalk expert, so maybe some of this doesn't apply to
image-based environments (I don't know why it wouldn't be though - CBD
is fundamentally langauge independent, and there have been Smalltalk
"componentization" techniques like parcels and ICs). Additionally, I
remember working with a mid-sized telecom company in Ohio that adopted
CBD because it helped them manage "families" of billing components
that gave them a competitive advantage.
Mind you, I'm a bit biased having been raised on the Catalysis
approach by Desmond D'Souza, but I've actually seen a number of
mid-sized and larger companies who could benefit and *would* be better
off with them. One big problem is that components are like a car;
there are other things that must be considered besides just the "car"
- insurance, maintenance, gasoline, registration, etc. Likewise,
there's the deployment and versioning problems of components you
mention, but also certification, packaging, management, harvesting,
and a host of other things that must be addressed. Again, I wouldn't
recommend the approach for everybody, but many larger organizations
would probably find a favorable cost/benefit ratio if they did the
research.

KeithB

Keith,

> > Sergei wrote:
> > > I don't have my mind set on a particular solution, but many people
> > > will not be that easy to convince to use monolithic image or one set
> > > of dlls.
> >
> > That might be, but I can almost guarantee you that most people asking
for
> > components don't need them, and would be better off without them.
> >
> Components and CBD address more than just deployment;

Agreed - and I never intended to suggest otherwise.


>  it is a
> development approach that (at least in theory) allows for a higher
> level of abstraction, modularity, and "pluggable parts".

Not to mention interfaces that don't get changed because it's too much
trouble, hence we end up living with poor quality and/or performance.  Even
at their best, the unavoidable boundaries that come with components are an
impediment to change.


>  While I agree
> many smaller developers may not need components,

I would argue almost all.


> many larger-scale
> development efforts can certainly benefit.

*If* they have either the vision and luck to get the interfaces right from
the beginning, or the will and funding to change them several times during
the project.


> For instance, certain
> multi-year DoD projects (like Anti-ballistic missle systems) being
> performed by multiple vendors, using parallel development can
> definitely benefit from a component-based approach.

As they would from static linking, and sharing source code.


> Now, I'm no where
> near a Smalltalk expert, so maybe some of this doesn't apply to
> image-based environments (I don't know why it wouldn't be though - CBD
> is fundamentally langauge independent, and there have been Smalltalk
> "componentization" techniques like parcels and ICs).

It is quite applicable.  However, there is very little magic associated with
connecting to a binary component, vs. compiling source code into a single
binary.  That's as true in static languages as it is in Smalltalk.


> Additionally, I
> remember working with a mid-sized telecom company in Ohio that adopted
> CBD because it helped them manage "families" of billing components
> that gave them a competitive advantage.

And they could do the same things with shared source code.  Their binaries
would be a little larger, and their code would probably be better because
they could stop worrying about which pre-existing apps any given change
would break, and focus on making the next build better/smaller/faster.

There is clear advantage in GDI etc. being dynamically linked, but I doubt
that too many vendors come close to the level of reuse needed to similarly
benefit end users.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]