Alexandre Benson Smith wrote:

>Windows has "at" and even a GUI front end for it, I have used it a few
>times, it's 3rd party, but part of OS. I agree with you that if FB
>relies on it's own is better then rely on 3rd party, my question is "Is
>it top priority ?"
>
>

There may be two services in the same ecological niche, but the fact
remains that they have different semantics, different interfaces,
different administration policies, and use command files that are 100%
incompatible. If we're going to support a services, it should be
consistent across all platforms, if for no other reason than to preserve
Helen's good nature.

>I could say the same for the encription of the wire protocol. Will be
>good to have it internally, transparent and the user even don't know how
>it works ? I will answer YES, but we could have it working now without
>much effort with ZeBeDee.
>
>

ZeBeDee may be a work around, but I don't see it has a viable long term
solution. In specific, I don't think it's reasonable to require anyone
who needs a reasonably secure protocol to acquire, install, learn,
administer, and use a third party product, even if the third party
product is free. And ease of use considerations aside, I suspect a
significant number of potential Firebird users will choke at the idea of
installing an unknown security package. I'm less paranoid than many,
but I don't want it on my systems.

Another consideration is that we may want the remote protocol to encrypt
only the password exchange, not data records, something that we couldn't
do with ZeBeDee.

>
>
>>> I doubt we will ever have a SQL command to do backups. But a procedure
>>>that could invoke a library function is a different question.
>>>
>>>
>>>
>>>
>In a completely diferent environment than the current UDF's right ?
>
>

The existing UDF mechanism doesn't export the information required to do
a backup. I have a backup mechanism based on serialized Java object
streams, but I don't think Firebird is ready to even consider that yet.

>
>
>>
>>
>>So the first task to have a internal scheduler, is to have a decent
>>internal language right ?
>>
>>

No, a scheduler could be implemented with existing procedures. When the
procedure mechanism is extended the external language processors, the
scheduler would just become more useful.

>>Just a pit that the first internal language was not Object Pascal, I am
>>far more familiar with it than with Java, but maybe this is just the
>>push I need to learn Java (that I started and stoped 2 times)
>>
>>
>>
>>

Java was designed from the ground up to be an embedded language running
in a well defined sandbox. I expect that other people will implement
other external language processors using a well defined interface, but
if it were my database (which it isn't) I would say that Java is
sufficient and leave it at that.