[EMAIL PROTECTED] wrote:
first thing to say is that I like your new design ! I think it is good that:
So looks like the time was a good investment ;)
A couple of questions...
1. In the "Disadvantages" section you say that there will be larger
exports. Is this really the case ? I would have
Hi Chris,
the most trouble which we have is that we have to maintain states. Ok, I
was the guy who introduced this stuff :(
Nevertheless I had an idea yesterday evening when I tried to draw a
graph of the finite state machine from your idea. The complete system
works without real states. It
[EMAIL PROTECTED] wrote:
Where: U=Updated data exchcnage state
P=Pending data exchange state
C=Commited data exchange state
Sender: U and C
Receiver: P and C
Are these all the required data exchange states ? I know Michael talked
about a rejected state, but I am not sure I
Hi,
>> I am reading the comments of you both and try to understand - whats
>> about creating another conference call (eiter by phone or in an online
>> chat) and discuss a little bit on the topic ?
>> I think this will bring us a little bit further in a shorter time...
>
> happy either way.
>
> Do
Guys,
> I am reading the comments of you both and try to understand - whats
> about creating another conference call (eiter by phone or in an online
> chat) and discuss a little bit on the topic ?
> I think this will bring us a little bit further in a shorter time...
happy either way.
Do either o
Hi Guys,
I am reading the comments of you both and try to understand - whats
about creating another conference call (eiter by phone or in an online
chat) and discuss a little bit on the topic ?
I think this will bring us a little bit further in a shorter time...
Oliver
--
Diese Nachricht wurd
Hi Chris,
I was not thinking of a dynamic schema, I was thinking of something like
this...
Each Object table would have a field "Exchange" the field would initially
be populated as "00" (in this example there are 10 nodes
represented by each digit).
If the record had been exported to n
Michael,
>
>> 1. Incorporate the data exchange fields within the Object tables
>> (certificate, csr, ca_certificate etc).
>
> This is a real problem because you must alter the database for every
> node which you add too the hierarchy. The problem is that some database
> has limits related to column
Hi Chris
[EMAIL PROTECTED] wrote:
1. Incorporate the data exchange fields within the Object tables
(certificate, csr, ca_certificate etc).
This is a real problem because you must alter the database for every
node which you add too the hierarchy. The problem is that some database
has limits
Michael,
thanks for your answers to the questions. One thing is still bothering me,
I am worried that the data exchange is still so complicated. I wonder if
taking a slightly different approach could make it simpler. I shall try
and describe what I am thinking...
1. Incorporate the data exchange
Hi Chris,
[EMAIL PROTECTED] wrote:
1. The the new design must support large volume installations, and the
time taken to perform operations must not increase exponentially with the
number of certificates in the PKI.
This was the reason for the new design.
2. A mechanism must be provided to a
11 matches
Mail list logo
