RE: Comments on draft-ryan-java-schema-02

[Andrew Probert <AndrewP@rotek.com.au>]

I agree with Jeffrey's requirement and to not include this requirement cuts
off a whole avenue of interesting possiblities.

In the case of distributed directories, it is very useful to use LDAP to
retrieve JAR files from the nearest directory, or allow that directory to
retrieve content from other trusted directories to which it may be
interconnected.

I think the statement "The general model for a directory is to store
(reference) information about entities rather than storing the entities
themselves" is not a supportable assumption.

There is certainly work going on the in the network management field, where
LDAP, DAP, DSP protocols are being used to route management queries, and
data around complex networks.



Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171



> -----Original Message-----
> From:	Vincent Ryan [SMTP:Vincent.Ryan@ireland.Sun.COM]
> Sent:	Thursday, April 29, 1999 1:21 AM
> To:	Jeffrey Spirn
> Cc:	ietf-ldapext@netscape.com; arbldap@us.oracle.com;
> aezzat@us.oracle.com; jcooper@us.oracle.com
> Subject:	Re: Comments on draft-ryan-java-schema-02
> 
> 
> Thanks for your feedback Jeff.
> 
> The general model for a directory is to store (reference)
> information about entities rather than storing the entities
> themselves. Jarfiles are typically stored in a filesystem.
> I'm not convinced that it'd be useful to store them in the
> directory. However, there may be merit to storing a jarfile
> manifest (and a reference to the jarfile) in the directory
> - how would you see it being used in practice?
> 
> Regarding point 2 below, the existing javaClassName and
> javaClassNames attributes are already searchable. They
> describe an object in a well-defined manner. Introducing
> a new attribute with type/value pairs would also require
> the definition of its contents in order to be generally
> useful. It'd be more in keeping with LDAP to define a
> specific EJB schema rather than defining a general-purpose
> object that describes itself by means of its type/value pairs.
> 
> 
> 
> Jeffrey Spirn wrote:
> > 
> > I have two suggestions:
> > 
> > 1) It would be a good idea to define a way to store Jar files, as a
> > representation of Java classes (and EJB's, etc.).  Perhaps this is
> > viewed as out of the scope of this proposal, since the draft discusses
> > only individual objects.  But it will be very useful if class files
> > (along with manifests and deployment descriptors in the case of EJB's)
> > can also be stored in the directory.  It should even be possible for a
> > serialized object to specify a value for its "javaCodebase" attribute
> > which is an ldap URL of a Jar file in the same or another directory.
> > 
> > 2) LDAP searches cannot be expected to be performed against the interior
> > of serialized Java objects (or the contents of Jar files!), and yet the
> > ability to search is one of the advantages of a directory.  It would be
> > useful to add an optional, multi-valued attribute to Java objects and
> > jar files in the directory which is a set of strings to search against.
> > Each value in this attribute could be a string of the form
> > <name>=<value>, where "name" and "value" are specific to the type of
> > object of Jar file.  (For example, it might include portions of the
> > manifest file in the case of an EJB jar file.)
> > 
> > Regards,
> > Jeff Spirn
> > Oracle