It's been rumoured that Tyson Dowd said:
>
> On 02-Jan-2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Tyson,
> >
> > Re:
> > It's been rumoured that Christopher Browne said:
> > > CORBA Notification or Event services rather than changing GUIDs all the
> > > time.
> >
> >
> > We also h
Tyson Dowd <[EMAIL PROTECTED]> writes:
> Oops, forgot to mention that I don't know what SOL means, so I couldn't
> answer that bit.
S**t Out of Luck is the normal definition. :)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Pr
On 02-Jan-2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> We also have Derek Atkin's announcement that he has demo code working
> that does event notification via onc-rpc. Since soap/xml is our third
> candidate for network services, does it have something analogous that
> we're not aware of
On 02-Jan-2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tyson,
>
> Re:
> It's been rumoured that Christopher Browne said:
> > CORBA Notification or Event services rather than changing GUIDs all the
> > time.
>
>
> We also have Derek Atkin's announcement that he has demo code working
> t
On Tue, 2 Jan 2001 [EMAIL PROTECTED] wrote:
> I suggest posting the demo code somewhere when you have it shaken
> out (including a thorough explanation of why this is an important
> feature/'good thing'). Can you abstract the interfaces to something
> generic?
> Is there some sort of rpc-speci
<[EMAIL PROTECTED]> writes:
> It's been rumoured that Derek Atkins said:
> > Again, see my long mail for a more "coherent" explanation.
>
> Do you envision keeping one socket open for the entire session?
> Or can a socket be torn down and rebuilt without loosing the session?
I envision keeping
It's been rumoured that David Merrill said:
> The alternative is to assign a version number that increments each
> time the record is updated. Then we need only check one field to know
> if changes have been made. See any problems with that approach?
That works, and seems to solve other problems
It's been rumoured that Derek Atkins said:
> Again, see my long mail for a more "coherent" explanation.
Do you envision keeping one socket open for the entire session?
Or can a socket be torn down and rebuilt without loosing the session?
I envision, for example, a gnucash client staying up for
Tyson,
Re:
It's been rumoured that Christopher Browne said:
> CORBA Notification or Event services rather than changing GUIDs all the
> time.
We also have Derek Atkin's announcement that he has demo code working
that does event notification via onc-rpc. Since soap/xml is our third
candidate f
<[EMAIL PROTECTED]> writes:
> I suggest posting the demo code somewhere when you have it shaken
> out (including a thorough explanation of why this is an important
> feature/'good thing'). Can you abstract the interfaces to something
> generic?
I plan to do so, once I work out a few kinks. I
It's been rumoured that Derek Atkins said:
>
> In my solution, we would define two RPC programs, the forward
> (client->server) program which would be all the client-originated
> requests and server responses, and the callback/event (server->client)
> program, which would be the event notificatio
How about an object "version" number.. The GUID is static for an
object across all changes, but the version number is monotonically
incrased for every change. The audit trail can be based on the
version number. A client need only remember the version it has and
can easily determine that an obje
On Tue, Jan 02, 2001 at 02:38:45PM -0600, Christopher Browne wrote:
> On Tue, 02 Jan 2001 14:23:22 CST, the world broke into rejoicing as
> [EMAIL PROTECTED] said:
> > It's been rumoured that David Merrill said:
> > >
> > > I read this again and changed my mind, and I'll tell you why...
> > >
>
On Tue, 02 Jan 2001 14:23:22 CST, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> It's been rumoured that David Merrill said:
> >
> > I read this again and changed my mind, and I'll tell you why...
> >
> > When a record is changed, it is moved to the audit table, and a new
> > recor
It's been rumoured that David Merrill said:
>
> I read this again and changed my mind, and I'll tell you why...
>
> When a record is changed, it is moved to the audit table, and a new
> record is generated. That means a new GUID as well. So if the record
> exists in the transaction table, it is
On Mon, Jan 01, 2001 at 11:43:35PM -0800, Dave Peticolas wrote:
> David Merrill writes:
> > I read this again and changed my mind, and I'll tell you why...
> >
> > When a record is changed, it is moved to the audit table, and a new
> > record is generated. That means a new GUID as well. So if the
David Merrill writes:
> I read this again and changed my mind, and I'll tell you why...
>
> When a record is changed, it is moved to the audit table, and a new
> record is generated. That means a new GUID as well. So if the record
> exists in the transaction table, it is necessarily the same "ori
I read this again and changed my mind, and I'll tell you why...
When a record is changed, it is moved to the audit table, and a new
record is generated. That means a new GUID as well. So if the record
exists in the transaction table, it is necessarily the same "original"
data.
On Sat, Dec 30, 20
On Sat, Dec 30, 2000 at 01:04:01AM -0600, [EMAIL PROTECTED] wrote:
>
> It's been rumoured that David Merrill said:
> >
> > Option 1, no concurrent edits allowed:
> >
> > client 1 -> server "I want to edit record 1"
> > server -> client 1 "OK"
> >
> > client 2 -> server "I want to edit record 1
[EMAIL PROTECTED] writes:
> corba provides an asynchronous event mechanism that soap lacks, and I
> beleive onc-rpc lacks. We could e.g. do this:
Onc-rpc short-of lacks this, but I've been building an ONC-RPC system
that would do what we want. Indeed, I _JUST_ got it working this
morning (and
Hi David,
Excellent!
It's been rumoured that David Merrill said:
> > Lets assume we are using onc-rpc (or corba or xml-rpc or soap).
> >
> > ** GUI user uses mouse to highlight transaction for editing.
> > ** xaccTransBeginEdit() sends rpc/iiop/xml message to server.
> > ** GUI user types in
On Fri, Dec 29, 2000 at 01:57:56PM -0800, Dave Peticolas wrote:
> David Merrill writes:
> > On Fri, Dec 29, 2000 at 01:29:12PM -0800, Dave Peticolas wrote:
> > > David Merrill writes:
> > > >
> > > > Yes, I am trying to do it this way if I can. It is decidedly
> > > > nontrivial and may not make
David Merrill writes:
> On Fri, Dec 29, 2000 at 01:29:12PM -0800, Dave Peticolas wrote:
> > David Merrill writes:
> > >
> > > Yes, I am trying to do it this way if I can. It is decidedly
> > > nontrivial and may not make it into the first release. I am already
> > > becoming rather ruthless about
On Fri, Dec 29, 2000 at 01:29:12PM -0800, Dave Peticolas wrote:
> David Merrill writes:
> >
> > Yes, I am trying to do it this way if I can. It is decidedly
> > nontrivial and may not make it into the first release. I am already
> > becoming rather ruthless about cutting things.
> >
> > I *do* k
David Merrill writes:
>
> Yes, I am trying to do it this way if I can. It is decidedly
> nontrivial and may not make it into the first release. I am already
> becoming rather ruthless about cutting things.
>
> I *do* keep a complete auditing trail, so changes *can* be reversed.
That's very nice
On Fri, Dec 29, 2000 at 12:39:17PM -0600, [EMAIL PROTECTED] wrote:
> It's been rumoured that David Merrill said:
> >
> > Do you mean to
> > set a "lock" (not a real DB lock though, or at least not necessarily a
> > real DB lock) when the user BEGINS to do an edit, so other users
> > cannot? Now T
It's been rumoured that David Merrill said:
>
> Do you mean to
> set a "lock" (not a real DB lock though, or at least not necessarily a
> real DB lock) when the user BEGINS to do an edit, so other users
> cannot? Now THAT makes sense. :-)
Yes. I tend to speak metaphorically.
> > If you think a
On Fri, Dec 29, 2000 at 11:38:40AM -0600, [EMAIL PROTECTED] wrote:
> It's been rumoured that David Merrill said:
> >
> > On Fri, Dec 29, 2000 at 02:46:51AM -0600, [EMAIL PROTECTED] wrote:
> > > It's been rumoured that [EMAIL PROTECTED] said:
> > > >
> > > > It should be clear why Transaction eng
It's been rumoured that David Merrill said:
>
> On Fri, Dec 29, 2000 at 02:46:51AM -0600, [EMAIL PROTECTED] wrote:
> > It's been rumoured that [EMAIL PROTECTED] said:
> > >
> > > It should be clear why Transaction engine and DB engine should stay close;
> > > they will need to communicate quite
On Fri, Dec 29, 2000 at 02:46:51AM -0600, [EMAIL PROTECTED] wrote:
> It's been rumoured that [EMAIL PROTECTED] said:
> >
> > It should be clear why Transaction engine and DB engine should stay close;
> > they will need to communicate quite a lot of data in order to negotiate
> > the parts that ar
It's been rumoured that [EMAIL PROTECTED] said:
>
> It should be clear why Transaction engine and DB engine should stay close;
> they will need to communicate quite a lot of data in order to negotiate
> the parts that are to be submitted to the GUI. A "for instance" would
> be that if the DB doe
[EMAIL PROTECTED] writes:
> I would consider it a "Good Thing" for the security server and the
> transaction engine to stay close, as well as for the engine and the DB
> server to stay close.
It is not the case that the security server per se need be close to
the UI (I'm still unclear on the tr
> It is unclear that the security server and the engine need to be on
> the same machine; so long as the security server is associated with
> the datastore, it should suffice. E.g., if you don't have access to
> data, you wont be able to retreive it from the datastore in the first
> place. From
On Wed, Dec 27, 2000 at 10:13:58AM -0500, Derek Atkins wrote:
> It is unclear that the security server and the engine need to be on
> the same machine; so long as the security server is associated with
> the datastore, it should suffice. E.g., if you don't have access to
> data, you wont be able
It is unclear that the security server and the engine need to be on
the same machine; so long as the security server is associated with
the datastore, it should suffice. E.g., if you don't have access to
data, you wont be able to retreive it from the datastore in the first
place. From a security
Derek Atkins writes:
> David Merrill <[EMAIL PROTECTED]> writes:
> > From *my* perspective (me, the database, that is), it is all based on
> > the user_name under which you are logged on. The database doesn't know
> > anything else on which it can base things. So the calling layer has to
> > trans
36 matches
Mail list logo
