Reducing resource framework just to SwazooSite?

> I'm just thinking about simplifying Swazoo resource framework to be
> easier to understand and easier to debug, specially easier to trace a
> request through the resources.
>
> That's why I'm thinking about to reduce a resource framework to just one
> resource: a SwazooSite. AFAIK all uses of Swazoo so far don't really use
> a resource framework beyond a SwazooSite, so continuing with a full
> support of hierarchical resources is just not practical and it ads
> heavily to the complexity of Swazoo.
>
> What we can also do is to make a subclass of SwazooSite for static file
> serving and another one for Hello world example.
>
> What do you think, is reducing resources just to the Site good idea?

> Dear all,
>
> I'm just thinking about simplifying Swazoo resource framework to be
> easier to understand and easier to debug, specially easier to trace a
> request through the resources.
>
> That's why I'm thinking about to reduce a resource framework to just one
> resource: a SwazooSite. AFAIK all uses of Swazoo so far don't really use
> a resource framework beyond a SwazooSite, so continuing with a full
> support of hierarchical resources is just not practical and it ads
> heavily to the complexity of Swazoo.
>
> What we can also do is to make a subclass of SwazooSite for static file
> serving and another one for Hello world example.
>
> What do you think, is reducing resources just to the Site good idea?

> On 10/20/2010 10:10 AM, Janko Mivšek wrote:
>> I'm just thinking about simplifying Swazoo resource framework to be
>> easier to understand and easier to debug, specially easier to trace a
>> request through the resources.
>>
>> That's why I'm thinking about to reduce a resource framework to just one
>> resource: a SwazooSite. AFAIK all uses of Swazoo so far don't really use
>> a resource framework beyond a SwazooSite, so continuing with a full
>> support of hierarchical resources is just not practical and it ads
>> heavily to the complexity of Swazoo.
>>
>> What we can also do is to make a subclass of SwazooSite for static file
>> serving and another one for Hello world example.
>>
>> What do you think, is reducing resources just to the Site good idea?
>
> I think so, the major frameworks (Seaside, Aida, Iliad) all have their
> own path resolution but use just a SwazooSite.  SwazooSite would then be
> the superclass and have #answerTo: as an abstract metod.
>
> However, I have some changes pending to Swazoo and I would like to see
> those merged first to avoid merge headaches:
>
> 1) Move request reading and response printing to separate classes,
> allowing an HTTPServer to specify custom classes (for SCGI support,
> written by Nicolas Petton).
>
> 2) Similarly, allow an HTTPServer to specify a custom SwazooSocket class
> (for FastCGI support).
>
> 3) To remove SwazooBuffer and handle buffering directly into
> SwazooStream.  This improves performance (I think it was 6x on Hello World).
>
>
> I also have a simple refactoring of matching to remove #siteMatch: and
> #stringMatch:.  So, the matching of resources is done entirely by the
> resources themselves.  I did this for SCGI too, but it is something that
> probably you'd do anyway while removing double-dispatch on resource types.
>
> Nico has been using the first three patches in production for a while.
> For them I think I even have Squeak changeset files somewhere.
>
> Paolo
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/swazoo-devel
>

> On 10/24/2010 04:16 PM, Paolo Bonzini wrote:
>> On 10/21/2010 03:43 PM, Janko Mivšek wrote:
>>> Hi Paolo,
>>>
>>> I agree, let we integrate your patches on that occasion too. Can you
>>> provide me the Squeak or VW sources/changesets for it? I'd update VW
>>> Swazoo first, because I'm using it daily, then other ports will come.
>>> Let we say this will be Swazoo 2.3.
>>
>> Here they are. They're in Squeak format, I think it should not be hard
>> to import them into VW.
>
> Ok, I regenerated all of them again and tested them one by one.
>
> Swazoo-abstract-print-read.1.cs
>     Move request reading and response printing to separate classes,
>     allowing HTTPServer to specify custom classes
>
> Swazoo-abstractions.2.cs
>     Actually introduce an abstract HTTPServer class that can specify
>     a custom reader/printer, and an abstract HTTPSocket that can be
>     used in the future for FastCGI.
>
> Swazoo-buffer.1.cs
>     Remove SwazooBuffer and handle buffering directly in SwazooStream.
>     Also improves portability.
>
> Swazoo-refactor-matching.1.cs
>     core changes for SCGI support:
>     - do not create a default SiteIdentifier (use lazy initialization)
>     - add defaults for host and IP (see also the change to
>     URIResolutionTest>>#testSiteAnswer tests)
>     - add caching to HTTPRequest>>#host
>     - complete resolution double-dispatch and let SiteIdentifiers match
>     requests directly (without creating a temporary identifier)
>
> Swazoo-scgi.1.cs
>     add SCGI support (from Nicolas Petton)
>
> To test SCGI:
>
> 1) in #prepareDemoSite change
>
>     site host: '*' ip: '*' port: 8888
>
> to
>
>     site scgiPort: 8888.
>
> 2) stop Swazoo and send #demoStart.
>
> 3) type the following in a shell:
>
>    echo '50:REQUEST_METHOD@GET@REQUEST_URI@/@CONTENT_LENGTH@0@,' | \
>       tr @ \\0 | nc localhost 8888
>
> You should get back a reply that is basically the same as HTTP except
> it starts with "Status: 200 OK".
>
> I look forward to see these merged! :)
>
> Paolo
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
>
>
>
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/swazoo-devel