Am Montag, 13. Juni 2005 11:29 schrieb Stephan Bergmann:
>
> You should not call that protocol URP then. Even if you manage to
> extend the existing binary UNO URP endpoint implementation to implement
> your new protocol, other URP endpoint implementations (e.g., the Java
> version) will not understand the new protocol.
>
> Also, I am not sure whether your text-based protocol will be that much
> simpler to implement in a given language than the current binary
> protocol. For example, if you want to stay relatively close to URP in
> your new protocol (which I assume you want to do, as you want to reuse
> the existing binary UNO URP endpoint implementation), you have to
> implement URP's object lifecycle model; that is, you have to send and
> receive release messages in addition to any "true" messages.
>
> -Stephan
>
> > Cheers,
> > Arnulf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
Hello Stephan,
I have renamed the topic to avoid confusion.
I am willing to use a different name, but I don't kow how to integrate a new
protocol.
The advantage of using urp for me is, that I don't have to handle all the
MutexLlocking and Thread stuff myself, which I do not understand completly up
to now. In principle I just use different marshaling and unmarshaling if the
magic is set, filling the same structures as the existing unmarshaling
functions, marshalling fills a dynamic string array which is sent from
Marshal::finish() instead of the binary message.
The protocol remains transparent if you don't send the new "magic" , because
the magic is given as a parameter also to the reply part (callling
pMultiJob->initiate). I am only handling synchronous messages at the moment.
Other URP endpoint implementations will not see anything of the new protocol,
if they do not send the magic.
What I am looking for is something similar like a soap webservice based on a
text-based protocol.
Just an example of the protocol I have implemented (a query interface
request). The conversion from the TYPE_CLASS strings to the enum value is at
the moment hard-wired but could also be done using the registry service based
on the types.rdb.
sending:
ffffffff0x025e 0x0001 {{HDRFLAG_LONGHEADER 1} {HDRFLAG_NEWTID 1}
{HDRFLAG_REQUEST 1} {HDRFLAG_NEWTYPE 1} {HDRFLAG_NEWOID 1}
{HDRFLAG_IGNORECACHE 0} {HDRFLAG_MOREFLAGS 0} {HDRFLAG_SYNCHRONOUS 0}
{HDRFLAG_MUSTREPLY 0} {HDRFLAG_LONGMETHODID 0} {HDRFLAG_EXCEPTION 0}
{METHOD_ID 0}}
{TYPE_CLASS INTERFACE NEW}
{TYPE_CACHE_INDEX 0}
{CLASS_NAME com.sun.star.uno.XInterface}
{OBJECT_ID StarOffice.ComponentContext}
{OBJECT_ID_CACHE_INDEX 0}
{THREAD_ID_SIZE 20}
{THREAD_ID {0x01 0x00 0x00 0x00 0xa2 0x1e 0x8f 0xe4 0xda 0x4c 0x11 0xd9 0xac
0x27 0x97 0x55 0x77 0x41 0x14 0xe3}}
{THREAD_INDEX 0}
{TYPE_CLASS INTERFACE}
{TYPE_CACHE_INDEX 0}
got reply:
ffffffff 0x0243 0x0001 {{HDRFLAG_LONGHEADER 1} {HDRFLAG_NEWTID 1}
{HDRFLAG_REQUEST 0} {HDRFLAG_NEWTYPE 0} {HDRFLAG_NEWOID 0}
{HDRFLAG_IGNORECACHE 0} {HDRFLAG_MOREFLAGS 0} {HDRFLAG_SYNCHRONOUS 0}
{HDRFLAG_MUSTREPLY 1} {HDRFLAG_LONGMETHODID 0} {HDRFLAG_EXCEPTION 0}}
{THREAD_ID_SIZE 20}
{THREAD_ID {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00}}
{THREAD_CACHE_INDEX 0}
{TYPE_CLASS INTERFACE}
{TYPE_CACHE_INDEX 0x0000}
{CLASS_NAME com.sun.star.uno.XInterface}
{VALUE 4102d8d8;gcc3[0];139a8b72dcb511d9aa8fc667f19897e2}
{OBJECT_ID_CACHE_INDEX 0x0000}
The needed code to produce such input using TCL is:
proc makeLongHeader {new_tid new_type new_oid method_id} {
set headers [list]
lappend headers [list HDRFLAG_LONGHEADER 1]
lappend headers [list HDRFLAG_NEWTID $new_tid]
lappend headers [list HDRFLAG_REQUEST 1]
lappend headers [list HDRFLAG_NEWTYPE $new_type]
lappend headers [list HDRFLAG_NEWOID $new_oid]
lappend headers [list HDRFLAG_IGNORECACHE 0]
lappend headers [list HDRFLAG_MOREFLAGS 0]
lappend headers [list HDRFLAG_SYNCHRONOUS 0]
lappend headers [list HDRFLAG_MUSTREPLY 0]
lappend headers [list HDRFLAG_LONGMETHODID 0]
lappend headers [list HDRFLAG_EXCEPTION 0]
lappend headers [list METHOD_ID $method_id]
set headers [list $headers]
return $headers
}
set sf [socket localhost 2002]
set headers [makeLongHeader 1 1 1 0]
set type_class [list TYPE_CLASS INTERFACE NEW]
set cache_index [list TYPE_CACHE_INDEX 0]
set class_name [list CLASS_NAME com.sun.star.uno.XInterface]
set oid [list OBJECT_ID StarOffice.ComponentContext]
set cache_index2 [list OBJECT_ID_CACHE_INDEX 0]
set tid [list THREAD_ID_SIZE 20]
set tid_info [list THREAD_ID [list 0x01 0x00 0x00 0x00 0xa2 0x1e 0x8f 0xe4 0
xda 0x4c 0x11 0xd9 0xac 0x27 0x97 0x55 0x77 0x41 0x14 0xe3]]
set tid_index [list THREAD_INDEX 0]
set type_class2 [list TYPE_CLASS INTERFACE]
set cache_index3 [list TYPE_CACHE_INDEX 0]
set cmd " $headers $type_class $cache_index $class_name $oid $cache_index2
$tid $tid_info $tid_index $type_class2 $cache_index3"
set lgth [format "0x%04x" [string length $cmd]]
set message_id [format "0x%04x" 1]
set cmd "ffffffff$lgth $message_id$cmd "
puts stderr "sending:$cmd"
puts -nonewline $sf $cmd
flush $sf
gets $sf line
puts stderr "got reply:$line:"
close $sf
Of course one can build better library functions in TCL to produce easy
interfaces for the user of such an interface.
I did not yet think about the lifecycle model yet.
Cheers,
Arnulf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
