Arnulf Wiedemann wrote:
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.
IIRC, UNO remote bridge protocols are found by library name. That is,
if you have a protocol named xyz (and corresponding accept strings/UNO
URLs would be of the form "...;xyz..." instead of the familiar
"...;urp..."), its implementation would be in in a dynamic library
called libxyz_uno.so (on Unix), similar to the existing liburp_uno.so.
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.
Your client will only work if it connects to an OOo where the URP bridge
endpoint has been modified to understand your extensions. As long as
you keep those modifications private, whether you reuse the name "urp"
is rather irrelevant. However, once you distribute your modified OOo
URP bridge endpoint implementation, you will cause confusion, as it will
be unclear wether or not a given bridge endpoint named "urp" understands
your extensions. (And then, it could well happen that an URP endpoint
implementation is accidentally confronted with your extensions, namely
if your client tries to talk to an arbitrary OOo instance.)
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]
