On 06/11/10 02:40 PM, Karen Tung wrote:
Hi Darren,
More responses inline. I also remove all the sections
where I have no further comment.
On 06/10/10 12:26 AM, Darren Kenny wrote:
Hi Karen,
More responses, with some parts cut out where I've no more comment...
On 06/10/10 12:17 AM, Karen Tung wrote:
On 06/09/10 02:24, Darren Kenny wrote:
Section 4, page 5:
I'm wondering if the programming language to use is really a
choice for
this project since it's been decided at the higher level of
the CUD design
that Python is the language of choice for new implementations.
I didn't see any specific mention of Python in the architecture
design doc.
It only talks about using an Object Oriented language. So, I
thought I will
be complete, and talk about other potential choices here.
I don't think this is mentioned in the architecture document. Not that I
can find anyway...
That's true, but I feel that this is something that should be fixed
in the
architecture document rather than here since it's certainly the
assumption
that the majority of people are working on.
I agree with you that it should be specified in the architecture
document.
Let me check with Sarah again on this. When we were reviewing the
architecture document, I actually mentioned about this. She said at
that time that she doesn't want to put any implementation language
info there.
I don't think it should be mentioned in the architecture document. In
general, imo, the architecture document should specify software
constraints as deemed necessary to support the architectural goals. I
consider things such as extensibility, scalability, performance and
local standards such as cstyle as possible constraints that should be
named. There are many others, this is just a small example. I don't
believe it is up to the architecture to define design, except in the
form of requirements and constraints that might impact the designs.
There are many cases in Caiman that we don't use Python. For example,
with the error service library that was written some time ago, it was
decided this would be done in C. And, this made good sense. The fact
that we have to hook the error service library in to a number of other
components, possibly written in Python was considered but the overall
goals of this software didn't require it. We also have the AI client in
C, and yet it must interact with the Engine, which is will be in Python.
My point is that the language chosen for the components must support the
requirements and constraints.
Python is a design decision, but to be honest it doesn't have to be
Python. I think Karen's assessment in the design document is the correct
place for this. And, she correctly assessed the possible solutions for
object oriented languages. We could have used Java, or C++, if we felt
it was the better choice.
If you think that the use of Python is critical to how the architecture
is defined or puts constraints on the architecture that we must account
for, then I can see adding it. I don't think it does impact the overall
architecture as defined.
thanks,
sarah
****
thanks,
sarah
****
If the application want to do something else when
execute_checkpoint() is
running, it should run execute_checkpoint() in a thread.
Ok, but I wonder if this is an extra level of threading that really
shouldn't
be needed? For example, right now, the GUI doesn't need to run
liborchestrator
in a separate thread when doing TD, it's something that's hidden from
the GUI,
a change like this means that the GUI needs to add another
thread-level. (It's
more of an example really, since the GUI is probably going to need
re-work
anyway to work with the new CUD).
It just seems that the Engine would seem to be the logical place to
manage the
threading of things, since it's likely to be doing threading anyway...
What you said makes sense. Let me think about that as I add
the threading section.
Section 6.3.1, page 8:
Maybe the use of the term "dangerous" is too severe? It might
be better to
be specific about the risk, and how it might be able to be
prevented.
I can talk about risk, but is there really a way to prevent it?
We do allow checkpoints to exist everywhere. Do we want to restrict it
to loading from a certain location?
I think it's more how people implementing checkpoints and using the
Engine
could mitigate the risk, if at all possible - e.g. we could make the
use of
a directory path a high-risk while using a module name - to be loaded
from
sys.path - would be considered safer? Maybe thus producing a warning
if it's
seen to be a full path, or something...
That sounds like a good suggestion. I will add that as a recommendation
in the description of the register_checkpoint() function. Since we
only throw a warning if it is outside our "recommended area",
people will still be able to continue. So, we are not limiting their
ability to have their checkpoint implementation anywhere.
Section 6.7.1, page 12:
How are you going to guarantee that removal of snapshots from
/tmp will
not remove snapshots from other processes - e.g. are you
using a dir for
each run (/tmp/install_snapshots.PID/), just might be worth
spelling out.
Section 7.4, the second bullet point did talk about using PID for DOC
snapshots that are stored in /tmp. Do you think that's sufficient?
I think that's fine, but I would prefer to see things put in a
sub-directory -
especially in the case of DC - to avoid lots of messy files in /tmp.
(Dave has mentioned the possible mis-use of /tmp).
Based on Dave's recommendation, I will use /var/tmp.
What you said about putting checkpoint related data for a certain
run in a directory makes sense. I don't even need to use
pid to guaranteed having a unique name. I can use the Python
feature to generate a temp name that's unique. So,
each process will have it's own directory in /var/tmp like this:
/var/tmp/<tmp_dir_name>/
Section 7.5, page 15& 16:
How is "DataObjectCacheNotEmpty" state determined? Should the
DOC provide
a is_empty() method is or just checking that
len(doc.children) == 0,
enough?
I was going to use doc.get_descendants() to make sure it return
an empty list. Looks like I can use len(doc.children) too.
Are they both the same? Is one better than the other?
The call to get_descendants() would be (potentially) an expensive
operation if
the tree isn't empty - I will provide a suitable method for you,
especially
given that there are two sub-trees, e.g.:
doc.persistent.has_children
(which is really the one you want to check for roll-backs...)
OK, I will use whatever API you will provide then.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
