Re: [Ganymede Dev] Re: many G... questions

[Stephan Wiesand <wiesand@ifh.de>]

On Thu, 4 Jul 2002, Jonathan Abbey wrote:

> I'm not familiar with the JAAS.  I imagine the issues would revolve
> around how the client would get access to the TGT if it is run from a
> browser.  By default, of course, a downloaded Java applet has almost
> no privileges to access anything of the local environment.  The
> ganymede GUI client and xmlclients might benefit from that if run as
> an application from a command line, but the ganymede GUI client is
> dual-mode, and when run as an applet has very restricted privileges.

Yes that's a problem. I think these restrictions are relaxed for signed
applets?

> An additional question is how to represent the privileges that the
> Kerberos ticket is authenticating for.  Ganymede is designed to have
> its own record of the user account, and to rely on it to decide login
> and personae availability.  I imagine that changing Ganymede so that
> it referenced an external authenticator could certainly be done if
> need be, but I'm afraid I don't have enough experience with Kerberos
> to understand the advantages over simply entering the
> username/password pair.

Not having to do it is an obvious advantage at least for frequent users.
By the way, is there an option to allow changing Admin Personae without
having to type a password? After all, the user has authenticated himself
once he's got a session.

I understand JAAS would allow for many different authentication
mechanisms including passwords, without changing the login code once it's
used. But then, I'm no more familiar with it than you. But if we find or
pay someone who is to do the change, would you accept the patch?

> | But at the time DBEditObject.finalize...() is called, we know exactly
> | what changes if the transaction is committed, don't we? And we are allowed
> | to create new objects and add them to the current DBEditSet.
>
> The DBEditObject.finalize...() methods are called to finalize changes
> to individual fields, not to all changes to a given object.

So one would have to check whether the change event object already
exists, create it if not, then set the information for the respective
field. Not as clean as it could be, but it would also make the problem
you line out in the next paragraph a non-issue, right?

> It would certainly be possible to add another method to DBEditObject
> that would be called before commitPhase1(), as long as some reasonable
> semantics could be established for it.  The trick would be that if you
> hit 'commit', and this method was called on all objects that have been
> checked out for editing by the transaction, and then the commit fails
> for some reason (such as a missing required field in some object in
> the transaction), you'd want to be sure that a subsequent commit
> attempt wouldn't generate redundant change event objects.

> | So why not create a on object of type "event: Change to User". It's
> | existance after the commit means that something has to be done on a
> | platform. The builder task could then check for such objects, and act
> | accordingly for each with the value "new" for the attribute "status" by
> | sending the relevant information to the platform and then changing the
> | status to "sent". The platform would acknowledge the event by setting the
> | status to "read" via xmlclient, do the work, then update the status to
> | "done" (or delete the event object). In case of failure, status is sent to
> | "failed". A scheduled task would check for "failed" event objects and
> | overdue ones - resend them and/or notify someone.
>
> Sure, that sounds very feasible.
>
> | It's still ugly because of the additional builder tasks triggered, but
> | those should be fairly cheap. But communication with the platforms
> | would be fully decoupled from transaction commits, and full status
> | information would be available within Ganymede, changes pending execution
> | could be listed with the query facility, ...
> |
> | Wouldn't this work?
>
> Yes, I think it would work, and work well.  There would obviously be
> some design effort required to implement something clean, and it's
> possible that some generic mechanism could be added that others might
> be able to make use of in a generic fashion if it was done right,
> but I see absolutely no difficulty in doing such a thing.

Sounds great.

> We'd probably want to have some sort of appropriate object queueing
> and ordering mechanism, for instance.  Right now, neither the GUI
> client nor the server API provides a method for reordering items
> within a Vector field, which would probably be important if you wanted
> to maintain object queues, unless you simply used date fields for
> everything.

I'm not sure whether object queues or vectors of change events would be
needed at all. Ordering is important, though, since successfully
processing events out of order on the platform will not generally
possible. If change event objects were labelled by transaction ID+object
name, would it be simple for the builder/scheduled task to process them
in the right order?

One might even want dependencies between events (within a single
transaction) to allow deferral of execution of those that depend on
others (no way to add a user to a pts group before it exists, for
instance).

