Re: [Openinteract-help] Using several content-generators for one action?

[Heiko K. <Hei...@gm...>]

Hi,

I have been thinking most about the limited amount of names we're having 
for action/methods and I was thinking about bundling those which have 
the same content and just a different content-type.

That we use one SOAP entry point (SOAP::Lite calls this a proxy, when I 
understand right), is fine for me. Ant the results, as you describe them 
in the table, are nearly exactly what I think of. (The URL 
http://myoi.com/action.soap whould not exist, but the SOAP entry 
point/proxy locator URL http://myoi.com/soap with the identifier URI 
http://myoi.com/action .

I prefer a configuration where everything kan be configured from the 
top-level file (i.e. enabling the SOAP handler for all packages) and 
that the packages can specify when they don't want to have the one or 
other. But thats more a question of taste.

Having a split of action/method/presentation-type (with a dot or a slash 
or a soap-entry-point) seems natural to me.

Best regards,

heiko

Kutter Martin wrote:
> Hi Heiko !
> 
> ....after a while of thinking, I got the idea that you actually suggested
> something different (sorry that I didn't get this before): a request handler
> that can handle different types of requests (like SOAP, WWW-Form).
> 
> This would mean an end to the need of a separate entry point for SOAP
> requests, and allow to return an error if a user tries to access an action
> returning SOAP-Content via a browser, or an action returning HTML (or PDF or
> whatever) content via SOAP.
> 
> This would mean that you could access your actions by whatever way you like,
> and always get a correct response:
> 
>                Accessed by:      Browser           SOAP
> 
>         Page                              Result
> 
> http://myoi.com/action.html      HTML Page         SOAP Fault
> http://myoi.com/action.soap      HTML Error page   SOAP Response
> http://myoi.com/action.pdf       PDF file          SOAP Fault
> 
> How this is configured in the action config should be a secondary issue.
> 
> Regards,
> 
> Martin Kutter
> 
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of
> Kutter Martin
> Sent: Mittwoch, 6. Oktober 2004 16:58
> To: ope...@li...
> Subject: RE: [Openinteract-help] Using several content-generators for
> one action?
> 
> 
> Hi Heiko 
> 
> 
>>Your current SOAP implementation (which I like) needs a proxy-url (i.e. 
>>http://my.oi2.com/WebServices) to get to get the correct soap-request 
>>handler. Only calls to that proxy should give you back a useable 
>>soap-response.) Why should then all URIs (soap-namespaces) contain in 
>>addition the _soap flag, i.e. "http://my.oi.com/action_soap"?
> 
> 
> ....it's not quite a proxy-URL. It's just another entry point for OI2 (like
> CGI, Standalone or Apache are).
> And the SOAP request handler allows to access different actions at the same
> URL by specifying the Action as SOAP method URI. This is somewhat common for
> web Services, though it is not REST-design.
> 
> ....and you don't need a _soap suffix for actions which use a SOAP Content
> generator.
> You can just call them whatever you like.
> 
> OI actions are *not* namespaces - they are just URL-snippets like /action/
> to the user 
> and a lookup table with associated modules for OI2.
> 
> 
>>.html should be the default-type for all pages, so http://my.oi.com 
>>still functions, no requirement on a index.html. For .pdf files, you 
>>will need the http://my.oi.com/index.pdf. This requirement isn't that 
>>large. I have never seen a web-site delivering a pdf-page without a .pdf 
>>ending. I'm not even sure if the windows plugin handler will handle it 
>>without a .pdf at the end.
> 
> 
> I have - and windows usually does know the MIME-type application/pdf and
> thus handle the associated document correctly. 
> 
> I think this argument is raising to a philosophical level: You would like 
> 
> [action]
> class  FOO
> content-generator BAR
> content-generator FOOBAR
> content-gererator BAZ
> 
> The current implementation does
> 
> [action]
> class FOO
> content-generator BAR
> 
> [someotheraction]
> class FOO
> content-generator FOOBAR
> 
> [onemoreaction]
> class FOO
> content-generator BAZ
> 
> These implementations are almost equal in terms of functionality - where you
> have 
> http://url/action.bar
> http://url/action.foobar
> http://url/action.baz
> 
> in the first variant, you have
> 
> http://url/action
> http://url/someotheraction
> http://url/onemoreaction
> 
> If OI2 would support the '.' character in action names (I don't know if it
> does) , you could even do 
> 
> [action.bar]
> class FOO
> content-generator BAR
> 
> [action.foobar]
> class FOO
> content-generator FOOBAR
> 
> [action.baz]
> class FOO
> content-generator BAZ
> 
> with
> 
> http://url/action.bar
> http://url/action.foobar
> http://url/action.baz
> 
> in the second one.
> 
> The only difference is the config file - and if you specify which task is
> valid for which content generator, config file complexity and length is
> equal for both variants.
> 
> 
> Regards,
> 
> MArtin Kutter
> 
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of Heiko
> Klein
> Sent: Mittwoch, 6. Oktober 2004 16:20
> Cc: ope...@li...
> Subject: Re: [Openinteract-help] Using several content-generators for
> one action?
> 
> 
> Hi Martin,
> 
> except the point, that you might not like to support all methods with 
> all content-generators, I don't agree with your points.
> 
> Calling directly http://my.oi.com/action with SOAP without the correct 
> Proxy will still give you a html-page (and thus an error).
> 
> ..html should be the default-type for all pages, so http://my.oi.com 
> still functions, no requirement on a index.html. For .pdf files, you 
> will need the http://my.oi.com/index.pdf. This requirement isn't that 
> large. I have never seen a web-site delivering a pdf-page without a .pdf 
> ending. I'm not even sure if the windows plugin handler will handle it 
> without a .pdf at the end.
> 
> For an API to all OI-functionality, it would be nice to have the 
> request-handler determine the request-type, even when some functionality 
> is quite useless for some methods (your web-form example). One thing i 
> must admit: The OI action/methods have been designed for web-pages, it 
> is quite likely that it is not suitable for an API, where you would like 
> to bundle the functionality. Thus it would feel quite natural to write 
> own actions for a SOAP request.
> 
> Since I'm lazy, I think my idea would be quite easy enough to implement 
> and would immediately give full access to the whole functionality which 
> exists in the web-pages. It would be easy enough to switch off a 
> content-generator for a action and add a own content-generator to a 
> method as [action_soap].
> 
> Best wishes,
> 
> Heiko
> 
> 
> 
> Kutter Martin wrote:
> 
>>Hi Heiko,
>>
>>OI2's solution is maybe technical, but does not have any impacts asides
> 
> from
> 
>>a few more lines in the config file.
>>
>>The config
>>
>>[foo]
>>content-generator = TT
>>class = MyFoo::Action
>>
>>[fooWebService]
>>content-generator = SOAP
>>class = MyFoo::Action
>>
>>direct both actions to the same perl module.
>>
>>There is no need to include the name of the content generator in the
>>action's name - it was just an example.
>>For an end user, an OI2 action is just a URL-snippet - and SOAP
> 
> programmers
> 
>>definitely won't regard an URL containing something like '_soap' or
>>'WebService' or the like as strange - it's rather normal.
>>
>>Delegating Content-Generator switching to the Request Handler has some
>>serious disadvantages:
>>
>>- Your suggestion would accept requests for all content handlers on the
> 
> same
> 
>>URL.
>>If you access an URL hosting a WWW-(HTML)-page with a SOAP-Call, (or a
>>SOAP-Webservice with a browser) you would expect this call to fail or be
> 
> at
> 
>>least non-functional.
>>Your suggestion would change this.
>>
>>Moreover, Requests from a Browser and SOAP-Requests could be required to
> 
> use
> 
>>different authentications (e.g. normal Username/Password for WWW-Forms,
>>Client SSL Certificate for SOAP). This is very hard to implement for
>>different contents on the same URL (Apache can handle this for different
>>URLs).
>>
>>Determining the request type from the request content is rather difficult,
>>if at all possible. The SOAP protocol defines not only a
> 
> "Request-Response"
> 
>>model with SOAP request & SOAP response, but also a "Response" model,
> 
> where
> 
>>the request is a simple HTTP GET (This is not supported by the current OI2
>>SOAP implementation). I don't know how you would find out whether a GET on
>>the same URL is meant for a SOAP content generator or a PDF content
>>generator.
>>
>>- Making the Request handler decide about Content Generation would expose
>>all tasks of an action via all content generators (or introduce the same
>>configuration overhad different actions do).
>>This is to be avoided: Maybe you do not want to make some functions
>>accessible via other means than SOAP, and maybe you don't want some other
>>pages accessible via SOAP or PDF content generators (Forms for editing
> 
> data
> 
>>are a classical WWW-Form-only example).
>>
>>- The need for all "HTML" requests to match /\.html$/ and all PDF requests
>>match /\.pdf$/ is a very artificial requirement almost never seen on
>>web-servers on the internet. Or would you expect that e-bay would require
>>you to request http://www.ebay.com/index.html instead of
> 
> http://www.ebay.com
> 
>>as a start page ? 
>>
>>This would confuse end-users more than having to access different URLs for
>>PDF, HTML and SOAP version (something quite general: The usual "print
>>version" link on lots of pages).
>>
>>In my opinion, the current scheme has enough power to handle most
> 
> scenarios.
> 
>>I don't think a request-type aware RequestHandler would bring more
> 
> benefits
> 
>>than disadvantages.
>>
>>Regards,
>>
>>Martin Kutter
>>
>>-----Original Message-----
>>From: ope...@li...
>>[mailto:ope...@li...]On Behalf Of Heiko
>>Klein
>>Sent: Mittwoch, 6. Oktober 2004 10:51
>>To: ope...@li...
>>Subject: Re: [Openinteract-help] Using several content-generators for
>>one action?
>>
>>
>>Hmmm,
>>
>>declaring a different action for a different content-generator is a
>>rather technical than user-friendly solution. I guess we will end up
>>with something like:
>>
>>[foo]
>>content-generator = TT
>>
>>[foo_soap]
>>content-generator = SOAP
>>
>>[foo_wap]
>>content-genertor = WAP
>>
>>[foo_pdf]
>>content-genertor = GS-PDF
>>
>>
>>and we will have to write a lots of stuff for each of these action.
>>Since a action is more of a class or namespace for a method, I don't see
>>why it needs to include the content generator.
>>
>>[foo_soap] needs a SOAP response and request generator. The soap API
>>user will think its very strange that all namespaces have _soap included.
>>
>>[foo_pdf] and [foo_wap] will most likely have a request for something
>>ending with .pdf as an ending. (At least, nobody would think it's
>>strange when you require this.)
>>
>>
>>Without having looked closely at the code yet, I would make the request
>>generator determine the content-type. After setting some default (most
>>likely to .html), when the request ends with .pdf to pdf and with .wap
>>to wap. SOAP has a different request-generator, so it will be very easy
>>to set the content-type to soap there.
>>
>>The only situation, where you will need different actions is when you
>>want to present the same content-type (html) with different
>>html-content-generators - IMHO not a very common situation in
>>production. (In testing, sure this will happen, but for test-pages I
>>want to have the possibilty to switch between foo_TT and
> 
> foo_HTMLTemplate.)
> 
>>So, if it makes sense, it is a feature request to implement several
>>content-generator determined by content-type per action:
>>[foo]
>>content-generator default = TT
>>content-generator soap = SOAP
>>content-generator pdf = GS-PDF
>>....
>>(don't know if this is parseable by the .ini-reader)
>>
>>Best regards,
>>
>>Heiko
>>
>>Chris Winters wrote:
>>
>>
>>>>I'm currently trying out Martin Kutters SOAP add on for OpenInteract2.
>>>>My idea is to use soap as remote API for OI2. Thus I would like to have
>>>>two content-generators for all packages, one giving the usual
>>>>html-response, and the other one giving a soap response.
>>>
>>>
>>>That's been my idea for SOAP as well.
>>>
>>>
>>>
>>>
>>>>When I understand the current implementation of OI correct, then it is
>>>>in principle possible to have several content generators in OI, but one
>>>>action has exactly one content generator, defined by the action.ini
>>>>file, not by the Response-type. I hope I'm wrong with this assumption,
>>>>so my question is, how do I enable different content-generators for one
>>>>action? Or is my understanding of an 'action' wrong?
>>>
>>>
>>>Your understanding is right. But I think what's missing is you can map
>>>multiple action specifications to the same class. For instance in an
>>>action.ini you might have:
>>>
>>>[foo]
>>>class = OpenInteract2::Action::Foo
>>>content_generator = TT
>>>
>>>[bar]
>>>class = OpenInteract2::Action::Foo
>>>content_generator = SOAP
>>>
>>>The same data are retrieved from the action + task, but they're passed off
>>>to a different content generator depending on how they were invoked. Make
>>>sense?
>>>
>>>The 'news' package has some commented-out examples of doing this with
>>>Text::Template and HTML::Template.
>>>
>>>
>>>
>>>
>>>>And in some packages, I haven't seen the content_generator flag in the
>>>>action.ini. Where is the default defined?
>>>
>>>
>>>In server.ini:
>>>
>>>[action_info default]
>>>controller         = tt-template
>>>content_generator  = TT
>>>
>>>Hope this helps,
>>>
>>>Chris
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>Use IT products in your business? Tell us what you think of them. Give us
>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> 
> more
> 
>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>_______________________________________________
>>openinteract-help mailing list
>>ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/openinteract-help
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>Use IT products in your business? Tell us what you think of them. Give us
>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> 
> more
> 
>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>_______________________________________________
>>openinteract-help mailing list
>>ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/openinteract-help
>>
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
> 
>