|
|
|
| Re: DBGp Debug Commands and Encoding. [message #4437 is a reply to message #4299] |
Fri, 18 May 2007 13:29   |
 Dmitriy Kovalev
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Hi Dave,
Thank you for your comments, I think your interpretation of 'encoding'
is right and acceptable. We will implement this scheme for ruby in the
nearest future. UTF-8 is the best choice because it's a superset of
ASCII and encodes unicode symbols.
But there is one small problem: first "init" command from debugging
engine (before feature negotiation) should be sent in the predefined
encoding. "init" xml request has only one problem attribute "fileuri"
and we should decide what to do with it.
Dave Kelsey wrote:
> Hi Dmitriy,
> I have considered interpreting the feature "encoding" as follows.
> 1. as the encoding to be used for the XML response (encoding is
> a feature that can be set).
> 2. as the encoding for commands.
>
> With 2, the encoding must be a superset of the ASCII codeset, to allow
> for programs which have compiled the commands into their code as ascii
> bytes (which is not unreasonable).
>
> What do you think ?
>
> Dave Kelsey
>
> Dmitriy Kovalev wrote:
>> Hello Dave,
>> Of course commands in ASCII encoding are the source of problems. We
>> understand it and thinking about good general solution for script
>> languages. Unfortunately DBGp specification doesn't give clear
>> understanding of usage the 'encoding' feature. I think the problem
>> only in commands from IDE to debugging engine because xml response
>> already has encoding in the header "<?xml version="1.0"
>> encoding="UTF-8"?>". So our possible solution is usage of 'encoding'
>> feature only for commands for IDE commands. For now we doesn't check
>> this feature and send commands in plain ASCII encoding.
>>
>> Dmitriy Kovalev
>>
>>
>> Dave Kelsey wrote:
>>> Reading the DBGp specification, I see it states commands should be
>>> sent as ASCII. However that
>>> I think poses a problem. A command may be in ASCII and filenames
>>> converted to a URI is convertable
>>> to ASCII, but what about other inserts such as variable names and
>>> method names that may not
>>> be in ascii format ? Especially with Java which works with strings, a
>>> conversion to ASCII would fail if it contained
>>> codepoints that cannot be represented in ASCII.
>>>
>>> I also see in the DBGp specification reference to a feature called
>>> encoding which defines the debug session
>>> encoding. This could imply to me that the commands could be sent in
>>> this encoding and the xml returned
>>> will be in this encoding, but is not well defined in the documentation.
>>>
>>> I was wondering how DLTK handles the issue of commands which could
>>> contain non ASCII representable information ?
>>>
>>> Dave Kelsey
|
|
|
| Re: DBGp Debug Commands and Encoding. [message #4507 is a reply to message #4437] |
Fri, 18 May 2007 14:01 |
D Kelsey
Messages: 232
Registered: July 2009 |
Senior Member |
|
|
Hi Dmitriy,
I don't think init is a problem.
As it is XML, it will have an encoding (so an engine may want to use UTF-8
as a default encoding anyway), but I think ascii would also work. A fileuri
comprises of ASCII characters. when a file is converted to a URI, it encodes
non ascii characters to escaped UTF-8 values.
Dave Kelsey
Dmitriy Kovalev wrote:
> Hi Dave,
> Thank you for your comments, I think your interpretation of 'encoding'
> is right and acceptable. We will implement this scheme for ruby in the
> nearest future. UTF-8 is the best choice because it's a superset of
> ASCII and encodes unicode symbols.
> But there is one small problem: first "init" command from debugging
> engine (before feature negotiation) should be sent in the predefined
> encoding. "init" xml request has only one problem attribute "fileuri"
> and we should decide what to do with it.
>
> Dave Kelsey wrote:
>> Hi Dmitriy,
>> I have considered interpreting the feature "encoding" as follows.
>> 1. as the encoding to be used for the XML response (encoding is
>> a feature that can be set).
>> 2. as the encoding for commands.
>>
>> With 2, the encoding must be a superset of the ASCII codeset, to allow
>> for programs which have compiled the commands into their code as ascii
>> bytes (which is not unreasonable).
>>
>> What do you think ?
>>
>> Dave Kelsey
>>
>> Dmitriy Kovalev wrote:
>>> Hello Dave,
>>> Of course commands in ASCII encoding are the source of problems. We
>>> understand it and thinking about good general solution for script
>>> languages. Unfortunately DBGp specification doesn't give clear
>>> understanding of usage the 'encoding' feature. I think the problem
>>> only in commands from IDE to debugging engine because xml response
>>> already has encoding in the header "<?xml version="1.0"
>>> encoding="UTF-8"?>". So our possible solution is usage of 'encoding'
>>> feature only for commands for IDE commands. For now we doesn't check
>>> this feature and send commands in plain ASCII encoding.
>>>
>>> Dmitriy Kovalev
>>>
>>>
>>> Dave Kelsey wrote:
>>>> Reading the DBGp specification, I see it states commands should be
>>>> sent as ASCII. However that
>>>> I think poses a problem. A command may be in ASCII and filenames
>>>> converted to a URI is convertable
>>>> to ASCII, but what about other inserts such as variable names and
>>>> method names that may not
>>>> be in ascii format ? Especially with Java which works with strings,
>>>> a conversion to ASCII would fail if it contained
>>>> codepoints that cannot be represented in ASCII.
>>>>
>>>> I also see in the DBGp specification reference to a feature called
>>>> encoding which defines the debug session
>>>> encoding. This could imply to me that the commands could be sent in
>>>> this encoding and the xml returned
>>>> will be in this encoding, but is not well defined in the documentation.
>>>>
>>>> I was wondering how DLTK handles the issue of commands which could
>>>> contain non ASCII representable information ?
>>>>
>>>> Dave Kelsey
|
|
|
Powered by
FUDForum. Page generated in 0.03872 seconds
] 
Search
Help
Register
Login
Home
