[vwnc] Any interest in a server-focussed reboot of VW?

My commercial interest in using VW is as a development environment for  
server applications. I do GUI development purely to enhance the  
environment itself, not to ship. I am also interested in improving VW  
to increase it's appeal to other developers. These two interests have  
lead me to develop solutions, (some not to completion), that address a  
number of weaknesses (IMO) in VisualWorks. Specifically GCCXML/LLVM/
Clang (DLLCC/C integration), ASBAqua/ASBLook (OSX L&F), LinkuisticsUI  
(GUI support) and MirrorImage (version control etc).

I would like to enlist more resources in this mission because I don't  
think these issues are being addressed aggressively enough by Cincom.  
The non-technical issues that impede Cincom's ability to implement  
significant change include resource allocation, strategic imperative,  
and an understandable requirement to service and protect their  
existing revenue stream. I'm not being critical of the Cincom  
Smalltalk team. They have significant practical constraints, and I can  
only guess at the way in which the parent company views the Smalltalk  
product in a strategic sense.

Personally I think Cincom should fork/reboot VW into a server-only  
stream, because virtually all of the legacy issues are to do with the  
L&F and UI toolkit, and partly Store. WebVelocity uses this approach,  
and it's no coincidence that it doesn't use the VW UI, but I think a  
less radically partitioned product, not targeted specifically to  
Seaside, would be a potent thing.

Considering this mailing list, I can see that there is both a  
significant conservatism and no clear consensus on what change is both  
required and acceptable. I suspect the VW community is both smaller  
and has little of the energy/time/motivation/tools that characterize  
e.g. the Ruby community. It doesn't help that using VW isn't free,  
which is merely a fact of life.

Having said that however, I wonder if anyone else has both the  
interest and time to invest in mutating VW to produce a version that  
ignores the GUI and Store legacies? I'm slowly doing that but as a  
part-time effort it takes a long time, and just as importantly,  
working alone, whilst good for pursuing a vision, is intellectually  
impoverishing.

I was a guest on the Industry Misinterpretations podcast recently, and  
Michael suggested setting up a website for my 'NeuvoVW'. I said at the  
time that I didn't think there was any community for what I was doing.  
I guess I should find out, rather than supposing.

Any takers?

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Lack of will power has caused more failure than lack of intelligence  
or ability.
  -- Flower A. Newhouse

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 26/07/2008, at 12:39 PM, Antony Blakey wrote:

> I was a guest on the Industry Misinterpretations podcast recently, and
> Michael suggested setting up a website for my 'NeuvoVW'.

NuevoVW of course. My fingers aren't trained for Spanish :)

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

All that is required for evil to triumph is that good men do nothing.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Sat, 26 Jul 2008 12:39:55 +0930
Antony Blakey <[hidden email]> wrote:

> Personally I think Cincom should fork/reboot VW into a server-only  
> stream, because virtually all of the legacy issues are to do with the  
> L&F and UI toolkit, and partly Store. WebVelocity uses this approach,  
> and it's no coincidence that it doesn't use the VW UI, but I think a  
> less radically partitioned product, not targeted specifically to  
> Seaside, would be a potent thing.

I understand that you'd like NuevoVW to be streamlined for providing
(headless) server applications. Besides focusing the target range of
products, what would you remove from or change in the current system
to achieve this goal?

> Considering this mailing list, I can see that there is both a  
> significant conservatism and no clear consensus on what change is both  
> required and acceptable. I suspect the VW community is both smaller  
> and has little of the energy/time/motivation/tools that characterize  
> e.g. the Ruby community. It doesn't help that using VW isn't free,  
> which is merely a fact of life.

That's part of the problem. Remember what happened to Widgetry.
Lots of efforts poured in, too few supporters, abandoned by external
constraints. How would NuevoVW deal with this situation? If VW were
free, forking would "only" entail the usual ugliness with double
maintenance, drawing resources from the "main" product and what not,
but since it is not, there are legal ramifications to consider, too.

> Having said that however, I wonder if anyone else has both the  
> interest and time to invest in mutating VW to produce a version that  
> ignores the GUI and Store legacies? I'm slowly doing that but as a  
> part-time effort it takes a long time, and just as importantly,  
> working alone, whilst good for pursuing a vision, is intellectually  
> impoverishing.

Interest, yes. Capability, maybe. Time, no. Family needs food and
growing kids are expensive :-)

> I was a guest on the Industry Misinterpretations podcast recently, and  
> Michael suggested setting up a website for my 'NeuvoVW'. I said at the  
> time that I didn't think there was any community for what I was doing.  
> I guess I should find out, rather than supposing.

