Results for blocking-http-server

A simple Blocking HTTP server library

Evented WebSockets and Server Side Events for Ruby, using Celluloid::IO and WebSocket::Driver.

A Free Software, multi-threaded, non-blocking network application server designed for low _idle_ power consumption. It is primarily optimized for applications with occasional users which see little or no traffic. yahns currently hosts Rack/HTTP applications, but may eventually support other application types. Unlike some existing servers, yahns is extremely sensitive to fatal bugs in the applications it hosts.

BackgrounDRb is a Ruby job server and scheduler. Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from http request/response cycle. This is the RoR 3 version (Railtie based) of the gem. Please read the GitHub homepage for installation instructions.

Em-resque is a version of Resque, which offers non-blocking and non-forking workers. The idea is to have fast as possible workers for tasks with lots of IO like pinging third party servers or hitting the database. The async worker is using fibers through Synchrony library to reduce the amount of callback functions. There's one fiber for worker and if one of the workers is blocking, it will block all the workers at the same time. The idea to use this version and not the regular Resque is to reduce the amount of SQL connections for high-load services. Using one process for many workers gives a better control to the amount of SQL connections. For using Resque please refer the original project. https://github.com/defunkt/resque/ The library adds two rake tasks over Resque: * resque:work_async for working inside the EventMachine

