[erlang-questions] Misultin EOL

Sat Feb 18 15:32:03 CET 2012

On Sat, Feb 18, 2012 at 2:19 PM, Tim Watson <watson.timothy@REDACTED> wrote:
> Hi Joe,
>
> I don't think you actually *need* a single scripting language to rule
> them all - nowhere else is this the case. Even in PHP there are
> templating and MVC frameworks, because fundamentally any large code
> base begins to fray at the seams in the face of 'scriptlet' code
> because it is
>
> (a) hard to isolate and therefore
> (b) hard to unit test
> (c) makes it 'easy' to do the wrong thing and mingle view generation
> and business logic, violating separation of concerns
>
> Personally I avoid things like this (PHP, JSP, ASP.NET, etc) like the
> plague, opting for templating tools like ErlyDTL or - more often than
> not - generating JSON/XML directly from the data model and
> streaming/serialising this back to the client.
>
> Other than that, I think a consistent interface between the different
> web servers is a bloody awesome step in the right direction. One thing
> that simple_bridge does well, in its philosophy at least, is to
> delegate to the underlying framework/server as much as possible, for
> things like identifying the mime type.
>
> Also I don't think that the implementation adapter should make choices
> about, for example, the JSON library used to do the
> serialisation/de-serialisation as in
> https://github.com/joearms/adapter_pattern/blob/master/mochiweb_adapter.erl#L48.
> I want to make my own choices when I'm building a web application,

I quite agree - this code was just a proof-of-concept not
frozen in stone.

As I see things there are two layers:

*inside* EHE I'd write code like this:

   <?e Value = SYS:get_key(Key),,, ?>

SYS:get_key(Val) would have a well defined type that never changes.

*outside* EHE I would define the semantics of get_key
so I could say If I wanted a memory resident db, persistent,
replicated, authenticated and so on.

> which include
>
> 1. what libraries I use to serialise/de-serialise data
> 2. what scripting and/or templating libraries I wish to use to
> generate content (if this approach is in play)
> 3. what response codes I want to send to the client
>
> So I fundamentally like where you're going with this, but it's a bit
> too high a level of abstraction for a 'generic web server api' and is
> making too many choices about these things (above). You need to offer
> lower level APIs that bridge the different web servers, as
> simple_bridge does. And on that note, if parameterised modules are
> going to be official and 'ok' soon, then simple_bridge is actually a
> long way ahead already, so maybe it's worth spending some time looking
> at it too.

I agree

/Joe

>
> On 18 February 2012 10:39, Joe Armstrong <erlang@REDACTED> wrote:
>> On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson <watson.timothy@REDACTED> wrote:
>>> On 17 February 2012 02:09, Steve Davis <steven.charles.davis@REDACTED>
>>> wrote:
>>>>
>>>> Hi Roberto,
>>>>
>>>> I'm a bit confused by this whole thread...
>>>>
>>>> I'm agreeing with Jesse that since Misultin is open source, it's not
>>>> really in your control to "stop development" if the interest is there
>>>> elsewhere to push it on?
>>>>
>>>> I'm also agreeing with Steve that I've not seen any demonstration that
>>>> yaws is somehow "lacking",
>>>>
>>>> For me, the last interesting benchmark that demonstrated anything
>>>> graspably real was "yaws vs apache".
>>>>
>>>> A really interesting benchmark for today's "web server" would be, if
>>>> someone were willing to engage in a non-trivial effort, to make a
>>>> comparison of a full-fledged web application with full session
>>>> management and routing capabilities. Note that this would truly test
>>>> the appropriateness of the server's http APIs as well as the base
>>>> response. That kind of benchmark, for me, would seem more appropriate
>>>> and useful according to the epoch.
>>>
>>>
>>> I've been suggesting this for some time now. I will make some time (somehow)
>>> to participate and I'm sure others will too.
>>
>> Yes ^ 100
>>
>> My *minimal* application does this for *every* GET request
>>
>>   1) Is there a cookie?
>>   2) If no cookie redirect to a set-cookie page
>>   3) if there is a cookie lookup value in database
>>   4) if no value in DB redirect to warning page
>>   5) if there is a value check if user is authenticated
>>   6) if not authenticated redirect to login page
>>   7) if authenticated lookup same basic data about user
>>       in DB
>>   8) send the result
>>
>> I suspect that impedance mismatches between the DB and
>> web server are the main sources of inefficiency
>>
>> The *interesting* benchmark is (say) the number of
>> page-views in a forum/second or the number of searches/second in a forum.
>>
>> We need to implement something like PHPBB and benchmark the number of
>> page-views/second
>> (Actually doing so would involve even more work before a page gets
>> sent - is the IP blacklisted? - has the user
>> posted more than N requests in the last T seconds -
>> is the user a spammer...)
>>
>> One thing that hinders this is the lack of a common language
>> to implement the web-part in. I have made a little language
>> EHE for this - which included in my adapter pattern - EHE is
>> easy to embed in *any* erlang web server - I have done so
>> for misultin, cowboy and mochiweb see
>>
>>   https://github.com/joearms/adapter_pattern
>>
>> The database for something like a web forum needs
>> investigation:
>>
>>
>> I want a data base with the following characteristics
>>
>>   - persistent
>>   - Key-Value
>>   - fast lookups
>>   - slow writes
>>   - full-text indexing of certain fields of certain key-types
>>
>> In a forum type application the read-write ratio is heavily
>> skewed in favor of reads - ie lots of reads very few writes.
>>
>> I am making a systems where all keys-values are stored in
>> an ets table.
>>
>> Reads go to the ets table, writes go to the ets table and are trailed
>> on disk. I guess I'd also like large values on disk
>> small values in the ets table. Oh and I'd also like full-text indexing
>> on tuple fields. ie if I say
>>
>>    store({post,12456},#item{user="joe", text="......"})
>>
>> Id like to automatically index the text field of the record.
>>
>> No erlang database I know of fits the bill - I don't want
>> an interface to mySQL or whatever since I suspect the impedance
>> mismatch between Erlang and the external
>> database would be terrible.
>>
>> Summary:
>>
>>    In addition to a fast web-server we need
>>
>>    - a fast persistent DB suitable for web applications
>>    - zero impedance mismatch between the DB and the web server
>>   - a language for the application (like PHP) (you'll find my
>>     EHE at https://github.com/joearms/adapter_pattern)
>>   - authentication
>>
>> All these bits have to fit together with bridges (adapters) so
>> we can change the database/server/authentication without
>> having to rewrite the entire application.
>>
>> Do this and *then* benchmark against PHPBB (or something)
>>
>> Cheers
>>
>> /Joe
>>>
>>>>
>>>>
>>>> Best regards,
>>>> /s
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>