Hello,

The simple json protocol does not satisfy all needs.
Only simple data types, sequences and collections are supported.
There is not even a native Date type.
It would also be nice to include application specific object constructors.

Here my ideas on that subject.
The simple notation is extended to include an object library.
This library consists functions objects or named objects/constant.

For example:
{"birthDate" : sys.ISODate("19761210:T13:55:00"),
  "name" : "Jan-Klaas Kollhof"
  "sex" : MALE}

Each json impl must provide a core library object. This is the sys lib.
Applications must be able to add objects to the JSON parser.
The JSON-RPC impl. would for example add a lib called "rpc" which
provides the core JSON-RPC constructor functions for Error, Request
and Response objects.

Example:

rpc.Request("someID", "registerUser", ["jan", "password"])
rpc.Response("someID", null, WrongPassword())

rpc is the lib defined by the JSON-RPC protocoll.
WrongPassword is an application specific object(constructor).

rpc.Request("someId", "getTime", [])
rpc.Response("someId", sys.ISODate("20040404T12:44:44"), null)

This is just a request to get the time which results in a reponse with
  the current time using the core lib's Date constructor.


The extension would allow a more flexible way to work with JSON-RPC.


Jan

Hey there, ...

   JSON-RPC sounds like a great idea, I have played around with it a
bit ever since I saw notes about it in the DomAPI forum.
   Here is a site that might get you ideas to your JSON-RPC specs and
interface:

   DomAPI DHTML Platform

   - http://www.domapi.com/tutor_topic.cfm?topicid=33
    (RPC Interface suggestions)

   - http://www.domapi.com/forum_index.cfm
    (DomAPI Forum , type in JSON and RPC in the Keywords textbox)


   Gaston Jeremy   gastonjy@...

Hi,

I've continued the work on my JSON-RPC-Java implementation
and have been adding some basic ORB funcationality.

     * References - Objects of classes registered as References
       will be returned as opaque reference objects to JavaScript
       that when passed to succussive Java method calls will then
       be reassociated back to the original Java object (great for
       security sensitive objects).
     * Callable References - Object of classes registered as
       Callable References will return dynamic proxies to allow
       invocation on the particular object instance in the
       server-side Java.

There are 2 API calls used from Java to register Java classes
as either References or Callable References.

JSONRPCBridge.registerReference(Test.RefTest.class);
JSONRPCBridge.registerCallableReference(Test.CallableRefTest.class);

I have made some changes to the jsolait json-rpc client for dynamic
proxy creation support needed for Callable References.

I believe I could possibly use Jan-Klaas's suggested enhancements
for sys. method calls during unmarshalling. Although for my purpose,
I need to be able to substitue the top level object returned from
a method call that returns a Callable Reference.

I have some example code that demos my implementation of References
and Callable References here: Click on 'Reference Tests'

    http://oss.metaparadigm.com/jsonrpc/test.jsp
    http://oss.metaparadigm.com/jsonrpc/Test.java.txt
    http://oss.metaparadigm.com/jsonrpc/test.js.txt

The support for Callable References is completely transparent on
the Javascript side. You call a method that returns an object
that is registered as a Callable Reference on the Java side, and
the resulting method will return an object in the JavaScript client
that will dynamically create a new ServerProxy that makes invocations
on that specific object instance in the server.

Presently I have made two changes to jsolait to support this:

1. Add an 'objectID' attribute to the method invocation protocol
to support invocations on these unamed objects. It is only
needed on requests to unamed objects that have been returned as
Callable References. Only ServerProxy's instantiated as the
result of these calls will have an objectID field.

2. Add recognition of 'JSONRPCType' and 'objectID' attributes
on returned toplevel objects.

My 2 new objects look like this:

{"result": {"javaClass":"com.metaparadigm.test.Bar",
              "objectID":4827452,
              "JSONRPCType":"CallableReference"} }

{"result": {"javaClass":"com.metaparadigm.test.Foo",
              "objectID":5535614,
              "JSONRPCType":"Reference"} }

They Reference is completely opaque to the Javascript JSON-RPC client
and the CallableReference is recoginised when a toplevel object
in returned values by the existence of the 'JSONRPCType' field with
a value of "CallableReference", a new ServerProxy is instantiated
to make invocations on the specific instance. If the objectID attribute
is present on a call to system.listMethods, the methods of the
specific instance are returned rather than the global methods of
named objects.