Public IP blocks are a set of contiguous IPs that allow you to access your servers or networks from the internet. Use the IP Addresses API to request and delete IP blocks.<br> <br> <span class='pnap-api-knowledge-base-link'> Knowledge base articles to help you can be found <a href='https://phoenixnap.com/kb/public-ip-management#bmc-public-ip-allocations-api' target='_blank'>here</a> </span><br> <br> <b>All URLs are relative to (https://api.phoenixnap.com/ips/v1/)</b>

pikuri-mcp adds Model Context Protocol support to pikuri-core agents: a +Pikuri::Mcp::Registry+ for declaring stdio + HTTP MCP servers, the +Pikuri::Mcp::Servers+ runtime that spawns them, a +Pikuri::Mcp::Synthesizer+ that LLM-fills missing server descriptions, a +Pikuri::Mcp::Verifier+ that screens server surfaces for prompt-injection patterns before any tool is advertised to the LLM, and a +Pikuri::Mcp::Extension+ that wires everything into a +Pikuri::Agent+ via +c.add_extension(...)+ in the +Agent.new+ block.

This is Daemons 1.0.10 with the addition of Chris Kline's fix from http://blog.rapleaf.com/dev/?p=19 Daemons provides an easy way to wrap existing ruby scripts (for example a self-written server) to be run as a daemon and to be controlled by simple start/stop/restart commands. If you want, you can also use daemons to run blocks of ruby code in a daemon process and to control these processes from the main application. Besides this basic functionality, daemons offers many advanced features like exception backtracing and logging (in case your ruby script crashes) and monitoring and automatic restarting of your processes if they crash. Daemons includes the daemonize.rb script written by Travis Whitton to do the daemonization process.

This is Daemons 1.0.10 with the addition of Chris Kline's fix from http://blog.rapleaf.com/dev/?p=19 Daemons provides an easy way to wrap existing ruby scripts (for example a self-written server) to be run as a daemon and to be controlled by simple start/stop/restart commands. If you want, you can also use daemons to run blocks of ruby code in a daemon process and to control these processes from the main application. Besides this basic functionality, daemons offers many advanced features like exception backtracing and logging (in case your ruby script crashes) and monitoring and automatic restarting of your processes if they crash. Daemons includes the daemonize.rb script written by Travis Whitton to do the daemonization process.

This is Daemons 1.0.10 with the addition of Chris Kline's fix from http://blog.rapleaf.com/dev/?p=19 Includes ability to change the process uid/gid. Also logdir can be specified seperate from piddir. Daemons provides an easy way to wrap existing ruby scripts (for example a self-written server) to be run as a daemon and to be controlled by simple start/stop/restart commands. If you want, you can also use daemons to run blocks of ruby code in a daemon process and to control these processes from the main application. Besides this basic functionality, daemons offers many advanced features like exception backtracing and logging (in case your ruby script crashes) and monitoring and automatic restarting of your processes if they crash. Daemons includes the daemonize.rb script written by Travis Whitton to do the daemonization process.

:title: The Ruby API :section: PYAPNS::Client There's python in my ruby! This is a class used to send notifications, provision applications and retrieve feedback using the Apple Push Notification Service. PYAPNS is a multi-application APS provider, meaning it is possible to send notifications to any number of different applications from the same application and same server. It is also possible to scale the client to any number of processes and servers, simply balanced behind a simple web proxy. It may seem like overkill for such a bare interface - after all, the APS service is rather simplistic. However, PYAPNS takes no shortcuts when it comes to completeness/compliance with the APNS protocol and allows the user many optimization and scaling vectors not possible with other libraries. No bandwidth is wasted, connections are persistent and the server is asynchronous therefore notifications are delivered immediately. PYAPNS takes after the design of 3rd party push notification service that charge a fee each time you push a notification, and charge extra for so-called 'premium' service which supposedly gives you quicker access to the APS servers. However, PYAPNS is free, as in beer and offers more scaling opportunities without the financial draw. :section: Provisioning To add your app to the PYAPNS server, it must be `provisioned` at least once. Normally this is done once upon the start-up of your application, be it a web service, desktop application or whatever... It must be done at least once to the server you're connecting to. Multiple instances of PYAPNS will have to have their applications provisioned individually. To provision an application manually use the `PYAPNS::Client#provision` method. require 'pyapns' client = PYAPNS::Client.configure client.provision :app_id => 'cf', :cert => '/home/ss/cert.pem', :env => 'sandbox', :timeout => 15 This basically says "add an app reference named 'cf' to the server and start a connection using the certification, and if it can't within 15 seconds, raise a `PYAPNS::TimeoutException` That's all it takes to get started. Of course, this can be done automatically by using PYAPNS::ClientConfiguration middleware. `PYAPNS::Client` is a singleton class that is configured using the class method `PYAPNS::Client#configure`. It is sensibly configured by default, but can be customized by specifying a hash See the docs on `PYAPNS::ClientConfiguration` for a list of available configuration parameters (some of these are important, and you can specify initial applications) to be configured by default. :section: Sending Notifications Once your client is configured, and application provisioned (again, these should be taken care of before you write notification code) you can begin sending notifications to users. If you're wondering how to acquire a notification token, you've come to the wrong place... I recommend using google. However, if you want to send hundreds of millions of notifications to users, here's how it's done, one at a time... The `PYAPNS::Client#notify` is a sort of polymorphic method which can notify any number of devices at a time. It's basic form is as follows: client.notify 'cf', 'long ass app token', {:aps=> {:alert => 'hello?'}} However, as stated before, it is sort of polymorphic: client.notify 'cf', ['token', 'token2', 'token3'], [alert, alert2, alert3] client.notify :app_id => 'cf', :tokens => 'mah token', :notifications => alertHash client.notify 'cf', 'token', PYAPNS::Notification('hello tits!') As you can see, the method accepts paralell arrays of tokens and notifications meaning any number of notifications can be sent at once. Hashes will be automatically converted to `PYAPNS::Notification` objects so they can be optimized for the wire (nil values removed, etc...), and you can pass `PYAPNS::Notification` objects directly if you wish. :section: Retrieving Feedback The APS service offers a feedback functionality that allows application servers to retrieve a list of device tokens it deems to be no longer in use, and the time it thinks they stopped being useful (the user uninstalled your app, better luck next time...) Sounds pretty straight forward, and it is. Apple recommends you do this at least once an hour. PYAPNS will return a list of 2-element lists with the date and the token: feedbacks = client.feedback 'cf' :section: Asynchronous Calls PYAPNS::Client will, by default, perform no funny stuff and operate entirely within the calling thread. This means that certain applications may hang when, say, sending a notification, if only for a fraction of a second. Obviously not a desirable trait, all `provision`, `feedback` and `notify` methods also take a block, which indicates to the method you want to call PYAPNS asynchronously, and it will be done so handily in another thread, calling back your block with a single argument when finished. Note that `notify` and `provision` return absolutely nothing (nil, for you rub--wait you are ruby developers!). It is probably wise to always use this form of operation so your calling thread is never blocked (especially important in UI-driven apps and asynchronous servers) Just pass a block to provision/notify/feedback like so: PYAPNS::Client.instance.feedback do |feedbacks| feedbacks.each { |f| trim_token f } end :section: PYAPNS::ClientConfiguration A middleware class to make `PYAPNS::Client` easy to use in web contexts Automates configuration of the client in Rack environments using a simple confiuration middleware. To use `PYAPNS::Client` in Rack environments with the least code possible `use PYAPNS::ClientConfiguration` (no, really, in some cases, that's all you need!) middleware with an optional hash specifying the client variables. Options are as follows: use PYAPNS::ClientConfiguration( :host => 'http://localhost/' :port => 7077, :initial => [{ :app_id => 'myapp', :cert => '/home/myuser/apps/myapp/cert.pem', :env => 'sandbox', :timeout => 15 }]) Where the configuration variables are defined: :host String the host where the server can be found :port Number the port to which the client should connect :initial Array OPTIONAL - an array of INITIAL hashes INITIAL HASHES: :app_id String the id used to send messages with this certification can be a totally arbitrary value :cert String a path to the certification or the certification file as a string :env String the environment to connect to apple with, always either 'sandbox' or 'production' :timoeut Number The timeout for the server to use when connecting to the apple servers :section: PYAPNS::Notification An APNS Notification You can construct notification objects ahead of time by using this class. However unnecessary, it allows you to programmatically generate a Notification like so: note = PYAPNS::Notification.new 'alert text', 9, 'flynn.caf', {:extra => 'guid'} -- or -- note = PYAPNS::Notification.new 'alert text' These can be passed to `PYAPNS::Client#notify` the same as hashes

pikuri-vectordb gives a pikuri-core agent a +vectordb_search+ tool over a local document corpus — agentic search, the agent decides when to retrieve. Ships a swappable backend (a pure-Ruby +Backend::InMemory+ for teaching, plus thin +Backend::Qdrant+ / +Backend::Chroma+ HTTP clients for persistence — Qdrant recommended), a chunker, an embedder wrapper over +RubyLLM.embed+, and an optional +Reranker::LlamaServer+ that speaks +/v1/rerank+ against a cross-encoder model. Text extraction goes through +Pikuri::FileType.read_as_text+ in pikuri-core, which handles plain text / Markdown / PDF; HTML extraction is a deferred follow-up. Hosts wire the feature via +c.add_extension Pikuri::VectorDb::Extension.new(...)+ inside the +Agent.new+ block — same opt-in shape as +pikuri-tasks+ / +pikuri-skills+. The bundled +Pikuri::VectorDb::LIBRARIAN+ persona is the privilege-separated sub-agent counterpart for hosts that want recall to flow through a child rather than the parent's context. Three model endpoints in the full setup — chat (via ruby_llm), an embedder (via +RubyLLM.embed+), and an optional reranker (HTTP +/v1/rerank+). A single +llama-server+ in router mode serves all three by default, loading each cached GGUF on demand; see the gem's README for details.

== README.md: #ScheduledResource This gem is for displaying how things are used over time -- a schedule for a set of "resources". You can configure the elements of the schedule and there are utilities and protocols to connect them: - Configuration (specification and management), - Query interfaces (a REST-like API and internal protocols to query the models), and - A basic Rails controller implementation. We have a way to configure the schedule, internal methods to generate the data, and a way to retrieve data from the client. However this gem is largely view-framework agnostic. We could use a variety of client-side packages or even more traditional Rails view templates to generate HTML. In any case, to get a good feel in a display like this we need some client-side code. The gem includes client-side modules to: - Manage &lt;b&gt;time and display geometries&lt;/b&gt; with "infinite" scroll along the time axis. - &lt;b&gt;Format display cells&lt;/b&gt; in ways specific to the resource models. - &lt;b&gt;Update text justification&lt;/b&gt; as the display is scrolled horizontally. ## Configuration A **scheduled resource** is something that can be used for one thing at a time. So if "Rocky &amp; Bullwinkle" is on channel 3 from 10am to 11am on Saturday, then 'channel 3' is the &lt;u&gt;resource&lt;/u&gt; and that showing of the episode is a &lt;u&gt;resource-use&lt;/u&gt; block. Resources and use-blocks are typically Rails models. Each resource and its use-blocks get one row in the display. That row has a label to the left with some timespan visible on the rest of the row. Something else you would expect see in a schedule would be headers and labels -- perhaps one row with the date and another row with the hour. Headers and labels also fit the model of resources and use-blocks. Basic timezone-aware classes (ZTime*) for those are included in this gem. ### Config File The schedule configuration comes from &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; which has three top-level sections: - ResourceKinds: A hash where the key is a Resource and the value is a UseBlock. (Both are class names), - Resources: A list where each item is a Resource Class followed by one or more resource ids, and - visibleTime: The visible timespan of the schedule in seconds. The example file &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; (installed when you run &lt;tt&gt;schedulize&lt;/tt&gt;) should be enough to display a two-row schedule with just the date above and the hour below. Of course you can monkey-patch or subclass these classes for your own needs. ### The schedule API The 'schedule' endpoint uses parameters &lt;tt&gt;t1&lt;/tt&gt; and &lt;tt&gt;t2&lt;/tt&gt; to specify a time interval for the request. A third parameter &lt;tt&gt;inc&lt;/tt&gt; allows an initial time window to be expanded without repeating blocks that span those boundaries. The time parameters _plus the configured resources_ define the data to be returned. ### More About Configuration Management The &lt;b&gt;ScheduledResource&lt;/b&gt; class manages resource and use-block class names, id's and labels for a schedule according to the configuration file. A ScheduledResource instance ties together: 1. A resource class (eg TvStation), 2. An id (a channel number in this example), and 3. Strings and other assets that will go into the DOM. The id is used to - select a resource _instance_ and - select instances of the _resource use block_ class (eg Program instances). The id _could_ be a database id but more often is something a little more suited to human use in the configuration. In any case it is used by model class method &lt;tt&gt;(resource_use_block_class).get_all_blocks()&lt;/tt&gt; to select the right use-blocks for the resource. A resource class name and id are are joined with a '_' to form a tag that also serves as an id for the DOM. Once the configuration yaml is loaded that data is maintained in the session structure. Of course having a single configuration file limits the application's usefulness. A more general approach would be to have a user model with login and configuration would be associated with the user. ## Installation Add this line to your application's Gemfile: ```ruby gem 'scheduled_resource' ``` And then execute: $ bundle Or install it yourself as: $ gem install scheduled_resource Then from your application's root execute: $ schedulize . This will install a few image placeholders, client-side modules and a stylesheet under &lt;tt&gt;vendor/assets&lt;/tt&gt;, an example configuration in &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; and an example controller in &lt;tt&gt;app/controllers/schedule_controller.rb&lt;/tt&gt;. Also, if you use $ bundle show scheduled_resource to locate the installed source you can browse example classes &lt;tt&gt;lib/z_time_*.rb&lt;/tt&gt; and the controller helper methods in &lt;tt&gt;lib/scheduled_resource/helper.rb&lt;/tt&gt; ## Testing This gem also provides for a basic test application using angularjs to display a minimal but functional schedule showing just the day and hour headers in two different timezones (US Pacific and Eastern). Proceed as follows, starting with a fresh Rails app: $ rails new test_sr As above, add the gem to the Gemfile, then $ cd test_sr $ bundle $ schedulize . Add lines such as these to &lt;tt&gt;config/routes.rb&lt;/tt&gt; get "/schedule/index" =&gt; "schedule#index" get "/schedule" =&gt; "schedule#schedule" Copy / merge these files from the gem source into the test app: $SR_SRC/app/views/layouts/application.html.erb $SR_SRC/app/views/schedule/index.html.erb $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js} and add &lt;tt&gt;//= require angular&lt;/tt&gt; to application.js just below the entries for &lt;tt&gt;jquery&lt;/tt&gt;. After you run the server and browse to http://0.0.0.0:3000/schedule/index you should see the four time-header rows specified by the sample config file. ## More Examples A better place to see the use of this gem is at [tv4](https://github.com/emeyekayee/tv4). Specifically, models &lt;tt&gt;app/models/event.rb&lt;/tt&gt; and &lt;tt&gt;app/models/station.rb&lt;/tt&gt; give better examples of implementing the ScheduledResource protocol and adapting to a db schema organized along somewhat different lines. ## Contributing 1. Fork it ( https://github.com/emeyekayee/scheduled_resource/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create a new Pull Request

No description provided.

No description provided.

No description provided.

No description provided.