Test-first before optimizing it away, good idea :-)

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 26/07/2008, at 5:53 PM, Steven Kelly wrote:

> How do you see your improvements as being beneficial to server  
> applications?

Because it is a lot easier to improve the toolset if you don't have to  
ensure that every change won't affect those users who use the GUI code  
for their app.

> Or maybe a better question is this: what kinds of server  
> applications are you thinking about?

Anything without a GUI. I'm thinking of Web apps, but that's just  
because I build them.

> And what kind of business model for NuevoVW?

None. It would be a) an enhanced VM and b) packages which you load  
into NC or licensed VW. Or maybe even a starter image. I'm not  
interested in making money, just allowing more radical surgery than  
Cincom can manage.

> I'd have thought people making server apps would want a big company  
> or very big community behind the platform.

Many people make server apps in Ruby, Python and Perl, all without a  
big vendor.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Don't anthropomorphize computers. They hate that.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 26/07/2008, at 6:43 PM, Stefan Schmiedl wrote:

> I understand that you'd like NuevoVW to be streamlined for providing
> (headless) server applications. Besides focusing the target range of
> products, what would you remove from or change in the current system
> to achieve this goal?

I'm probing for support for the impulse first. Subsequent discussion  
would need to occur.

Off the top of my head, and not orthogonal:

Change UI specs to be programatic, using a canvas.
Change layout to use GroupLayout rather than the current layout  
mechanism, to improve the layout of the interface.
Move 100% to Announcements.
Remove all L&Fs but ASBAqua/WinXP.
Lower the level of abstraction in the VM so that platform differences  
can be handling in the image, not the VM.
Fix OSX font handling.
Fix OSX command key handling.
Change the command invocation/menu system. I have something coming on  
that.
Add llvm/clang and inline C.
Incorporate MirrorImage - file based sources, DSL based  
metaprogramming, git/bazaar integration.
Use a micro-image + build-from-source model.
Remove Store, except for import/export to file based sources.
Redo the source editor.
Add an embedded Webkit interface for rich presentation of e.g.  
documentation and visualisation output.
Add a 'pivoting' browser interface based on a reification of the code  
model and a virtual-syntax structured editor.

The key thing is that we wouldn't have to worry about breaking  
anything because the full extent of the UI components of the system  
would be manifested as a product. I would anticipate having NO  
optional UI components e.g. everything is included so that it can be  
refactored/rebuilt and moved forward as a whole.

> That's part of the problem. Remember what happened to Widgetry.
> Lots of efforts poured in, too few supporters, abandoned by external
> constraints.

I'm doing some of this anyway, I just want to see if there's any  
collaborators. Unless there are other people who will contribute (as  
opposed to those who are interested but cannot contribute), then the  
overhead of being public isn't worth it.

> How would NuevoVW deal with this situation? If VW were
> free, forking would "only" entail the usual ugliness with double
> maintenance, drawing resources from the "main" product and what not,
> but since it is not, there are legal ramifications to consider, too.

If there is interest, I'll take it up with Cincom. The issues are:

1. VM code sharing, amongst VW licensees only.
2. Shipping a modified VM (without source).

Other changes aren't an issue given the NC exists.

Maybe Cincom won't allow this to happen. Let me see if there is any  
need to investigate first.

> Interest, yes. Capability, maybe. Time, no. Family needs food and
> growing kids are expensive :-)

Hell yeah, I know.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

It is no measure of health to be well adjusted to a profoundly sick  
society.
   -- Jiddu Krishnamurti


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 26.07.2008 um 11:50 schrieb Antony Blakey:

> I'm probing for support for the impulse first. Subsequent discussion
> would need to occur.

Recently I felt a similar desire to get rid of the "backwards  
compatibility chains" by forking a new breed of VW, however more  
focussed on desktop applications and fat clients, hence in the  
opposite direction ;-) The list of desired changes is as long as  
yours, and, as you might know, me too went to great lengths to solve  
issues on my own.

However, as the market for Smalltalk is a niche already, I wouldn't  
recommend to split it into even smaller parts by separating headless  
from headful product lines. One universal VW platform can easily serve  
both, provided the issues discussed here will be addressed. I would  
also guess that only a combined solution can justify the investment in  
maintenance, documentation and support.

IMO, the advent of multiple product mutations might have a negative  
effect on the general perception in that it can give the impression of  
them being a huge pile of extremely cool stuff that's just a bit half-
baken and not enough integrated and supported to bank a commercial  
business on it.

