Issue 3786:  What about valuetype factories? (components-ftf)
Source: Laboratoire d`Informatique Fondamentale de Lille (Mr. Raphael G. Marvie, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of 
<i>valuetype</i> factories has not been really mentionned in the spec, 
especially in the deploiement process. 
If I am right, dealing with <i>valuetypes</i> in a program means to 
instantiate and to register a factory for this <i>valuetype</i> to the 
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>. 
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype 
factories</i> also have to be introduced.</p>  

<!--
<softpkg>
  ...
  <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
      <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
      <fileinarchive name="bank.dll" />
      <entrypoint>createEventFactory</entrypoint>
    </code>
  </implementation>
  ...
</softpkg>
-->

<p><tt><softpkg>
<br>  ...
<br>  <implementation id="...">
<br>    ... all the environment stuff ...
<br>    <descriptor type="Event Factory">
<br>      <fileinarchive>...</fileinarchive>
<br>    </descriptor>
<br>    <code type="DLL">
<br>      <fileinarchive name="bank.dll" />
<br>      <entrypoint>createEventFactory</entrypoint>
<br>    </code>
<br>  </implementation>
<br>  ...
<br></softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a 
<i>home</i> may be portable between containers, which IMHO should be
possible).</p> 

Resolution: see below
Revised Text: In ptc/99-10-04 section 69.3.2.7 page 69-263, replace
The dependency element is used to specify environmental or other
dependencies. The type of dependency is specified by the type attribute. The
dependency element is a child element of both the softpkg element and
implementation elements. When used as a child of softpkg, it specifies
general dependencies applicable to all implementations. When used as a child
of implementation, it specifies implementation specific dependencies.
<!ELEMENT dependency
( softpkgref
| codebase
| fileinarchive
| localfile
| name
)>
<!ATTLIST dependency
type CDATA #IMPLIED
action (assert | install)"assert">
The type attribute specifies the type of the resource required. This may be set
to, for example, “DLL”, “.so”, or “.class”.
with
The dependency element is used to specify environmental or other
dependencies. The type of dependency is specified by the type attribute. The
dependency element is a child element of both the softpkg element and implementation elements. When used as a child of softpkg, it specifies
general dependencies applicable to all implementations. When used as a child
of implementation, it specifies implementation specific dependencies.
<!ELEMENT dependency
( softpkgref
| codebase
| fileinarchive
| localfile
| name
| valuetypefactory
)>
<!ATTLIST dependency
type CDATA #IMPLIED
action (assert | install)"assert">
The type attribute specifies the type of the resource required. The types “DLL”,
“Executable”, and “Java Class” shall be recognized as valid types.
In ptc/99-10-04 section 69.3.2 page 69-272, insert
69.3.2.32 The valuetypefactory Element
The valuetypefactory element contains information needed to register and
utilize a valuetype factory. The valuetypefactory element is a child element of
the dependency element.
<!ELEMENT valuetypefactory
( codebase
| fileinarchive
| link
)>
<!ATTLIST valuetypefactory
repid CDATA #REQUIRED
valueentrypoint CDATA #IMPLIED
factoryentrypoint CDATA #IMPLIED>
The repid attribute specifies the repository id of the valuetype created by the
valuetype factory. The factoryentrypoint attribute specifies an operation or
function that can be used to create an instance of a valuetype factory
associated to the repository id given by repid. The valueentrypoint attribute
specifies an operation or function that can be used to create an instance of a
valuetype using a factory instance created with factoryentrypoint.
In ptc/99-10-04 section 69.3.2 page 69-272, replace
69.3.2.32 The webpage Element
with 69.3.2.33 The webpage Element
In ptc/99-10-04 section 695.1 page 695-336, replace
<!ELEMENT dependency
( softpkgref
| codebase
| fileinarchive
| localfile
| name
)>
with
<!ELEMENT dependency
( softpkgref
| codebase
| fileinarchive
| localfile
| name
| valuetypefactory
)>
In ptc/99-10-04 section 695.1 page 695-339, insert
<!ELEMENT valuetypefactory
( codebase
| fileinarchive
| link
)>
<!ATTLIST valuetypefactory
repid CDATA #REQUIRED
valueentrypoint CDATA #IMPLIED
factoryentrypoint CDATA #IMPLIED>
In ptc/99-10-04 section 69.8.2.1 page 69-323, replace
The properties element is the root element of the properties document. It
contains an optional description and any combination of simple, sequence,
and struct elements.
<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
)*
)> with
The properties element is the root element of the properties document. It
contains an optional description and any combination of simple, sequence,
struct, and valuetype elements.
<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
| valuetype
)*
)>
In ptc/99-10-04 section 69.8.1 page 69-322, replace
The properties document has 3 major elements: simple, sequence and struct.
The simple element describes a single primitive idl type. The sequence element
corresponds to an IDL sequence, and the struct element corresponds to an IDL
struct.
with
The properties document has 4 major elements: simple, sequence, struct, and
valuetype. The simple element describes a single primitive idl type. The
sequence element corresponds to an IDL sequence, the struct element
corresponds to an IDL struct, and the valuetype element corresponds to an IDL
valuetype.
In ptc/99-10-04 section 69.8.2.8 page 69-325, replace
The sequence element is used to represent a sequence of similar types. It may
be a sequence of simple types, a sequence of structs, or a sequence of
sequences. The order of the sequence elements in the property file is preserved
in the constructed sequence. An optional description may be used to describe
the sequence property.
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
)
)>
with The sequence element is used to represent a sequence of similar types. It may
be a sequence of simple types, a sequence of structs, a sequence of
valuetypes, or a sequence of sequences. The order of the sequence elements
in the property file is preserved in the constructed sequence. An optional
description may be used to describe the sequence property.
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
| valuetype*
)
)>
In ptc/99-10-04 section 69.8.2.9 page 69-325, replace
The struct element corresponds to an IDL structure. It may be composed of
simple properties, sequences, or other structs.
<!ELEMENT struct
( description?
, ( simple
| sequence
| struct
)*
)>
with
The struct element corresponds to an IDL structure. It may be composed of
simple properties, sequences, structs, or other valuetypes.
<!ELEMENT struct
( description?
, ( simple
| sequence
| struct
| valuetype
)*
)>
In ptc/99-10-04 section 69.8.2 page 69-326, insert
69.8.2.11 The valuetype Element
The valuetype element is used to specify an IDL valuetype. It may be
composed of simple properties, sequences, structs, or other valuetypes. <!ELEMENT valuetype
( description?
, ( simple
| sequence
| struct
| valuetype
)*
)>
<!ATTLIST valuetype
name CDATA #IMPLIED
type CDATA #REQUIRED
primarykey (true | false) “false” >
name
The name attribute specifies the name of the valuetype attribute as it appears in
IDL. The name attribute is required, except when the valuetype property is used
in a sequence.
type
The type attribute specifies the repository id of the corresponding IDL
valuetype.
primarykey
The primarykey attribute indicates whether or not the valuetype property
provides the state information for an entity component primary key with a
repository id given by the type attribute.
In ptc/99-10-04 section 695.3 page 695-345, replace
<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
)*
)>
with
<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
| valuetype
)* )>
In ptc/99-10-04 section 695.3 page 695-346, replace
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
)
)>
with
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
| valuetype*
)
)>
In ptc/99-10-04 section 695.3 page 695-346, replace
<!ELEMENT struct
( description?
, ( simple
| sequence
| struct
)*
)>
with
<!ELEMENT struct
( description?
, ( simple
| sequence
| struct
| valuetype
)*
)>
In ptc/99-10-04 section 695.1 page 695-346, insert
<!ELEMENT valuetype
( description?
, ( simple
| sequence
| struct | valuetype
)*
)>
<!ATTLIST valuetype
name CDATA #IMPLIED
type CDATA #REQUIRED
primarykey (true | false) “false” >
Actions taken:
August 24, 2000: received issue
May 13, 2002: closed issue
Discussion: 
There are two problems involving valuetype factories. The first is in connection
with events as identified by the author in that there is no straightforward way to
register valuetype factories for events in a generic container. The second
problem is similar to the first in that there is no straightforward way to register
primary key valuetype factories for entity component homes nor is there a
mechanism to specify the state for a primary key that is required to create an
entity component. The solution to the first problem (and part of the solution for
the second problem) is to add a valuetypefactory ELEMENT in the software
package DTD and modify the description of the dependency ELEMENT in the
description of the software package descriptor to explicitly include handling of
valuetype factories. The solution to the second problem requires the addition of a
valuetype ELEMENT in the properties DTD so that the state for the primary key
of an entity component can be specified and identified.
End of Annotations:=====
From: Raphael Marvie <raphael.marvie@lifl.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <14757.8535.530259.584778@gargle.gargle.HOWL>
Date: Thu, 24 Aug 2000 15:21:27 +0200 (MET DST)
To: issues@omg.org
Cc: merle@lifl.fr, marvie@lifl.fr, jcd@one.com
Subject: [Component FTF] What about valuetype factories?
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
Content-Type: text/plain; charset=us-ascii
X-UIDL: GP:!!Q?>e92:Y!!F(Ne9


Hi,

This may be an issue for the Component FTF.

Raphael

-8<-

What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of 
<i>valuetype</i> factories has not been really mentionned in the spec, 
especially in the deploiement process. 
If I am right, dealing with <i>valuetypes</i> in a program means to 
instantiate and to register a factory for this <i>valuetype</i> to the 
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>. 
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype 
factories</i> also have to be introduced.</p>  

<!--
<softpkg>
  ...
  <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
      <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
      <fileinarchive name="bank.dll" />
      <entrypoint>createEventFactory</entrypoint>
    </code>
  </implementation>
  ...
</softpkg>
-->

<p><tt>&lt;softpkg>
<br>&nbsp; ...
<br>&nbsp; &lt;implementation id="...">
<br>&nbsp;&nbsp;&nbsp; ... all the environment stuff ...
<br>&nbsp;&nbsp;&nbsp; &lt;descriptor type="Event Factory">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;fileinarchive>...&lt;/fileinarchive>
<br>&nbsp;&nbsp;&nbsp; &lt;/descriptor>
<br>&nbsp;&nbsp;&nbsp; &lt;code type="DLL">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;fileinarchive name="bank.dll"
/>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;entrypoint>createEventFactory&lt;/entrypoint>
<br>&nbsp;&nbsp;&nbsp; &lt;/code>
<br>&nbsp; &lt;/implementation>
<br>&nbsp; ...
<br>&lt;/softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a 
<i>home</i> may be portable between containers, which IMHO should be
possible).</p> 

-- 
    ___   Raphael MARVIE  (marvie@lifl.fr)  http://www.lifl.fr/~marvie
   /_ _\   Equipe GOAL - Labo. d'Informatique Fondamentale de Lille
  @ 0 0 @   UPRESA 8022 - Bat. M3 - 59655 Villeneuve d'Ascq (France)
_o0o_O_o0o_  --Linux, Corba, C++, Java, CorbaScript, Smalltalk and me.


X-Sender: evans@mail.cpi.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 05 Nov 2001 11:40:45 -0500
To: Philippe.Merle@lifl.fr, components-ftf@omg.org
From: "J. Scott Evans" <evans@cpi.com>
Subject: Re: Resolutions for issues 3232, 3786, 3925, 4576, 4577,
4578,
  and 4579
In-Reply-To: <200111051208.NAA13942@karjala.lifl.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-UIDL: 7~;e9[pVd9i[Qd9p4'e9


Hi Philippe,

At 01:08 PM 11/5/01 +0100, Philippe.Merle@lifl.fr wrote:
Hello Scott,

> From: "J. Scott Evans" <evans@cpi.com>
> Subject: Resolutions for issues 3232, 3786, 3925, 4576, 4577, 4578,
> and
>   4579
>
> Hi All,
> I have submitted a first draft of our proposed resolutions for
> issues 3232, 3786, 3925, 4576, 4577, 4578, and 4579. The doc and pdf
> files
> are posted in <a href="http://cgi.omg.org/pub/componentsftf/"
> eudora="autourl"><font
> color="#0000FF"><u>http://cgi.omg.org/pub/componentsftf/</a></u></font>.
> Please review the resolutions and see if you can find any
> problems. I am
> especially concerned about resolutions to issues 4576, 4577, 4578,
> and 4579
> being incomplete simply because there may be possibilities we
> haven't thought of that could present problems to compilers (we
> haven't
> experienced any yet but further testing may change that)
> Philippe, would you mind checking the doc, section, and page
> reference
>
> Juergen, thanks for posting the files.
> Scott

OK I have reviewed your resolutions and

- added some presentation indentations,

- changed some referenced page numbers,

- simplified issue 3786 by removing replacements of unchanged texts
  and only pointing new texts out.

- changed the meaning of the entrypoint of the valuetype factory in
  Issue 3786
  i.e. a function to create an instance of the valuetype
       -> a function to create an instance of the valuetype factory

Well, I actually intended the entrypoint to be an operation that is
used to
create an instance of the valuetype not the factory.  A default
constructor
is assumed for the valuetype factory.  The entrypoint is needed so
that the
assembly code can use the factory instance to create a primary key
instance
and the entrypoint is the void argument operation that the assembly
calls to
create the primary key (very similar to language mapping feature
regarding
home entry point).  Primary key state must be public so the DII (or in
Java
the reflection API) can be used to set primary key state.  If the
entrypoint
operation to create the valuetype is not explicit then there is no way
for the
assembly code to create the primary key.  Does this make sense?

- simplified issue 4577 by removing replacements of unchanged texts
  and only pointing new texts out,

  Scott could you check this new 4577 resolution and control if I
  don't forget
  any part of your proposed replacements?

Yes, I'll do this ASAP.


Two questions: Valuetypefactory is now a kind of dependencies
- What are impacts on deployment API?
- Do you need to add operations to install valuetype factories?

The impact on deployment is that the valuetype factories must be
registered with the Container ORB and AssemblyFactory ORB.
I intentionally added the valuetype factory as an additional
dependency
since that is exactly what it is in that it is similar to other DLL
.so and
.class dependencies that an application may have.  So, I don't
think anything needs to be changed with the Deployment API since
a compliant CCM implementation must handle all dependencies defined
in the CSD files.  How the container gets the dependency information
is a configuration issue and, until we can democratically establish a
set
of ConfigValue configuration names, will be CCM dependent.  Make
sense?

The draft document for vote 8 is available at:

http://www.lifl.fr/~merle/CCM/Draft_Vote8.doc
http://www.lifl.fr/~merle/CCM/Draft_Vote8.ps

Thanks to other contributors to send their resolutions asap:
The Vote 8 would run before the Dublin meeting so before
the Thrusday 8th November.

Thanks for drafting the Vote * docs!

Scott

A+
Philippe Merle
--
___________________________________________________________________________
Dr. Philippe Merle - Associate Researcher at INRIA
Laboratoire d'Informatique Fondamentale de Lille
UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3
Universite des Sciences et Technologies de Lille
59655 Villeneuve d'Ascq CEDEX France

      Tel: (33) (0)3 20 43 47 21
      Fax: (33) (0)3 20 43 65 66
   E-Mail: Philippe.Merle@lifl.fr
Home Page: http://www.lifl.fr/~merle
 See also: http://corbaweb.lifl.fr/
___________________________________________________________________________




From: Philippe.Merle@lifl.fr
Received: from (merle@localhost)
          by karjala.lifl.fr (8.9.1b+Sun/jtpda-5.3.3) id SAA04089
          ; Mon, 5 Nov 2001 18:16:57 +0100 (MET)
Date: Mon, 5 Nov 2001 18:16:57 +0100 (MET)
Message-Id: <200111051716.SAA04089@karjala.lifl.fr>
To: Philippe.Merle@lifl.fr, components-ftf@omg.org, evans@cpi.com
Subject: Re: Resolutions for issues 3232, 3786, 3925, 4576, 4577,
4578,
  and 4579
X-Sun-Charset: US-ASCII
Content-Type: text
X-UIDL: j/9!!<15e9VV8e9C91!!

Hello Scott,

> From: "J. Scott Evans" <evans@cpi.com>
> Subject: Re: Resolutions for issues 3232, 3786, 3925, 4576, 4577,
> 4578,
>   and 4579
> 
> >OK I have reviewed your resolutions and
> >
> >- added some presentation indentations,
> >
> >- changed some referenced page numbers,
> >
> >- simplified issue 3786 by removing replacements of unchanged texts
> >   and only pointing new texts out.
> >
> >- changed the meaning of the entrypoint of the valuetype factory in
> Issue 3786
> >   i.e. a function to create an instance of the valuetype
> >        -> a function to create an instance of the valuetype
> factory
> 
> Well, I actually intended the entrypoint to be an operation that is
> used to
> create an instance of the valuetype not the factory.  A default
> constructor
> is assumed for the valuetype factory.  The entrypoint is needed so
> that the
> assembly code can use the factory instance to create a primary key
> instance
> and the entrypoint is the void argument operation that the assembly
> calls to
> create the primary key (very similar to language mapping feature
> regarding
> home entry point).  Primary key state must be public so the DII (or
> in Java
> the reflection API) can be used to set primary key state.  If the
> entrypoint
> operation to create the valuetype is not explicit then there is no
> way for the
> assembly code to create the primary key.  Does this make sense?

But to handle valuetypes is required to register a valuetype factory
to the ORB.
If the entrypoint does not refer to a function that creates valuetype
factory instances,
then I see no way to create valuetype factories in C++ for instance,
there is no way to obtain a pointer to a default constructor.
So I prefer that the entrypoint refers to a function that creates the
valuetype
factory. In the assembly, you could call this function to create a
valuetype
factory and after call on it an operation to obtain a new instance.
Perhaps, all primary key factory classes should implement a base
interface
like:

local interface PrimaryKeyBaseFactory
{
  PrimaryKeyBase create();
};

> 
> >- simplified issue 4577 by removing replacements of unchanged texts
> >   and only pointing new texts out,
> >
> >   Scott could you check this new 4577 resolution and control if I
don't 
> > forget
> >   any part of your proposed replacements?
> 
> Yes, I'll do this ASAP.

OK.

> >Two questions: Valuetypefactory is now a kind of dependencies
> >- What are impacts on deployment API?
> >- Do you need to add operations to install valuetype factories?
> 
> The impact on deployment is that the valuetype factories must be
> registered with the Container ORB and AssemblyFactory ORB.
> I intentionally added the valuetype factory as an additional
dependency
> since that is exactly what it is in that it is similar to other DLL
.so and
> .class dependencies that an application may have.  So, I don't
> think anything needs to be changed with the Deployment API since
> a compliant CCM implementation must handle all dependencies defined
> in the CSD files.  How the container gets the dependency information
> is a configuration issue and, until we can democratically establish
a set
> of ConfigValue configuration names, will be CCM dependent.  Make
sense?

OK, I agree with this.

> 
> >The draft document for vote 8 is available at:
> >
> >http://www.lifl.fr/~merle/CCM/Draft_Vote8.doc
> >http://www.lifl.fr/~merle/CCM/Draft_Vote8.ps
> >
> >Thanks to other contributors to send their resolutions asap:
> >The Vote 8 would run before the Dublin meeting so before
> >the Thrusday 8th November.
> 
> Thanks for drafting the Vote * docs!
> 
> Scott

A+
Philippe Merle
--
___________________________________________________________________________
Dr. Philippe Merle - Associate Researcher at INRIA
Laboratoire d'Informatique Fondamentale de Lille
UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3
Universite des Sciences et Technologies de Lille
59655 Villeneuve d'Ascq CEDEX France

      Tel: (33) (0)3 20 43 47 21
      Fax: (33) (0)3 20 43 65 66
   E-Mail: Philippe.Merle@lifl.fr
Home Page: http://www.lifl.fr/~merle
 See also: http://corbaweb.lifl.fr/
___________________________________________________________________________


X-Sender: evans@mail.cpi.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 05 Nov 2001 12:57:27 -0500
To: Philippe.Merle@lifl.fr, Philippe.Merle@lifl.fr,
components-ftf@omg.org
From: "J. Scott Evans" <evans@cpi.com>
Subject: Re: Resolutions for issues 3232, 3786, 3925, 4576, 4577,
4578,
  and 4579
In-Reply-To: <200111051716.SAA04089@karjala.lifl.fr>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
X-UIDL: RU,!!<ZIe9@F1e9Qa_d9


Hi Philippe,

At 06:16 PM 11/5/01 +0100, Philippe.Merle@lifl.fr wrote:
Hello Scott,

> From: "J. Scott Evans" <evans@cpi.com>
> Subject: Re: Resolutions for issues 3232, 3786, 3925, 4576, 4577,
> 4578,
>   and 4579
> 
> >OK I have reviewed your resolutions and
> >
> >- added some presentation indentations,
> >
> >- changed some referenced page numbers,
> >
> >- simplified issue 3786 by removing replacements of unchanged texts
> >   and only pointing new texts out.
> >
> >- changed the meaning of the entrypoint of the valuetype factory in
> Issue 3786
> >   i.e. a function to create an instance of the valuetype
> >        -> a function to create an instance of the valuetype
> factory
> 
> Well, I actually intended the entrypoint to be an operation that is
> used to
> create an instance of the valuetype not the factory.  A default
> constructor
> is assumed for the valuetype factory.  The entrypoint is needed so
> that the
> assembly code can use the factory instance to create a primary key
> instance
> and the entrypoint is the void argument operation that the assembly
> calls to
> create the primary key (very similar to language mapping feature
> regarding
> home entry point).  Primary key state must be public so the DII (or
> in Java
> the reflection API) can be used to set primary key state.  If the
> entrypoint
> operation to create the valuetype is not explicit then there is no
> way for the
> assembly code to create the primary key.  Does this make sense?

But to handle valuetypes is required to register a valuetype factory
to the ORB.
If the entrypoint does not refer to a function that creates valuetype
factory instances,
then I see no way to create valuetype factories in C++ for instance,
there is no way to obtain a pointer to a default constructor.
So I prefer that the entrypoint refers to a function that creates the
valuetype
factory. In the assembly, you could call this function to create a
valuetype
factory and after call on it an operation to obtain a new instance.
Perhaps, all primary key factory classes should implement a base
interface
like:

local interface PrimaryKeyBaseFactory
{
  PrimaryKeyBase create();
};

You are correct, I sometimes fail to take off my Java hat 
and remember to think in terms of all supported languages :^(
We could also simply have two entry point attributes in the
DTD.  For example:

 <!ELEMENT valuetypefactory 
( codebase
| fileinarchive
| link
)>
 <!ATTLIST valuetypefactory
repid      CDATA #REQUIRED
valueentrypoint CDATA #IMPLIED
factoryentrypoint CDATA #IMPLIED>

  The repid attribute specifies the repository id of the valuetype
  created by the
  valuetype factory. The factoryentrypoint attribute specifies an
  operation or function
  that can be used to create an instance of a valuetype factory
  associated with the 
  repository id given by repid. The valueentrypoint attribute
  specifies an operation or function
  that can be used to create an instance of a valuetype using a
  factory instance created with
  factoryentrypoint.

I kind of like this better because it is a little more flexible and is
easier to fix in resolution
(adding the local interface will require changes to other areas of the
spec including the
language mapping I would think).  If everyone/anyone prefers the local
interface approach 
I'll go along with the democratic nomimation ;-)

> 
> >- simplified issue 4577 by removing replacements of unchanged texts
> >   and only pointing new texts out,
> >
> >   Scott could you check this new 4577 resolution and control if I
don't 
> > forget
> >   any part of your proposed replacements?
> 
> Yes, I'll do this ASAP.

OK.

I've looked over your version and I don't see that you've missed
anything.
If I had turned on change tracking I would know for sure :^(

> >Two questions: Valuetypefactory is now a kind of dependencies
> >- What are impacts on deployment API?
> >- Do you need to add operations to install valuetype factories?
> 
> The impact on deployment is that the valuetype factories must be
> registered with the Container ORB and AssemblyFactory ORB.
> I intentionally added the valuetype factory as an additional
dependency
> since that is exactly what it is in that it is similar to other DLL
.so and
> .class dependencies that an application may have.  So, I don't
> think anything needs to be changed with the Deployment API since
> a compliant CCM implementation must handle all dependencies defined
> in the CSD files.  How the container gets the dependency information
> is a configuration issue and, until we can democratically establish
a set
> of ConfigValue configuration names, will be CCM dependent.  Make
sense?

OK, I agree with this.

Great.

Scott

> 
> >The draft document for vote 8 is available at:
> >
> >http://www.lifl.fr/~merle/CCM/Draft_Vote8.doc
> >http://www.lifl.fr/~merle/CCM/Draft_Vote8.ps
> >
> >Thanks to other contributors to send their resolutions asap:
> >The Vote 8 would run before the Dublin meeting so before
> >the Thrusday 8th November.
> 
> Thanks for drafting the Vote * docs!
> 
> Scott

A+
Philippe Merle
--
___________________________________________________________________________
Dr. Philippe Merle - Associate Researcher at INRIA
Laboratoire d'Informatique Fondamentale de Lille
UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3
Universite des Sciences et Technologies de Lille
59655 Villeneuve d'Ascq CEDEX France

      Tel: (33) (0)3 20 43 47 21
      Fax: (33) (0)3 20 43 65 66
   E-Mail: Philippe.Merle@lifl.fr
Home Page: http://www.lifl.fr/~merle
 See also: http://corbaweb.lifl.fr/
___________________________________________________________________________