If it was totally trivial, you'd probably have done it...

> The one place I've seen problems with heavy linkages is when you have
> certain objects that lots of objects get symmetrically linked to.  In
> such cases, only one transaction at a time can make or break a link to
> the common object, which may well limit concurrency.  By making it an
> anonymous link, the current Ganymede server core can handle tons of
> concurrent link and unlink operations, though.

Aren't owner groups prone to this?

> | It seems straightforward to me: Your fine tree widget handles subfolders
> | nicely, and as a user I'd like queries to consider the object type I
> | specify and all derived types. I'm probably missing something, what is it?
>
> Mm, no, perhaps not.  You're thinking that there would be a User
> folder, which you would open and see 'UNIX Users', 'NT Users',
> 'UNIX&NT Users' each as separate subfolders, along with all plain
> Users listed thereunder?

Close. Just the "Unix" and "NT" subfolders within the "Accounts" folder.
Those would be linked to the "Accounts" vector field of the "User"
object. If there were plain "Account" objects as well, I wouldn't mind
seeing them at the same level as the subfolders. Having subfolders listed
first would probably be convenient.

> | Would it be possible to allow a *list* of object types as reference
> | targets instead of just one? That would solve most cases I have in mind
> | nicely.
>
> Sure, the DBEditObject class already has methods that you can override
> to generate custom choice lists for InvidDBFields.  Right now, though,
> the GUI client doesn't show any kind of type identifier for listed
> objects, and if you had two objects of differing kinds with the same
> name, it would probably get confused.

Labels could be kept unique, for example by having a hidden label
field set to <prefix>.<object name> by the plugin. In my example, one of
my unix accounts would read "unix.wiesand".

The pity is that the schema editor seems to choke on these things.
It won't allow me to set up bidirectional links unless I specify the
target object type. Ok, using vi on schema.xml would do the trick
as long as I keep Field Names and IDs consistent, but touching such
an object definition with the schema editor would break it, and
being unable to use this fine tool is a *major* loss.

> I've thought about making the Invid selector widget in the GUI client
> be tree-based in some fashion, to reflect the types of mixed choice
> lists.  Or, alternatively, at least show an icon of some sort and
> track and display the type identity to distinguish things that might
> not have a shared namespace.

I consider the requirement to have objects in one list share one namespace
very reasonable and acceptable.

> Derivable types aside, the major extension I've tried to consider to
> Ganymede's type system is to allow for hierarchical object containment.
>
> That would also complicate the GUI, especially considering that at
> present an object may have more than one owner.  If ownership was made
> congruent with containership, the client's object tree could not
> literally be a tree, as individual objects could appear under multiple
> container-owners.  The XML file format that Ganymede uses currently
> would need to be changed as well, along with the query engine, and so
> on.

I can't think of anything that could be accomplished by hierarchical
object containment, but not by derivable types and embedded objects
as available today. But maybe that's because it's getting late...

> Especially if you're thinking of going away from doing complete builds
> at each build time, I would think the scalability should be all right.

I dumped the data of some 2500 real accounts, plus groups, into the
example UserKit. The GUI copes very well with lists of that size, both the
tree widget and the edit forms do just fine.

Creating a schema vaguely similar to what we'll finally want to have
(sans plugins) and writing a perl script to fill it with twice the
anticipated amount of data via xmlclient shouldn't be too much work,
thanks to ganymede's maturity and documentation, and we'll hopefully do
that soon. I'll let you know the result.

Have you ever run a series of such tests?

Cheers,
--

 ----------------------------------------------------
| Stephan Wiesand  |                                |
|                  |                                |
| DESY Zeuthen     | phone  +49 33762 7 7370        |
| Platanenallee 6  | fax    +49 33762 7 7216        |
| D-15738 Zeuthen  | mobile +49 171 317 6367        |
| Germany          | email  stephan.wiesand@desy.de |
 ----------------------------------------------------





----------------------------------------------------------------------------
To make changes to your subscription to the Ganymede Dev mailing list, send
mail to majordomo@arlut.utexas.edu.

To unsubcribe, include the line

unsubscribe ganymede-dev

in the body of your mail message

Visit the Ganymede web page at http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------