I would rather recommend to setup a roadmap based on surveys and  
careful use case analysis, and then collect and integrate the changes  
incrementally (and hire a designer and external critic). A full reboot  
of any kind would take many, many years. A couple of beautifications  
and modernizations are probably much easier and earlier to achieve.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 26/07/2008, at 10:30 PM, Andre Schnoor wrote:

> Recently I felt a similar desire to get rid of the "backwards  
> compatibility chains" by forking a new breed of VW, however more  
> focussed on desktop applications and fat clients, hence in the  
> opposite direction ;-) The list of desired changes is as long as  
> yours, and, as you might know, me too went to great lengths to solve  
> issues on my own.

Yes. I'd still like your Mac menubar code before I have to do it myself.

> I would rather recommend to setup a roadmap based on surveys and  
> careful use case analysis, and then collect and integrate the  
> changes incrementally (and hire a designer and external critic). A  
> full reboot of any kind would take many, many years.

On the basis of what I've done so far, I think 12 months of full time  
coding effort would have a very usable result, looking a lot cooler  
than the product currently does.

> A couple of beautifications and modernizations are probably much  
> easier and earlier to achieve.

This is predicated on the idea that significant changes to VW are  
remarkably difficult to make when you have to consider the existing  
users who build on/with the GUI side of the product.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The intuitive mind is a sacred gift and the rational mind is a  
faithful servant. We have created a society that honours the servant  
and has forgotten the gift.
   -- Albert Einstein


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I think that the work on a minimal VW image would help with making
both the server specific and client specific images described in this
thread.

The ideal minimal image would have just enough in it to load a parcel.
 From that one could create an image that only contained the things
needed for a particular task, be it server, client or development
environment.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I agree that the current look and feel is the products biggest handicap. And we can only hope that cincom got the message. However if they manage to insert cairo / pango underneeth every single widget and hire a designer to get at least one sexy and selling interface, we have a chance to become a frontrunner.

I don't understand all of your wordings but if you want to rebuild the UI you better start with Widgetry which was way easier to modify and understand then the so praised Wrapper or join the squeak gtk project who allready have a browser running under cairo.

http://blog.summer.squeak.org/2008/07/squeakgtk-omnibrowser.html

@+Maarten,

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

A couple of years ago I attempted just that. I created
a set of fileIns that would strip the image. I managed to
get down to around 2MB.

I think that in order to make progress you need to take
bite sized steps and reorganizing the image so it can
more easily made smaller should be the first step.

Unfortunately, I don't think Cincom is interested in this
so every release will mean reevaluating the repackaging,
not much fun.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27/07/2008, at 6:36 AM, Eliot Miranda wrote:

My idea for bootstrapping with MirrorImage was to follow the Lisp  
lead, and use an existing system to bootstrap a new image from source.  
This way you don't need to code a bootstrap loader in a minimal  
kernel, and all that's required is a sandboxing facility with an image-
writing facility. I want a build-from-nothing-via-sources  
implementation.

Is this what you mean by using the ImageTracer?

> - as far as external and primitive interfaces to OS, WIndow System,  
> etc al, the image and VM should contain on;y basic file primitives,  
> a primitive to load an object library and another to lookup symbols  
> in it, the C: interface and that's it.

When I was doing clang/llvm integration I considered implementing an  
FFI using nothing but dlopen/dlclose/dlsym/dlerror. Everything else  
can be built from that within the VM, which lowers the level of  
abstraction of the VM and moves platform abstraction into the image.  
This works really well for SWT (Eclipse).

OTOH, the link process in llvm gives me that and more, and clang gives  
me Objective-C (and eventually C++) integration.

> - work be done to analyse the current set of overrides in the  
> "standard" developer image and as many of these be replaced by  
> registration-style interfaces as possible.  Overrides are for  
> modifying an ossified system.  This new kernel should be more  
> pluggable and extensible.

Yes.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Plurality is not to be assumed without necessity
   -- William of Ockham (ca. 1285-1349)


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27/07/2008, at 4:23 PM, Eliot Miranda wrote:

> llvm also gives you duplication and a footprint hit.

Yes, but 2MB isn't an issue with server apps, and LLVM is more highly  
optimizing than the VW code generator.

With CLang, the option of inline C/Obj-C/C++ plus a better header  
parser. is interesting.

Particularly given that I've already done this with VW, so there's  
nothing to prove.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The ultimate measure of a man is not where he stands in moments of  
comfort and convenience, but where he stands at times of challenge and  
controversy.
   -- Martin Luther King


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc