Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ruby > #2338 > unrolled thread

Seeking advice

Back to article view | Back to comp.lang.ruby

Contents

  Seeking advice Alex Rothbard <alex323@gmail.com> - 2011-04-05 08:22 -0500
    Re: Seeking advice Robert Klemme <shortcutter@googlemail.com> - 2011-04-05 08:39 -0500
      Re: Seeking advice Johnny Morrice <spoon@killersmurf.com> - 2011-04-05 09:44 -0500
        Re: Seeking advice Robert Klemme <shortcutter@googlemail.com> - 2011-04-05 10:23 -0500
    Re: Seeking advice Johnny Morrice <spoon@killersmurf.com> - 2011-04-05 08:43 -0500
    Re: Seeking advice Alex Rothbard <alex323@gmail.com> - 2011-04-05 13:30 -0500
      Re: Seeking advice Jesús Gabriel y Galán <jgabrielygalan@gmail.com> - 2011-04-06 01:53 -0500
      Re: Seeking advice Robert Klemme <shortcutter@googlemail.com> - 2011-04-06 04:30 -0500

#2338 — Seeking advice

Hi. I am writing a library that will have the ability to access a server
by many different "transports" (JSON over HTTP, Thrift, etc). Depending
on which transport the user chooses, different files and classes will
need to be loaded.

A complete implementation of a transport requires that three classes
(such as the 'Grid' class below) be implemented from their respective
base class. Additionally, if the user wants to use JSON over HTTP, they
shouldn't need to depend on the thrift gem and vice versa. These
transport classes are used by other classes within the library, and
should never be used directly by the user.

What is the best way to allow the user of the library to specify a
transport at runtime? Could I wrap all my implemented transport classes
in a module and do something like this?:

def initialize(transport)
  @t = transport
  @grid = @t::Grid.new
end

where "transport" could be "MyProject::Transport::Thrift".

Is this a good idea? Is there a better way?

-- 
Posted via http://www.ruby-forum.com/.

[toc] | [next] | [standalone]

#2342

On Tue, Apr 5, 2011 at 3:22 PM, Alex Rothbard <alex323@gmail.com> wrote:
> Hi. I am writing a library that will have the ability to access a server
> by many different "transports" (JSON over HTTP, Thrift, etc). Depending
> on which transport the user chooses, different files and classes will
> need to be loaded.
>
> A complete implementation of a transport requires that three classes
> (such as the 'Grid' class below) be implemented from their respective
> base class. Additionally, if the user wants to use JSON over HTTP, they
> shouldn't need to depend on the thrift gem and vice versa. These
> transport classes are used by other classes within the library, and
> should never be used directly by the user.
>
> What is the best way to allow the user of the library to specify a
> transport at runtime? Could I wrap all my implemented transport classes
> in a module and do something like this?:
>
> def initialize(transport)
>  @t = transport
>  @grid = @t::Grid.new
> end
>
> where "transport" could be "MyProject::Transport::Thrift".
>
> Is this a good idea? Is there a better way?

I'd go for factory pattern.

def initialize(transport)
 @t = transport
 @grid = @t.grid
 @grid = @t.grid.new # alternative
end

All transports must implement the particular set of methods of course.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#2347

On Tue, Apr 5, 2011 at 3:22 PM, Alex Rothbard <alex323@gmail.com> wrote:
> A complete implementation of a transport requires that three classes
> (such as the 'Grid' class below) be implemented from their respective
> base class.

> These transport classes are used by other classes within the
> library, and should never be used directly by the user.

I interpreted this to mean that the base grid class would not be part
of the interface presented to the user either. Is this correct?

On Tue, 5 Apr 2011 22:39:33 +0900
Robert Klemme <shortcutter@googlemail.com> wrote:
> def initialize(transport)
>  @t = transport
>  @grid = @t.grid
>  @grid = @t.grid.new # alternative
> end

Cus the way Robert saw it was that the transport should be the factory
for the grid, and the user will see the grid.  The transport, which is
the factory for the grid, is fed to the object.

But the way I saw it was that the transport should be created by the
factory and so the user should see no grid at all.  The factory
feeds the transport to the object.

Have I missed the point?  More importantly, have you made the code win?

Cheers
Johnny

[toc] | [prev] | [next] | [standalone]

#2349

On Tue, Apr 5, 2011 at 4:44 PM, Johnny Morrice <spoon@killersmurf.com> wrote:
> On Tue, Apr 5, 2011 at 3:22 PM, Alex Rothbard <alex323@gmail.com> wrote:
>> A complete implementation of a transport requires that three classes
>> (such as the 'Grid' class below) be implemented from their respective
>> base class.
>
>> These transport classes are used by other classes within the
>> library, and should never be used directly by the user.
>
> I interpreted this to mean that the base grid class would not be part
> of the interface presented to the user either. Is this correct?
>
> On Tue, 5 Apr 2011 22:39:33 +0900
> Robert Klemme <shortcutter@googlemail.com> wrote:
>> def initialize(transport)
>>  @t = transport
>>  @grid = @t.grid
>>  @grid = @t.grid.new # alternative
>> end
>
> Cus the way Robert saw it was that the transport should be the factory
> for the grid, and the user will see the grid.  The transport, which is
> the factory for the grid, is fed to the object.
>
> But the way I saw it was that the transport should be created by the
> factory and so the user should see no grid at all.  The factory
> feeds the transport to the object.

We probably need more context.  In an attempt to create a bigger example:

$ ./TrueGrit.rb
sending "basic message" across TheLibrary::JasonTransport
closing TheLibrary::JasonTransport
waiting for two weeks to transmit "basic message" via TheLibrary::CarrierPigeon
TheLibrary::CarrierPigeon is flying home
$ cat -n TrueGrit.rb
     1  #!/bin/env ruby19
     2
     3  module TheLibrary
     4
     5    class BaseTransport
     6      def self.open(*params)
     7        grid = new(*params)
     8
     9        if block_given?
    10          begin
    11            yield grid
    12          ensure
    13            grid.close
    14          end
    15        else
    16          grid
    17        end
    18      end
    19    end
    20
    21    class JasonTransport < BaseTransport
    22      def send(msg)
    23        printf "sending %p across %p\n", msg, self.class
    24      end
    25
    26      def close
    27        printf "closing %p\n", self.class
    28      end
    29    end
    30
    31    class ThriftTransport < BaseTransport
    32      def send(msg)
    33        printf "sending %p across %p\n", msg, self.class
    34      end
    35
    36      def close
    37        printf "%p says, man I'm glad I get home\n", self.class
    38      end
    39    end
    40
    41    class CarrierPigeon < BaseTransport
    42      def send(msg)
    43        printf "waiting for two weeks to transmit %p via %p\n",
msg, self.class
    44      end
    45
    46      def close
    47        printf "%p is flying home\n", self.class
    48      end
    49    end
    50
    51  end
    52
    53  include TheLibrary;
    54
    55  JasonTransport.open(:host => "foo.bar.com") do |grid|
    56    grid.send("basic message")
    57  end
    58
    59  CarrierPigeon.open(:destination => "Stockholm") do |grid|
    60    grid.send("basic message")
    61  end
$

It really does not matter what method #new of the factory returns (or
whether it's called "new" at all).  Basically one needs a defined
interface (note that I left some flexibility in there in order to be
able to provide different configurations depending on transport used).
 Also, the approach with open is just an example how to do this in the
same manner as File and IO and other classes work which use a block
for safe resource deallocation.

> Have I missed the point?  More importantly, have you made the code win?

I'm not sure what "win" means in this context...

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#2343

On Tue, 5 Apr 2011 22:22:17 +0900
Alex Rothbard <alex323@gmail.com> wrote:

> What is the best way to allow the user of the library to specify a
> transport at runtime? 

Use factory pattern

The user should call something like

MyProject::Transport::ThriftFactory.build

Then they don't need to find the transport themselves.
But it should be obvious what ThriftFactory returns.

The following might be how you would do it, up to you really :)

# I don't know what this is about, so I'm calling your class Foo here
class Foo

   # My Foo transports all the data to the yard
   def initialize(transport)
      @t = transport
      @grid = @t::Grid.new
    end

end

