OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cooperating message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [regrep-cooperating] Cooperating registries version 0.4


Matt,

I, also have mixed feelings about the Object caching. But not about the
replication or not-to-replication because all caching is built on some form
of replication.  Either in memory to persistent or replication between hosts
(e.g., multicast).

My problem is more with the routing.  How do we route to these objects?
Like you, how do we expire cached objects? Do we create a problem for low
resource users?

Bigger question does caching need to be defined in the federated registry
spec.  Should an external agent provide caching services to the registry.
The registry would simply show it as a flag.

zack

-----Original Message-----
From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
Sent: Friday, July 05, 2002 1:29 PM
To: regrep-cooperating@lists.oasis-open.org
Subject: Re: [regrep-cooperating] Cooperating registries version 0.4


Farrukh,

My mistake.  I have mixed feelings about this topic.  One one hand, I
see how Object caching via replication is logical, on the other hand I
see a need to apply caching on individual objects outside of
"replication". If the objects have a refresh time in them, event
notification isn't needed for this function.  Having two separate
replication methods is not good either...so...

This is my last on this subject for now, to be revisited.  I have no
issues on the rest of the proposal.

Regards,

Matt

On Friday, July 5, 2002, at 10:20  AM, Farrukh Najmi wrote:

> Hi Matt,
>
> The following statement in Cooperating registries version 0.4:
>
> "Data caching will be described later in more detail once the event
> notification proposal is flushed out. This is because it is likely to
> depend
> upon the event notification feature. "
>
> is at line 256 which is the very beginning of "5.4 Object Caching Via
> Replication".
>
> I propose we leave the section 5.4 in the proposal as it acts as a place
> holder and a place to keep though-lets on the subject. Give that the
> audience is small I think we can overcome the confusion it might cause.
> However, if you feel strongly on this point I can take it out.
>
> --
> Regards,
> Farrukh
>
>
> Matthew MacKenzie wrote:
>
>> On Friday, July 5, 2002, at 09:29  AM, Farrukh Najmi wrote:
>>>
>>> Recall that the current proposal has deferred object replication until
>>> after
>>> Event Notification is somewhat defined.
>>
>> I do recall that, however, that fact is not reflected in the proposal.
>> Maybe replication should be removed for now, or the deferral explained
>> in the text.
>>
>> In this case, I think we need to address this even if replication is
>> not
>> addressed, as local caching of objects contained in a remote registry
>> is
>> an important feature because it allows implementors to provide more
>> scalable solutions.
>>
>> -Matt
>>
>> ----------------------------------------------------------------
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC