App stuff

[Terry Disz]

Regarding point number 2, I understand that join/leave is the venue
mechanism that gives applications the ability to maintain general state (as
in current slide number in a ppt app, or vector list in a shared drawing
program, etc) and a general mechanism to pass it on to users that join an
app in progress, much like "enter" gives venue state to a client entering a
venue. This seems a very good and useful thing to me, especially for the
general class of shared app where users need state when they join to get
current with everyone else.

Terry



> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov]On
> Behalf Of Ivan R. Judson
> Sent: Thursday, March 13, 2003 9:33 AM
> To: 'Robert Olson'
> Cc: 'AG Dev'
> Subject: App stuff
>
>
>
> Rather than block on this much longer since I think we want it soon; I'm
> sending yo u my issues to think about. Then you can respond perhaps with
> some proposed solution.  I can propose solutions too, however they're less
> likely to suit your taste than one you produce :-).
>
> First, simple thing: I think the Application Service wants to be an
> Application Factory. That's the pattern it implements. It's more clear to
> developers that way and it's not user exposed. It's to our advantage to
> leverage the clarity of common naming I think.
>
> Second, I'd like to minimize the design to keep things simple. The web
> service interface should only have 4 methods (and two of those I'd like to
> consider dropping) for join/leave (the two I don't think we
> _need_, although
> they are convenient), and get/set data.  I don't think we need to support
> more complex interactions until we are asked to do so.  Let's see what
> people build first.
>
> Third, I'd like to encapsulate the client stuff in a class so the
> developer
> doesn't have to deal with the guts. It also affords us an opportunity to
> keep our decision about whether the app is a venueclient or not behind a
> clean interface so we can change our minds if we choose too.
>
> Fourth, I think I want to change our minds now on the venue client issue.
> I'm not adamant about it, but I think it's not advantageous to make all
> applications venue clients. They really aren't in a lot of ways
> and it feels
> like it muddy's our design to do that.
>
> Anyhow, those are my four main concerns.  If we can blow through
> this today
> and get a timeline for merging the branch that'd be great.  I'm
> guessing it
> won't be for tomorrow, but perhaps it could be.
>
> Finally, We've gone back and forth on implementation vs interface, and I
> think it's clear (but easily forgotten) that we're building
> implementation.
> We're only building interface where it's missing. We're really relying on
> pyGlobus (and later pyGridWare) for interface. That being said, I don't
> think we need to explicitly build interface objects for all our
> implementation objects where they are only passing through with no added
> value.  We're going to have to go back and remove that later, so
> have it in
> there now?
>
> Ok, enough. I'll stop.  In a half an hour, perhaps you'll have
> time to bring
> some responses to our 10am.  That'd be great :-).
>
> --Ivan
>