# Factory to build the Foo which uses the Thrift Transporter
class ThriftFactory

   # Users can make Foos that transport with Thrift without having to
   # find the Thrift themselves
   def build
      Foo.new MyProject::Transport::Thrift
   end

end
   

[toc] | [prev] | [next] | [standalone]

#2361

The factory design pattern is sort of what I want, but not exactly.
Remember that there are three different classes (services) that need to
take advantage of a transport. The library is broken down like this:

There is a high level class that represents a user's overall account.
The user uses this class only. This account class needs to access three
different "services" (classes): the grid, the archive, and the
transaction service. All three services need to communicate with the
remote server using a transport.

In the example above, the transport is providing methods for accessing
the grid, but I am thinking of it in another way: the
grid/archive/transaction classes should provide methods which correspond
to the API on the remote server, and those classes then use the selected
transport to send it across.

In short, I have a server library which offers up three sets of APIs
(one for each service), and I want to be able to allow the end user to
easily choose which transport the client library uses when accessing
these services.

-- 
Posted via http://www.ruby-forum.com/.

[toc] | [prev] | [next] | [standalone]

#2376

On Tue, Apr 5, 2011 at 8:30 PM, Alex Rothbard <alex323@gmail.com> wrote:
> The factory design pattern is sort of what I want, but not exactly.
> Remember that there are three different classes (services) that need to
> take advantage of a transport. The library is broken down like this:
>
> There is a high level class that represents a user's overall account.
> The user uses this class only. This account class needs to access three
> different "services" (classes): the grid, the archive, and the
> transaction service. All three services need to communicate with the
> remote server using a transport.
>
> In the example above, the transport is providing methods for accessing
> the grid, but I am thinking of it in another way: the
> grid/archive/transaction classes should provide methods which correspond
> to the API on the remote server, and those classes then use the selected
> transport to send it across.
>
> In short, I have a server library which offers up three sets of APIs
> (one for each service), and I want to be able to allow the end user to
> easily choose which transport the client library uses when accessing
> these services.

Then something like:

class Grid
  TRANSPORTS = {:json => JsonTransport, :thrift => ThriftTransport}

  def initialize transport, params
    @transport = TRANSPORTS[transport]
    # ... initialize the transport with params if required or whatever
  end

  def method_xxx param1, param2
    @transport.call_remote_method(:xxx, param1, param2) # the
transport defines how to call remote methods, I guess
  end
end

grid = Grid.new :json, {:url => "http://my.json.service"}
grid.method_xxx ("a", "b")

If you don't want the client to know about transport params, you can
hide the configuration inside the Grid class, or read it from a file
or something.

Jesus.

[toc] | [prev] | [next] | [standalone]

#2380

On Tue, Apr 5, 2011 at 8:30 PM, Alex Rothbard <alex323@gmail.com> wrote:
> The factory design pattern is sort of what I want, but not exactly.
> Remember that there are three different classes (services) that need to
> take advantage of a transport. The library is broken down like this:

I'm not convinced we are actually that far away from what you want.

> There is a high level class that represents a user's overall account.
> The user uses this class only. This account class needs to access three
> different "services" (classes): the grid, the archive, and the
> transaction service. All three services need to communicate with the
> remote server using a transport.

Do all three services need their own implementation of each transport
(i.e. thrift for grid, thrift for archive, thrift for TX) or do you
only need / want a single transport implementation per service?

> In the example above, the transport is providing methods for accessing
> the grid, but I am thinking of it in another way: the

Well, that's just a name.  You can replace it by "connection". :-)

> grid/archive/transaction classes should provide methods which correspond
> to the API on the remote server, and those classes then use the selected
> transport to send it across.
>
> In short, I have a server library which offers up three sets of APIs
> (one for each service), and I want to be able to allow the end user to
> easily choose which transport the client library uses when accessing
> these services.

It would be important to know when the user must decide about the
transport.  Do you want to have him do it initially when he opens his
account?  Do you want to allow for later changes of the transport?  Or
do you even want to use a different transport per interaction?  Also,
how do you want your transports to work: should they be connection
oriented or message oriented?  This will determine whether you need
something like a connection object you must store somewhere.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.ruby

csiph-web