Jim Starkey wrote:

>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 think encrypt everything (if the traffic goes on public network) to be
a goo thing.

I don't have numbers, but with ZeBeDee we could have it installed in a
separe box so the CPU of the FB machine don't get used by
encription/compression tasks

>>
>>
>>
>>
>>>>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.
>
>
>

And any task that has long processing time is no good candidate for
UDF's right ?

>>
>>
>>
>>
>>>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.
>
>
>

Ok, but the initial proposal talk about back-ups and other
administrative tasks take could not be done in the first stage.

I am not against it (I said it before)

>>>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.
>
>
>
>

I agree that Java is strong enough to handle the majority (if not all)
the tasks needed... My complain (with myself) is that I don't know Java. :-)

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br