At 09:16 PM 8/22/00 -0400, Jay Love wrote:
>Chuck Esterbrook wrote:
> >
> > At 08:46 PM 8/21/00 -0400, Jay Love wrote:
> >
> > >My thoughts on this issue of how to handle multiple WebApps is to use a
> > >WebApp object. It would take the place of a Context and use a fair
> > >amount of Code from Application.
> > [snip]
> >
> > I can't say I buy it. The vision for the future division of
> > AppServer/Application/etc. is getting clearer and I'll probably go straight
> > for it. I'm pretty set on application=process (as opposed to "process has
> > multiple applications").
>
>I still think you should make a case for this. What is the difference
>from running multiple completely separate AppServers? It just seems
>confusing.
Actually, I wasn't verbose enough. Each process will have an app server
instance. Sorry.
*But* each process won't have 3 application instances like "News",
"StockPortal" and "WebMail". Different apps means different processes.
> > Also, it's weird to have an "Application" and a "WebApp". Why 2 app
> > classes? Why is one abbreviated? Why is one prefixed with "Web"? Why don't
> > we have WebSession, WebServlet, etc.?
>
>WebKit is an Application. A WebApp is something you want to publish on
>the Web. It is an interactive web based application. Our Application,
>my eyes, is part of the plumbing mechanism that we have constructed and
>call WebKit. WebKit can be used to serve up more than one WebApp at the
>same time.
Well if you really wanted distinct applications served off of the same
process, I suppose you could throw some classes and tweaks in there to do
it. But I don't see the case for distinct apps to run in the same process
and don't plan for this to be the out-of-the-box WebKit architecture.
I mean all of sudden if one app has a memory leak, seg fault, etc. they all
crash. That's like using DOS or a Macintosh.
> > Right now Application already has individual methods for doing things like
> > creating transactions, creating sessions, etc. By making it easy to
> > override this class, we will make it easy to customize all these behaviors.
>
>Web developers don't want to have to customize all this. I don't want
>to have to deploy it. If someone has installed Webware, I want them to
>be able to untar/zip a site I've created, add it to their config files
>and go. I don't want them to have to understand the mechanics of the
>Serving process. That's not what Web developers want. THey want to
>work on their side of the equation, generating content, and have the
>rest just work. I think. ;)
I agree. But I would add that there are always those cases where
customizing these things either makes life more interesting (you're doing
something you wouldn't have otherwise) or easier (you could do it the
"other" way but it would suck) or workable (you just fixed a nasty WebKit
bug with your own patch).
Having the mechanism/ability to easily subclass and customize these
operations in no way interferes with anything, including the learning
curve. You don't have to learn about these things to create an app. I have
three web sites in Webware and none of them currently subclass these key
classes or customize the dispatching of a request.
BUT when the day comes that I need customization (and it always comes),
it'll be easy.
WebKit is easy for newbies and has hooks for the pros. (At least I like to
think so.)
>I'm not saying that it shouldn't be possible to customize the rest, just
>that it shouldn't be the only OR default way.
Well there are only so many customizations you can provide for in a framework.
Currently we provide:
* General subclassing
* Config files
* Plug-ins
* Servlet factories
Heck, I was feeling pretty good. :-)
>It sounds to me like in your scenario, if a website has two main areas,
>a content/publishing area and a real-time discussion area, which both
>need some customization to Session or something else, they have to run
>two AppServers. But what if they need to share a bunch of stuff between
>the two sides of the site?
If their Session requirements were different and exclusive, then yes. But
then I think that's indicative of two separate apps. On the other hand, if
you're just storing some extra data with the session, no these wouldn't
have to be separate apps and if they share resources probably shouldn't.
I wasn't aware that in Java's web dev SDK, I could have two distinct kinds
of session classes used in different contexts. Is that possible? If so,
does it imply that I lose my session info from Context A when I enter
Context B? If so, then who cares? (But I really want to know the first
question.)
>I'm just after the real world vision, that's all. I am predisposed to
>my (Java Servlet centric) view. Help me see the light of your view.
Well there are my notes above.
Also, I've got 3 sites and counting which is part of where I get my "real
world" vision. (Well, actually I'll be expanding these sites, not
necessarily building out more.)
Also, WebObjects had most of this shit figured out before Java even had
something called a "Servlet" and overall the design is pretty clean. You
may wish to peruse it, since I am admittedly predisposed towards my
WebObjects-centric view. :-)
But ultimately, I want Webware to be the best it can be independent of Java
or WebObjects (while balancing reality, schedule, docs, etc.)
And the show goes on...
-Chuck
|