How can I have the application running in the background without using the windows server

On 31. Mrz 2006, at 21:14 Uhr, Philippe Laval wrote:
> Yesterday, I have read a lot of code about SOPE XML-RPC
 
> implementation and also about how oGo uses of this part
of the  
> framework.

Actually there are two implementations. An old one which is
somewhat  
based on WODirectAction and a new one which is based on
SOPE-as-in- 
ZOPE, aka SoObjectRequestHandler.

The ogo-xmlrpcd uses the first/old one and I'm not so fond
of the  
implementation (rather hackish code).

I think the new one is quite nice but AFAIK not really used
currently  
(not sure whether ZNeK does some stuff with it). An example
can be  
found in OGo in ZideStore/Protocols/Blogger which implements
some  
BloggerAPI for OGo.

Greets,
   Helge
-- 
http://d
ocs.opengroupware.org/Members/helge/
OpenGroupware.org

-- 
OpenGroupware.org MacOS X
macosxopengroupware.org
http://mail.opengroupware.org/mailman/listinfo/macosx

Helge Hess schrieb:
> I think the new one is quite nice but AFAIK not really
used currently 
> (not sure whether ZNeK does some stuff with it). An
example can be found 

The new implementation is really nice ... it's very close
to the 
WebObjects idea of doing things (it's using DirectActions
and standard 
accessor methods for mapping the positional arguments in an
XML-RPC call 
to the parameters probably used in the direct action ...
very nifty 
indeed). However, the setup in the product.plist currently
has one 
glitch ... you have to use the RequestHandler as the object
for adding 
categories (XML-RPC methods) to - not the Application
object. I think 
that this is a bug ... however I never understood this
particular 
semantic in the product.plist at all, so I don't really
care. Helge can 
probably elaborate on this (what he intended to do with it).

Cheers,

   Marcus
-- 
OpenGroupware.org MacOS X
macosxopengroupware.org
http://mail.opengroupware.org/mailman/listinfo/macosx

On 1. Apr 2006, at 13:01 Uhr, Marcus Mueller wrote:
> The new implementation is really nice ... it's very
close to the  
> WebObjects idea of doing things (it's using
DirectActions and  
> standard accessor methods for mapping the positional
arguments in  
> an XML-RPC call to the parameters probably used in the
direct  
> action ... very nifty indeed). However, the setup in
the  
> product.plist currently has one glitch ... you have to
use the  
> RequestHandler as the object for adding categories
(XML-RPC  
> methods) to - not the Application object.

I'm pretty sure this isn't the case. You need to define
the methods  
on the SoObject you address in your XML-RPC calls. If you
have

   /myapp/so/Calendar

you need to define your methods on the
"Calendar" object.

If you need to define the methods on your request handler,
you  
probably use a URL like URL:
   /myapp/[something]
which I think returns a WORequestHandler in the path lookup.


Notably another option supported by SOPE (this is also how
its done  
in Zope) is to use the XML-RPC package name for path
processing. Say  
you want to invoke

   calendar.events.addEvent()

you can either directly map the
"calendar.events.addEvent" method in  
product.plist OR you just map the "addEvent"
method and use an object  
hierarchy like:

   /myapp/so/calendar/events

to define the XML-RPC call. SOPE will automatically revert
to  
namespace processing if it can't find fully qualified
method on the  
target object. (see SoObjectXmlRpcDispatcher.m)

Greets,
   Helge
-- 
http://d
ocs.opengroupware.org/Members/helge/
OpenGroupware.org
-- 
OpenGroupware.org MacOS X
macosxopengroupware.org
http://mail.opengroupware.org/mailman/listinfo/macosx

On 3. Apr 2006, at 11:20 Uhr, Marcus Müller wrote:
> Correct. I'm posting to /RPC2 ... thanks for your
detailed  
> explanation.

Maybe we should make the /RPC2 URL a special case which
returns the  
application object. But then maybe not 

> Just for clarity's sake, I then need to add the
"categories" to the  
> SoObjectRequestHandler object, i.e.:

Yes, RPC2 is a registered request handler (the SoApplication
- 
lookupName:inContext: will try to resolve names by calling -

handlerForKey.

> --- snip ---
>   categories = {
>     SoObjectRequestHandler = {

Yup, this is messy. Just define a proper object which is
your XML-RPC  
API and attach that to the application object. Actually it
might even  
be possible to use "RPC2" as a key for that
object, like:

   categories = {
     SoApplication = {
       slots = {
         RPC2 = {
           defaultAccess = allow;
           protectedBy   = "<public>";
           valueClass    = ZNeKAPI;
         };
       };
     };
   };
   classes = {
     ZNeKAPI = {
       methods = {
>         "system.listMethods" = {
>           protectedBy = "View";
>           actionClass = "BMSOPEAction";
>           actionName  =
"listSystemMethods";
>           arguments   = { positionalKeys = ( ); };
>         };
>       };
     };
   };

Might work, didn't try.

> I see. This really offers quite some flexibility,
although I can't  
> think of a situation where this might be very useful.

Hu? This allows you to properly package your API. Like

   events
     addEvent
     deleteEvent
   tasks
     addTask
     deleteTask

Obviously you don't want to put your whole XML-RPC API in
just a  
single object/class.

A bit more obscure is the ability to address individual
objects with  
XML-RPC. But still quite cool IMHO.

Greets,
   Helge
-- 
http://d
ocs.opengroupware.org/Members/helge/
OpenGroupware.org

-- 
OpenGroupware.org MacOS X
macosxopengroupware.org
http://mail.opengroupware.org/mailman/listinfo/macosx

On 4. Apr 2006, at 01:19 Uhr, Marcus Müller wrote:
> Is this some future extension - or is this already
possible?

Not sure what you mean, but everything outlined should be
"already  
possible".

> Is this correct? You provide some value class which
itself doesn't  
> implement anything as it's defining methods which get
redirected to  
> the BMSOPEAction class. Or did you skip (overlook) that
part of the  
> definition and meant something different?

Get the Zope/SOPE concept  The
given class (SoClass) *does* have a  
method. That the method in turn is implemented as a direct
action and  
not a regular ObjC method is just a minor difference. (a
SoMethod is  
anything "callable").

Thats Python/Zope style. Implementation doesn't matter.
Everything  
which is 'callable' can be a method, be it a WOComponent,
a  
WODirectAction or a plain ObjC selector (or a SQLMethod
which  
executes SQL or a PythonMethod etc etc).

> Packaging everything depending on URLs is cool, but not
very  
> intuitive to use in other client side implementations.

Reread my initial response. You don't need to use URLs, you
can also  
use XML-RPC namespaces. Processing is exactly the same.
Either use

   server = Server("http://host/MyApp")
   server.events.deleteEvent(12345)
or use
   server = Server("http://host/MyApp/so/even
ts")
   server.deleteEvent(12345)

Its your choice. For the app developer it doesn't matter.

> In python's xmlrpclib module, you need different
server objects for  
> different URLs.

No, you don't.

>> A bit more obscure is the ability to address
individual objects  
>> with XML-RPC. But still quite cool IMHO.
> What do you mean?

Well, object oriented programming  Say you
have an event object  
living at (mapped to):

   http:/
/host/zidestore/so/helge/Calendars/12634

you can run XML-RPC "methods" on it. (XML-RPC
"methods" are not  
really methods but just functions, unless you map
"self" to the URL ...)

Greets,
   Helge
-- 
http://d
ocs.opengroupware.org/Members/helge/
OpenGroupware.org
-- 
OpenGroupware.org MacOS X
macosxopengroupware.org
http://mail.opengroupware.org/mailman/listinfo/macosx