Hi Norman,

Am Donnerstag, den 12.10.2006, 14:49 +0200 schrieb Norman Maurer:

> > They do belong to the implementation but could be shared by different
> > backends. The goal is message number stability which is needed by Imap,
> > Pop3 and JavaMail. That means that the message number have to be stable
> > even when a message gets deleted. Renumbering is allowed only when the
> > client could be notified
> > And that should work on a backend that is accessed by different hosts.
> > The service has to react to what it finds on the DB.
> > To be able to deliver the required events it has to keep track of what
> > the client is aware and cache the known message uids. This is done in
> > the tracker package. 

> How is this notify workin ? what for clients can use such notifys ?

IMAP clients. :-) After specific commands you can send unsolicited
responses. Sending expunge notifications does take effect on the message
numbers.
If there were messages added you can tell the new message count.
If there are flags changed you send unsolicited "fetch" responses. All
that happens asynchronous. The events are queued until the protocol
allows sending them.
The idea is that IMAP clients send a "NOOP" when it's idle. By
evaluating the events it is always up-to-date without doing periodic
requests. Well, the "NOOP" is indeed a periodic request. ;-)

In JavaMail store nearly every operation requires an appropriate event
which is send at once.

> > Unfortunately I noticed that derby support is only alpha in Torque 3.2.
> > One problem that exists that a db generated key can't be fetched. Maybe
> > we could use a custom build until 3.2.1 is out.

> Is it working better in torgue snapshot or still alpha ?

I did not test it but getting auto generated keys at insert should work
now. It's like in James. RC or trunk is sometimes even better then last
stable release. :-) 

Quote Thomas Fischer @torque-user:
"Derby support was still in the alpha stage when 3.2 was released. In
the meantime, I believe it is fully working in svn. I'd recommend a svn
pull of the sources from svn trunk and a custom build. As far as I know,
there are no large issues open at the moment which have not been in 3.2
also."

Some ideas I have in mind work only with getting the db generated key.
So I think we need a custom build then.

Joachim




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to