So some of the questions I have are regards possible additions
to the JSON-RPC specification. Particularily language specific
features that I have added such as the 'javaClass' attribute
which is part of my 'Class hinting' feature.

So I propose the following additions in the following areas
(which I can document if we agree it's a good idea)

1.
A language specific attrbiute 'javaClass' that hints the loosely
typed JavaScript object to allow specific mappings to a Java Class
(especially needed for unmarshalling of objects in generic
container classes).

2.
'JSONRPCType' field that when present in conjunction with an 'objectID'
field contains a value of either "Reference" or "CallableReference" type.
I am still wondering whether a CallableReference should instead be
called a CallableProxy as in my present implementation it can only be
called and not passed as a reference ?? Any thoughts?

3.
An 'objectID' field that is present in conjunction with the 'JSONRPCType'
field that contains an opaque Integer or String key that uniquely
identifies that object in the remote end.

4.
An 'objectID' field in the method invocation request that
when present contains an opaque Integer or String value that
specifies the invocation on on a specific instance of an object
rather than methods exported in the global namespace.

I will soon add support for Jan-Klaas sys. style marshalling to
allow marshalling of Date types (which I currently don't support).

Just thinking about an alternate implementation to my above
recommendation would be to return a sys.createProxy as the
toplevel object for Callable References (jsolait jsonrpc would
need to be taught how to do this). This is perhaps a better way.
I would still need mostly additions to formalise recognition of
the Reference type.

So it would look like this.

{"result": sys.createProxy{"javaClass":"com.metaparadigm.test.Bar",
                             "objectID":4827452,
                             "JSONRPCType":"CallableProxy"} }

Michael.

Hi,

> I believe I could possibly use Jan-Klaas's suggested enhancements
> for sys. method calls during unmarshalling. Although for my purpose,
> I need to be able to substitue the top level object returned from
> a method call that returns a Callable Reference.
> {"result": {"javaClass":"com.metaparadigm.test.Bar",
>              "objectID":4827452,
>              "JSONRPCType":"CallableReference"} }
>
> {"result": {"javaClass":"com.metaparadigm.test.Foo",
>              "objectID":5535614,
>              "JSONRPCType":"Reference"} }
>

Here is how I would do the proxy objects:
Exampe:
rpc.Request("id", "getSomeObj", [])

rpc.Response("id", rpc.ProxyObj("objID", ["method1", "methodName2",
...]), null)

To then call methods of that object a request might look like this:
rpc.Request("id", "proxies.objID.method1", [1,2,3])

To pass object refs one could do the following:
rpc.Request("id", "getSomeOtherObj", [])

the response using application specific classes:
rpc.Response("id", SomeAppSpecificClass("someObjSpecificInfo", "maybe
  even an id"), null)

or to make it part of the rpc protocol:
rpc.Response("id", rpc.ObjectRef("objID"), null)

to pass the object back one would simply use it as a parameter:

rpc.Request("id", "someMethod", [SomeAppSpecificClass(...)])
or
rpc.Request("id", "someMethod", [rpc.RefedObject("objID")])


> So some of the questions I have are regards possible additions
> to the JSON-RPC specification. Particularily language specific
> features that I have added such as the 'javaClass' attribute
> which is part of my 'Class hinting' feature.

I don't think there should be anything language specific in the protocol.

The service should be able to register handlers(libs/methods):
jsut an example:
jh = new JsonHandler()
jh.addClass("ClassName", constructorFunctionForClass)
jh.addLib("libName", libObj, ["exportedClass", "expClass2"])

service = ServiceProxy("jsonrpc://someserver:9999", ["remoteMethod1"], jh)

both peers would register the classes and libs.
The sys and rpc libs are automatically registered by json and json-rpc.

This way the impl is independent of the protocol.
say you want to pass some Object of the class MyClass(String name,
Date someDate)

the request would look like this:
rpc.Request("id", "someMethod", [MyClass("jan", sys.ISODate("19761210")])

Now, each peer will handle MyClass by invoking the method
that was registered for "MyClass". That may be a method called
createMyClassObject(String name, Date date), a class called MyClass
or maybe even mypackage.somesubpackage.SomeClass or ...
The point is that only the interface for the constructors has to be
the same. The impl can be completely different.

This allows the protocol to stay simple yet be powerful.


> 1.
> A language specific attrbiute 'javaClass' that hints the loosely
> typed JavaScript object to allow specific mappings to a Java Class
> (especially needed for unmarshalling of objects in generic
> container classes).

I guess that would not be needed when using my proposal.
In Java MyClass may be mapped to myPackage.MyClass or
myPackage.rpcConstructors.createMyClass
and in JS MyClass might for example use a createMyClass function.

> 2.
> 'JSONRPCType' field that when present in conjunction with an 'objectID'
> field contains a value of either "Reference" or "CallableReference"
type.

That should then be part of the "rpc" lib as described above.


> 3.
> An 'objectID' field that is present in conjunction with the
'JSONRPCType'
> field that contains an opaque Integer or String key that uniquely
> identifies that object in the remote end.

Same as 2.


> 4.
> An 'objectID' field in the method invocation request that
> when present contains an opaque Integer or String value that
> specifies the invocation on on a specific instance of an object
> rather than methods exported in the global namespace.

The protocol does not state how to interpret the methoName field.
I think I should change the name to reflect that a bit better

Here the Request in BNF:
request ::= "rpc.Request(" reqID "," object_identifier "," params ")"

object_identifier is preferably a string containing the name of the
method to invoke "someMethod" or  "someObj.someMethod".
but it does not have to.
Maybe the specs should define what is allowed and what is not.
Maybe one should/could only use constructs like:
"someobj.someMethod"
for simple method invokation on the service.
and "[objId].someObj.someMethod"
for ProxyObjects.


> I will soon add support for Jan-Klaas sys. style marshalling to
> allow marshalling of Date types (which I currently don't support).

I will have to add some more things to "sys":
All json specific things like errors for example and maybe a Base64
constructor.
sys should not include any rpc related things.

for the "rpc" lib I am thinking:
the RPC errors like MethodNotFound, BadParams, ObjectNotFound, ...
and the Request, Response, Notification cconstructors.

Another point is introspection.
I don't like the system.listMethod too much.
But I have not come up with anything else.


I have a couple concerns about object refferences:
It would be possible to impl them with JSON-RPC natively supporting it
or not.
But what happens to the objects if they should be destroyed?
How is referencing and dereferencing handled.


The main focus for JSON-RPC will probably be on simple method
invocation between peers. Parameters and return values can be either
objects of simple datatypes or objects of application specific classes.
This is still simple to implement and is more powerful and flexible
than XML-RPC. :)

Passing/returning ProxyObjects or ObjectRefferences does not seem to
make the protocol more difficult either.


I have worked on the JavaScript and python impl as described above.
It is working nicely. What is missing is a complete sys lib and
the Errors in the rpc lib.

I am also working on the specs to reflect the new ideas.
I am sorry that the specs change so much. Well, it's still a draft. :)

The main changes are now that the req., resp. and notif. become

rpc.Request("id", "methodName", [param1, ...])
rpc.Notification("methodName", [param1, ...])
rpc.Rsponse("id", resultObj, errorObj)



Jan

On 04/05/04 17:03, Jan-Klaas Kollhof wrote:
> Hi,
>
>
>>I believe I could possibly use Jan-Klaas's suggested enhancements
>>for sys. method calls during unmarshalling. Although for my purpose,
>>I need to be able to substitue the top level object returned from
>>a method call that returns a Callable Reference.
>>{"result": {"javaClass":"com.metaparadigm.test.Bar",
>>             "objectID":4827452,
>>             "JSONRPCType":"CallableReference"} }
>>
>>{"result": {"javaClass":"com.metaparadigm.test.Foo",
>>             "objectID":5535614,
>>             "JSONRPCType":"Reference"} }
>>
>
>
> Here is how I would do the proxy objects:
> Exampe:
> rpc.Request("id", "getSomeObj", [])
>
> rpc.Response("id", rpc.ProxyObj("objID", ["method1", "methodName2",
> ...]), null)

I liked this idea originally but have been thinking about it.

My problem is this: JSON is a standard and this embedded
procedure call within a JSON object breaks the JSON notation
and then we have a pseudo something between JSON and real
Javascript with slightly different rules.

I believe to stay JSON compatible, we would need to be able
to describe this functionality by building up objects from
JSON building blocks that have a specific meaning in JSON-RPC.

Possbily a way to to this is to specify an JSON object format
for specifing that a call needs to be made to transform the
object in question or simple specifications of types.

instead of:

    sys.ISODate("19761210") which is not JSON

perhaps:

    { JSONRPCType: "ISODate", ISODate: "1976-12-10" }

I think this is a little simpler and is also JSON compatible.
Also the hyphens are used if we are specifying the date to be in
ISO-8601 format.

Perhaps then we would just specify these JSON-RPC specific
types built upon the base JSON constructs.

ie.

    { JSONRPCType: "ISODate", ISODate: "1976-12-10" }

    { JSONRPCType: "Reference", objectID: "9f31ab87" }

    { JSONRPCType: "Proxy", objectID: "9d9ef3a6" }

I believe staying JSON compatible should be a goal, no?

Michael.

> To then call methods of that object a request might look like this:
> rpc.Request("id", "proxies.objID.method1", [1,2,3])
>
> To pass object refs one could do the following:
> rpc.Request("id", "getSomeOtherObj", [])
>
> the response using application specific classes:
> rpc.Response("id", SomeAppSpecificClass("someObjSpecificInfo", "maybe
>  even an id"), null)
>
> or to make it part of the rpc protocol:
> rpc.Response("id", rpc.ObjectRef("objID"), null)
>
> to pass the object back one would simply use it as a parameter:
>
> rpc.Request("id", "someMethod", [SomeAppSpecificClass(...)])
> or
> rpc.Request("id", "someMethod", [rpc.RefedObject("objID")])
>
>
>
>>So some of the questions I have are regards possible additions
>>to the JSON-RPC specification. Particularily language specific
>>features that I have added such as the 'javaClass' attribute
>>which is part of my 'Class hinting' feature.
>
>
> I don't think there should be anything language specific in the protocol.
>
> The service should be able to register handlers(libs/methods):
> jsut an example:
> jh = new JsonHandler()
> jh.addClass("ClassName", constructorFunctionForClass)
> jh.addLib("libName", libObj, ["exportedClass", "expClass2"])
>
> service = ServiceProxy("jsonrpc://someserver:9999", ["remoteMethod1"], jh)
>
> both peers would register the classes and libs.
> The sys and rpc libs are automatically registered by json and json-rpc.
>
> This way the impl is independent of the protocol.
> say you want to pass some Object of the class MyClass(String name,
> Date someDate)
>
> the request would look like this:
> rpc.Request("id", "someMethod", [MyClass("jan", sys.ISODate("19761210")])
>
> Now, each peer will handle MyClass by invoking the method
> that was registered for "MyClass". That may be a method called
> createMyClassObject(String name, Date date), a class called MyClass
> or maybe even mypackage.somesubpackage.SomeClass or ...
> The point is that only the interface for the constructors has to be
> the same. The impl can be completely different.
>
> This allows the protocol to stay simple yet be powerful.
>
>
>
>>1.
>>A language specific attrbiute 'javaClass' that hints the loosely
>>typed JavaScript object to allow specific mappings to a Java Class
>>(especially needed for unmarshalling of objects in generic
>>container classes).
>
>
> I guess that would not be needed when using my proposal.
> In Java MyClass may be mapped to myPackage.MyClass or
> myPackage.rpcConstructors.createMyClass
> and in JS MyClass might for example use a createMyClass function.
>
>
>>2.
>>'JSONRPCType' field that when present in conjunction with an 'objectID'
>>field contains a value of either "Reference" or "CallableReference"
>
> type.
>
> That should then be part of the "rpc" lib as described above.
>
>
>
>>3.
>>An 'objectID' field that is present in conjunction with the
>
> 'JSONRPCType'
>
>>field that contains an opaque Integer or String key that uniquely
>>identifies that object in the remote end.
>
>
> Same as 2.
>
>
>
>>4.
>>An 'objectID' field in the method invocation request that
>>when present contains an opaque Integer or String value that
>>specifies the invocation on on a specific instance of an object
>>rather than methods exported in the global namespace.
>
>
> The protocol does not state how to interpret the methoName field.
> I think I should change the name to reflect that a bit better
>
> Here the Request in BNF:
> request ::= "rpc.Request(" reqID "," object_identifier "," params ")"
>
> object_identifier is preferably a string containing the name of the
> method to invoke "someMethod" or  "someObj.someMethod".
> but it does not have to.
> Maybe the specs should define what is allowed and what is not.
> Maybe one should/could only use constructs like:
> "someobj.someMethod"
> for simple method invokation on the service.
> and "[objId].someObj.someMethod"
> for ProxyObjects.
>
>
>
>>I will soon add support for Jan-Klaas sys. style marshalling to
>>allow marshalling of Date types (which I currently don't support).
>
>
> I will have to add some more things to "sys":
> All json specific things like errors for example and maybe a Base64
> constructor.
> sys should not include any rpc related things.
>
> for the "rpc" lib I am thinking:
> the RPC errors like MethodNotFound, BadParams, ObjectNotFound, ...
> and the Request, Response, Notification cconstructors.
>
> Another point is introspection.
> I don't like the system.listMethod too much.
> But I have not come up with anything else.
>
>
> I have a couple concerns about object refferences:
> It would be possible to impl them with JSON-RPC natively supporting it
> or not.
> But what happens to the objects if they should be destroyed?
> How is referencing and dereferencing handled.
>
>
> The main focus for JSON-RPC will probably be on simple method
> invocation between peers. Parameters and return values can be either
> objects of simple datatypes or objects of application specific classes.
> This is still simple to implement and is more powerful and flexible
> than XML-RPC. :)
>
> Passing/returning ProxyObjects or ObjectRefferences does not seem to
> make the protocol more difficult either.
>
>
> I have worked on the JavaScript and python impl as described above.
> It is working nicely. What is missing is a complete sys lib and
> the Errors in the rpc lib.
>
> I am also working on the specs to reflect the new ideas.
> I am sorry that the specs change so much. Well, it's still a draft. :)
>
> The main changes are now that the req., resp. and notif. become
>
> rpc.Request("id", "methodName", [param1, ...])
> rpc.Notification("methodName", [param1, ...])
> rpc.Rsponse("id", resultObj, errorObj)
>
>
>
> Jan
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

--
Michael Clark,  . . . . . . . . . . . .  michael@...
Managing Director,  . . . . . . . . . http://www.metaparadigm.com
Metaparadigm Pte. Ltd.  . . . . . . . . . .  phone: +65 6395 6277
25F Paterson Road,  . . . . . . . . . . . . mobile: +65 9645 9612
Singapore 238515  . . . . . . . . . . . . . .  fax: +65 6234 4043

On 04/07/04 11:31, Michael Clark wrote:
> I believe to stay JSON compatible, we would need to be able
> to describe this functionality by building up objects from
> JSON building blocks that have a specific meaning in JSON-RPC.
>
> Possbily a way to to this is to specify an JSON object format
> for specifing that a call needs to be made to transform the
> object in question or simple specifications of types.
>
> instead of:
>
>   sys.ISODate("19761210") which is not JSON
>
> perhaps:
>
>   { JSONRPCType: "ISODate", ISODate: "1976-12-10" }
>
> I think this is a little simpler and is also JSON compatible.
> Also the hyphens are used if we are specifying the date to be in
> ISO-8601 format.
>
> Perhaps then we would just specify these JSON-RPC specific
> types built upon the base JSON constructs.
>
> ie.
>
>   { JSONRPCType: "ISODate", ISODate: "1976-12-10" }
>
>   { JSONRPCType: "Reference", objectID: "9f31ab87" }
>
>   { JSONRPCType: "Proxy", objectID: "9d9ef3a6" }

or more like you had suggested but instead as a plain JSON object

{ JSONRPCType: "Proxy",
    objectID: "9d9ef3a6",
    methods: ["foo", "bar"] }

> I believe staying JSON compatible should be a goal, no?

The other concerns I have with embedding calls within
JSON objects are potential security concerns due to
side-effects and unknown access constraints depending
on the specific language implementation. It may be a
larger can of worms than you think (although idea is
great from a pure JavaScript implementation point of view).

These types of calls will not map too well to early binding
languages such as C and would just end up vastly complicating
the parsing and unmarshalling.

Can we please stick to just using JSON in JSON-RPC, please ;).

~mc

Hi,

OK, I have heard that argument before about the function calls.
I don't think it is very hard to parse though.
But I can see the point and agree with sticking to pure JSON.

To ease object construction I have the following idea:

{"jsonclass": ["ConstructorName", [123,456]], "property1": 789 ...}

creates an object as follows(just to show how the obj would look like):
obj = ConstructorName(123, 456)
obj.property1 = 789

the default JSON would create an object like this:
obj = {}
obj.jsonclass = ["ConstructorName", [123]]
obj.property1 = 789

This approach ensures backwards compatibility to JSON.
It allows constructors to be called with parameters.
And it allows property assignment.

It would pretty much work like the function call plus the property
assignments.

So creating proxy objects should not be difficult.

I am still thinking about changing methodName to something else in the
request. But that's just a naming thing.



Jan

Finally I found some time again to work on JSON-RPC.
I have updated the spec to include class hinting.
This is accomplished by introducing a special property called jsonclass.
This property contains an array made up of the class name and the
parameters to be passed to the constructor:
{jsonclass:["classname", [param1, ... ]], ...}
If such a property is encountered the object will be constructed using
the constructor for the class noted in the classname entry and passing
the parameters to that constructor. After the construction all
optional properties will be set.

There are also a couple minor naming changes.

I have updated the JavaScript impl. and also posted the Python impl
used on the server for download.

Hello,

JSON-RPC was presentedn in two presentations at the SVGOpen 2004 in Tokyo.
It was used to show how client/server communication can be done in SVG
and as part of an SVG presentation tool.

Just to let anyone know JSON-RPC is not dead and I am still working on
new impl. und applications using it.


Jan

Hello,

I'm currently working on PHP implementation of the JSON-RPC
I have designed code for PHP4 and going to start working on PHP5 work.

Will let you know how will it work on real project!

JSON-RPC forever!

Regards,
Dmitry

Hi,


> I'm currently working on PHP implementation of the JSON-RPC
> I have designed code for PHP4 and going to start working on PHP5 work.


Great to hear, another JSON-RPC impl.
This will be the 4th besides Java, JavaScript and python.


> Will let you know how will it work on real project!

Please do.



Jan

Hello list! I am just a json-rpc newbie and I just want to know if
there's any way, I can add custom error messages on json-rpc error
field. I'm currently using json-rpc python library. Thanks!

Joseph Ross Lee

hi,


The python lib is a very rudamentary impl.
There is not a whole lot of room for customization.
Whenever a method of a service is executed and an error occurs
an ApplicationError object is created with the error traceback as the
msg property. This object is returned in the error property of the
response.
The specs do not define what can or cannot be used as an error in the
response object yet. So, you could define your own error objects.


Jan


--- In json-rpc@yahoogroups.com, Joseph Ross Lee <jross@p...> wrote:
> Hello list! I am just a json-rpc newbie and I just want to know if
> there's any way, I can add custom error messages on json-rpc error
> field. I'm currently using json-rpc python library. Thanks!
>
> Joseph Ross Lee

Ah ok. So, there's really no easy way of adding puting error messages
to json error field using python json-rpc lib?
If its possible, how can it be done? Does the python lib have any
documentation?

On 10 6, 04, at 7:58 PM, Jan-Klaas Kollhof wrote:

>
>  hi,
>
>
>  The python lib is a very rudamentary impl.
>  There is not a whole lot of room for customization.
>  Whenever a method of a service is executed and an error occurs
>  an ApplicationError object is created with the error traceback as the
>  msg property. This object is returned in the error property of the
>  response.
>  The specs do not define what can or cannot be used as an error in the
>  response object yet. So, you could define your own error objects.
>
>
>  Jan
>
>
>  --- In json-rpc@yahoogroups.com, Joseph Ross Lee <jross@p...> wrote:
>  > Hello list! I am just a json-rpc newbie and I just want to know if
>  > there's any way, I can add custom error messages on json-rpc error
>  > field. I'm currently using json-rpc python library. Thanks!
>  >
>  > Joseph Ross Lee
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
> <lrec_companion_043004.gif>
> <l.gif>
>
> Yahoo! Groups Links
>
>  •  To visit your group on the web, go to:
> http://groups.yahoo.com/group/json-rpc/
>  
>  • 	 To unsubscribe from this group, send an email to:
> json-rpc-unsubscribe@yahoogroups.com
>  
>  • 	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
Joseph Ross Lee

Hello,


> Ah ok. So, there's really no easy way of adding puting error
messages to json error field using python json-rpc lib?

Depends on how you interpret "easy". :)

You would need to change the python impl.
I made it to actually just test the JavaScript impl. and the
protocoll. To see if it all works as expected.

Right now I don't have the time to work on it a whole lot.
Both the JS and the Py  impl need work though.
The homepage too...



Jan

what's the best json-rpc server available? python?

Joseph Ross Lee

Hi,


That's a good question :).

I know that Dimitri Durach is witing a PHP impl.
and Michael Clark has a Java impl. and then there is my python impl.

I have never compared them in terms of anything.
The python impl. is just there for me to test the protocoll and probably
needs some rewriting and tuning. Also class-hinting is not impl. yet.
I don't know what Michael is doind and what his status is or if there
are any other usable impl out there.
I've been quite bussy lately.


Jan

Any new updates on JSON?

AJ

Hi all,

> Any new updates on JSON?

JSON-RPC?

Nothing new realy.
I am thinking of adding sockets to JavaScript in HTML using an applet.
But have not had the time.
I already have an impl. of the SVG1.2 sockets as an ActiveX library
one can use in HTML of SVG or ...
I have not put it up for download but probably will incl. the sourcecode.
My main problem is time right now.
Since JSON-RPC is more or less a freetime project I am not able to
spend as much on it as I want to .


Jan

Hi Dmitry

Any chance of sharing your PHP4 code with me?
I have been using RPC via the DomAPI libary but am looking for
something a bit more lightweight. My server-side scripting language
is PHP.

Thanks

Josh

--- In json-rpc@yahoogroups.com, Dmitry Durach <durach@y...> wrote:
> Hello,
>
> I'm currently working on PHP implementation of the JSON-RPC
> I have designed code for PHP4 and going to start working on PHP5
work.
>
> Will let you know how will it work on real project!
>
> JSON-RPC forever!
>
> Regards,
> Dmitry

Hello Josh,

I'll open sourceforge project in a few days and upload the files
there. I'm almost done with PHP5 the code looks more beautiful.

However the code is not tested very well, so I'll appreciate if you
report on any issues you find.

> Any chance of sharing your PHP4 code with me?
> I have been using RPC via the DomAPI libary but am looking for
> something a bit more lightweight. My server-side scripting language
> is PHP.

-DD

Thanks,

We will need the code to be PHP4 compliant, but we will certainly
test it extensively in a real life application and share results
with you / this forum.
The sooner you can pput it up, the better for us. We are researching
alternatives.

Josh

--- In json-rpc@yahoogroups.com, Dmitry Durach <durach@y...> wrote:
> Hello Josh,
>
> I'll open sourceforge project in a few days and upload the files
> there. I'm almost done with PHP5 the code looks more beautiful.
>
> However the code is not tested very well, so I'll appreciate if you
> report on any issues you find.
>
> > Any chance of sharing your PHP4 code with me?
> > I have been using RPC via the DomAPI libary but am looking for
> > something a bit more lightweight. My server-side scripting
language
> > is PHP.
>
> -DD

Hello,

> I'll open sourceforge project in a few days and upload the files
> there. I'm almost done with PHP5 the code looks more beautiful.

This is good new.
I am glad to hear of impl. for JSON-RPC.
please send a link and I will include it in the impl. list on the
JSON-RPC page.

Also, if you have projects using the protocoll let us know.
It's always interesting to see what people do with the protocol.

I am also interested in hearing about any difficulties you ran across
impl. it (regarding the specs).



Jan

Hello Jan,

I've done a few tests. It looks like JS library on your site does not
support negative numbers.

Parsing of string:
{"result":null,"error":{"message":"Unknown
module","code":-2,"details":null},"id":"phpRequest"}

Returns an error.

-DD

> This is good new.
> I am glad to hear of impl. for JSON-RPC.
> please send a link and I will include it in the impl. list on the
> JSON-RPC page.

> Also, if you have projects using the protocoll let us know.
> It's always interesting to see what people do with the protocol.

> I am also interested in hearing about any difficulties you ran across
> impl. it (regarding the specs).

Hi,

> I've done a few tests. It looks like JS library on your site does
not support negative numbers.

This is so embarassing.
It's a bug in the tokenizer lib(lib/lang.js).
I have to fix that.
Sorry, I should have tested it better.


Thanks


Jan

Hello,


> > I've done a few tests. It looks like JS library on your site does
> not support negative numbers.
>


I have fixed the javascript impl. and the python impl.
Personally I am not too happy with both impl. they do need an overhaul
at some time. I am a bit too bussy at the moment so any voluntiers are
welcome.



Jan

Hi,

I can't make it work.

I tested it in IE and Firebird via http://localhost/tester.xhtml:
service: server.php
mathods: getIT
service: getIT()

with following error:

"Error trace:

Fault [module 'xmlrpc' version: 1.3.3]:
     XML-RPC Fault: 1

Unknown method"

My directory structure is:
c:\apache\www\jsolait\init.js
c:\apache\www\jsolait\lib\*
c:\apache\www\tester.xhtml
c:\apache\www\tester.js
c:\apache\www\server.php

server.php:
--- cut here ---
<?
require 'XML/RPC/Server.php'; // PEAR XML-RPC library
function php_server_getit()
{
	 $temp_array[0]['id'] = 5;
	 $temp_array[0]['content'] = 'some text';
	 $retval = XML_RPC_encode($temp_array);
	 return new XML_RPC_Response($retval);
}

$dispatch_map = array('getIT' => array('function' =>
'php_server_getit'));

$server = new XML_RPC_Server($dispatch_map);
?>
--- cut here ---

Help me please.

Hello,

you have to patch your copy of the PEAR XML_RPC library or use the
version from CVS.

Please patch it as described in bug 1604 (
http://pear.php.net/bugs/bug.php?id=1604 ):

[2004-10-08 20:49 UTC] lars dot berntzon at cecilia-data dot se

I made following patch to the RPC.php file. It resets the parser[ac]
entry when the start element <methodname>. there by the method name will
be picked up when handling </methodname>

*** RPC.php     2004-10-08 22:37:21.000000000 +0200
--- RPC.php.org 2004-10-08 22:19:04.000000000 +0200
***************
*** 170,179 ****
           $XML_RPC_xh[$parser]['st'] = "";
           break;

-     case "METHODNAME":
-         $XML_RPC_xh[$parser]['ac'] = "";
-         break;
-
       case "VALUE":
           $XML_RPC_xh[$parser]['st'] .= "new XML_RPC_Value(";
           $XML_RPC_xh[$parser]['lv'] = 1;
--- 170,175 ----


Basically you add in these lines at the right place:

    case "METHODNAME":
         $XML_RPC_xh[$parser]['ac'] = "";
         break;

If this is unclear, I will post a patched version of it to my
moztips.com site.

You can also check out the excellent XML-RPC library for PHP available
from Incutio:

http://scripts.incutio.com/xmlrpc/

That script is better because you do not manually have to encode your
variables (in your XML RPC server script).

- Jay
--- In json-rpc@yahoogroups.com, "frykasek" <fryk@t...> wrote:
>
> Hi,
>
> I can't make it work.
>
> I tested it in IE and Firebird via http://localhost/tester.xhtml:
> service: server.php
> mathods: getIT
> service: getIT()
>
> with following error:
>
> "Error trace:
>
> Fault [module 'xmlrpc' version: 1.3.3]:
>     XML-RPC Fault: 1
>
> Unknown method"
>
> My directory structure is:
> c:\apache\www\jsolait\init.js
> c:\apache\www\jsolait\lib\*
> c:\apache\www\tester.xhtml
> c:\apache\www\tester.js
> c:\apache\www\server.php
>
> server.php:
> --- cut here ---
> <?
> require 'XML/RPC/Server.php'; // PEAR XML-RPC library
> function php_server_getit()
> {
>  $temp_array[0]['id'] = 5;
>  $temp_array[0]['content'] = 'some text';
>  $retval = XML_RPC_encode($temp_array);
>  return new XML_RPC_Response($retval);
> }
>
> $dispatch_map = array('getIT' => array('function' =>
> 'php_server_getit'));
>
> $server = new XML_RPC_Server($dispatch_map);
> ?>
> --- cut here ---
>
> Help me please.

> Basically you add in these lines at the right place:
>
>    case "METHODNAME":
>         $XML_RPC_xh[$parser]['ac'] = "";
>         break;
>
> If this is unclear, I will post a patched version of it to my
> moztips.com site.
That was piece of cake and... IT WORKS NOW!!!

I don't know who you are but that was MAGIC for me.

> You can also check out the excellent XML-RPC library for PHP available
> from Incutio:
Thanks, I'll check it.

Best
__
fryk

Hi Folks,

There is a new version of my Java bindings for JSON-RPC

   http://oss.metaparadigm.com/jsonrpc/

I probably need to sync up changes with Jan-Klaas' jsolait JSON-RPC
(I have some private changes to handle callable proxies).

Question - has anyone had success with jsolait JSON-RPC in
Konqueror 3.3 or Opera 8 Beta? (both which supposedly support
the XMLHttpRequest object).

~mc