[ANN] Seaside Installer

I created a package called "Seaside Installer" on SqueakMap. Loading
it will pull-in all the requirements to get a Seaside server running
in a fresh image. This installer could maybe later on replace the
official "Seaside" package on SqueakMap.

The load script is not very sophisticated for now, but it seems to
work well in the 3.8 image I tested. It loads Monticello, Kommanche,
Seaside and Scriptaculous.

Hope this makes you life also much easier ;-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Aug 7, 2006, at 3:17 PM, Lukas Renggli wrote:

> I created a package called "Seaside Installer" on SqueakMap. Loading
> it will pull-in all the requirements to get a Seaside server running
> in a fresh image. This installer could maybe later on replace the
> official "Seaside" package on SqueakMap.

So here's a challenge, related to the modularity thread on squeak-
dev.  What's the smallest image someone can produce which can fully  
use this installer?  Possibly by bringing in some extra required  
packages as well?

I've personally been more heartened by the somewhat ad-hoc shrinking  
work that Pavel, Steve Swerling, etc were doing (especially the  
series of 3.7 images like QuiteSmall.image) than by the more  
ambitious work being done at the SqF level.  In the long term, maybe  
the top-down modularize-everything work done in 3.9/3.10, and the  
bottom-up bootstrapping of Spoon will combine to give us something  
great.  In the meantime, I'd love to see a messy monolithic image  
with legacy bits, but that was as small as practically possible,  
which had roughly the same status for package releasers as  
3.7/3.8/3.9 do: that is, when releasing something like the Seaside  
Installer, we'd try to make sure it worked on that image as well.  I  
think it's important that the compatibility work go in that direction  
rather than the other way - such images have in the past shipped with  
modified versions of MC, Seaside, etc, but that's unsustainable; as a  
package maintainer, I'd rather be making sure that my own packages  
loaded into it cleanly than worrying about someone else keeping a  
branch.

If someone does release such an image - say, a 4MB 3.7-based image  
with bare-bones morphic, basic dev tools (browser/debugger/workspace/
inspector/transcript and nothing else), and enough network and file  
support to bring in the Seaside Installer - I'll commit to trying to  
keep any packages I have a hand in loadable on it going forward. FWIW.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 8/8/06, Avi Bryant <[hidden email]> wrote:
As someone who has ported Network, Comanche, Seaside, Scriptaculous
and ShoreComponents into my GUI-less image, I can say it was not
complicated. Scriptaculous and ShoreComponents was out-of-the-box. As
far as I remember, Comanche was also not problematic - only very few
modifications.

During porting of Seaside, the most problematic was absence of image
read-writers and some small issues like direct usage of Morphic
instead of UIManager (because of backward compatibility).

I think that we should split Seaside package into two or three
packages and create something like Seaside-Loader (see
ShoreComponents) to be able to strictly detach Squeak-dependent stuff.
That will make porting to VW (and other platforms) more easy and it
will also help us to load this package into the kernel image.

I may try to load the latest versions of this packages again and
report problematic code. Maybe Michel Bany should do the same.

The next step is to port MC for the kernel image but it needs to
enforce some refactorings in the Squeak (split ChangeSorter) and so
on...

-- Pavel
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Pavel Krivanek a écrit :

> I think that we should split Seaside package into two or three
> packages and create something like Seaside-Loader (see
> ShoreComponents) to be able to strictly detach Squeak-dependent stuff.
> That will make porting to VW (and other platforms) more easy and it
> will also help us to load this package into the kernel image.
>
Pavel,

Squeak-dependent stuff is already completely detached in Seaside.
The port to VW has become fairly easy with the 2.6b1 branch
and is about 99% automated. So I do not quite understand what you
have in mind with splitting Seaside into two or three packages.
Could you elaborate ? What would those packages be ?

> I may try to load the latest versions of this packages again and
> report problematic code. Maybe Michel Bany should do the same.

Here too, I do not understand. What exactly should I do ?

Cheers,
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 8/8/06, Michel Bany <[hidden email]> wrote:
Well

> So I do not quite understand what you
> have in mind with splitting Seaside into two or three packages.
> Could you elaborate ? What would those packages be ?
>
> > I may try to load the latest versions of this packages again and
> > report problematic code. Maybe Michel Bany should do the same.
>
> Here too, I do not understand. What exactly should I do ?

I was talking about splitting on the MC package level. See Wiki on
http://www.squeaksource.com/ShoreComponents.html for an example.

BTW we should create similar description for the Seaside repository.

Cheers,
 -- Pavel
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Wow, I just installed the installer and seaside looks even more
incredible then it did before.

There was one question that was asked on the "HREF considered harmful"
site, and Avi answered most of the questions but not this one which was
something I was conserned about myself.

One user asked about generating XML instead of HTML directly and then
doing XSLT conversions to get to the final output.  Avi had a good
answer for this, except for the situation where the client is actually a
phone or something like this.  How is the best way to handle the
situation when your client may be a normal web browser or it may end up
being a phone or something?

I had been writing, in my spare time, an apache module to convert XML
into some other form based on some rules (like cacoon, but without the
Java).  After seeing seaside, I have almost completely abandoned the
idea.  The only thing that keeps it in the back of my mind is this
question.

Thanks,
Jason

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von
Michel Bany
Gesendet: Dienstag, 8. August 2006 23:20
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: Re: [Seaside] [ANN] Seaside Installer

Pavel Krivanek a écrit :

> I think that we should split Seaside package into two or three
> packages and create something like Seaside-Loader (see
> ShoreComponents) to be able to strictly detach Squeak-dependent stuff.
> That will make porting to VW (and other platforms) more easy and it
> will also help us to load this package into the kernel image.
>
Pavel,

Squeak-dependent stuff is already completely detached in Seaside.
The port to VW has become fairly easy with the 2.6b1 branch
and is about 99% automated. So I do not quite understand what you
have in mind with splitting Seaside into two or three packages.
Could you elaborate ? What would those packages be ?

> I may try to load the latest versions of this packages again and
> report problematic code. Maybe Michel Bany should do the same.

Here too, I do not understand. What exactly should I do ?

Cheers,
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi

2006/8/9, Jason Johnson <[hidden email]>:
> Wow, I just installed the installer and seaside looks even more
> incredible then it did before.
>
> There was one question that was asked on the "HREF considered harmful"
> site, and Avi answered most of the questions but not this one which was
> something I was conserned about myself.
>
> One user asked about generating XML instead of HTML

Seaside produces (or should) XHTML which is XML.

> directly and then
> doing XSLT conversions to get to the final output.  Avi had a good
> answer for this, except for the situation where the client is actually a
> phone or something like this.  How is the best way to handle the
> situation when your client may be a normal web browser or it may end up
> being a phone or something?

I'd say it depends whether you want to do WML or HTML.

If you want to do HTML ideally a css for a different media type is enough.

For WML a way would be to make a WmlRenderer (look at WAHtmlCanvas and
WARenderCanvas and adopt it) and a WAWmlDocument similar
WAHtmlDocument. Then in your components override #rendererClass to
return your new renderer class.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von
Philippe Marschall
Gesendet: Donnerstag, 10. August 2006 10:13
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: Re: [Seaside] [ANN] Seaside Installer

Hi

2006/8/9, Jason Johnson <[hidden email]>:
> Wow, I just installed the installer and seaside looks even more
> incredible then it did before.
>
> There was one question that was asked on the "HREF considered harmful"
> site, and Avi answered most of the questions but not this one which
was
> something I was conserned about myself.
>
> One user asked about generating XML instead of HTML

Seaside produces (or should) XHTML which is XML.

> directly and then
> doing XSLT conversions to get to the final output.  Avi had a good
> answer for this, except for the situation where the client is actually
a
> phone or something like this.  How is the best way to handle the
> situation when your client may be a normal web browser or it may end
up
> being a phone or something?

I'd say it depends whether you want to do WML or HTML.

If you want to do HTML ideally a css for a different media type is
enough.

For WML a way would be to make a WmlRenderer (look at WAHtmlCanvas and
WARenderCanvas and adopt it) and a WAWmlDocument similar
WAHtmlDocument. Then in your components override #rendererClass to
return your new renderer class.
stuff. _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oh, sorry about that last send. *blush*.

Yes, I'm sold on the idea that CSS is the media translation for HTML
(certainly a much better (X)HTML media translation then XSLT).  The
concern was only over WML (or any other standard that might talk to my
browser in the near future).  I was curious what the seaside solution to
this would be.  The WML render class sounds great, so long as it gets
called when a WML client requests a page.  Or a WMLRenderOn: method
could work.  But is seaside planning on doing something for this or do I
have to put some logic in my system to check what kind of page got
requested?

Thanks very much for your reply,
Jason

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von
Philippe Marschall
Gesendet: Donnerstag, 10. August 2006 10:13
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: Re: [Seaside] [ANN] Seaside Installer

Hi

2006/8/9, Jason Johnson <[hidden email]>:
> Wow, I just installed the installer and seaside looks even more
> incredible then it did before.
>
> There was one question that was asked on the "HREF considered harmful"
> site, and Avi answered most of the questions but not this one which
was
> something I was conserned about myself.
>
> One user asked about generating XML instead of HTML

Seaside produces (or should) XHTML which is XML.

> directly and then
> doing XSLT conversions to get to the final output.  Avi had a good
> answer for this, except for the situation where the client is actually
a
> phone or something like this.  How is the best way to handle the
> situation when your client may be a normal web browser or it may end
up
> being a phone or something?

I'd say it depends whether you want to do WML or HTML.

If you want to do HTML ideally a css for a different media type is
enough.

For WML a way would be to make a WmlRenderer (look at WAHtmlCanvas and
WARenderCanvas and adopt it) and a WAWmlDocument similar
WAHtmlDocument. Then in your components override #rendererClass to
return your new renderer class.

> I had been writing, in my spare time, an apache module to convert XML
> into some other form based on some rules (like cacoon, but without the
> Java).  After seeing seaside, I have almost completely abandoned the
> idea.  The only thing that keeps it in the back of my mind is this
> question.
>
> Thanks,
> Jason
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I'd do completely different components for XHTML and WML and also
different seaside applications. That's certainly the easiest way. This
way you can also use the normal #renderContentOn: method, maybe rename
the argument from html to wml.

I know of no plans to integrate that into seaside. Mainly because
noone has yet had any use for it. But I doubt that a working
implementation that doesn't break exisiting code would be turned down.

It shouldn't be hard to produce a simple prototype. Do you have any
concrete plans for an application?

Philippe

2006/8/10, Jason Johnson <[hidden email]>: _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Not sure if this helps here, but method #rendererClass does not necessarily
need to return a constant. The class can be computed using data found
in the incoming request or even in the native request.

Computing the class of the output document based upon the request would
only need a small refactoring. In places where WAHtmlDocument is referenced,
the actual document class would be supplied by the session where
session subclasses would be able to compute the actual document class.

Michel.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yea, something like this is exactly what I was thinking of.  The session
subclasses could be overridden to allow arbitrary rendering classes to
be chosen based on a configurable set of rules (configurable from the
web site, to keep consistant with the rest of the design).  At that
point, you can do anything Cacoon, AxKit, etc. can do, but with no where
near the level of complexity those products have.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Bany,
Michel
Gesendet: Donnerstag, 10. August 2006 13:29
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: RE: [Seaside] [ANN] Seaside Installer

Not sure if this helps here, but method #rendererClass does not
necessarily
need to return a constant. The class can be computed using data found
in the incoming request or even in the native request.

Computing the class of the output document based upon the request would
only need a small refactoring. In places where WAHtmlDocument is
referenced,
the actual document class would be supplied by the session where
session subclasses would be able to compute the actual document class.

Michel.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Well, I have always avoided doing web site work because every tool I saw
was a nasty mix of HTML in code, template solution or something else
that just didn't seem right.  Not to mention, way too much work if you
don't want the cookie-cutter solution they have in their tutorial.

When I saw seaside, I told my brother-in-law I would be willing to take
over his comercial website after all.  I also intend to probe the market
in the area for how good the web page market is serviced.  I feel like a
technology like this would make me more mobile then any compitition on
any other solution out there.  Converting his website to this technology
should give me a good feeling for how correct I am with this.

But I really believe that at some point WML devices are going to start
gaining ground.  They wont eliminate the browser or anything, but get to
the point that saying your websites support phones on delivery will
decide if you get the contract or not.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von
Philippe Marschall
Gesendet: Donnerstag, 10. August 2006 13:00
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: Re: [Seaside] [ANN] Seaside Installer

I'd do completely different components for XHTML and WML and also
different seaside applications. That's certainly the easiest way. This
way you can also use the normal #renderContentOn: method, maybe rename
the argument from html to wml.

I know of no plans to integrate that into seaside. Mainly because
noone has yet had any use for it. But I doubt that a working
implementation that doesn't break exisiting code would be turned down.

It shouldn't be hard to produce a simple prototype. Do you have any
concrete plans for an application?

Philippe

2006/8/10, Jason Johnson <[hidden email]>:
> Oh, sorry about that last send. *blush*.
>
> Yes, I'm sold on the idea that CSS is the media translation for HTML
> (certainly a much better (X)HTML media translation then XSLT).  The
> concern was only over WML (or any other standard that might talk to my
> browser in the near future).  I was curious what the seaside solution
to
> this would be.  The WML render class sounds great, so long as it gets
> called when a WML client requests a page.  Or a WMLRenderOn: method
> could work.  But is seaside planning on doing something for this or do
I harmful" actually XML
> > into some other form based on some rules (like cacoon, but without
the _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Aug 10, 2006, at 7:24 AM, Jason Johnson wrote:
>
> But I really believe that at some point WML devices are going to start
> gaining ground.  They wont eliminate the browser or anything, but  
> get to
> the point that saying your websites support phones on delivery will
> decide if you get the contract or not.

How many WML-only phones are out there anymore?  Most of the devices  
that I see people use support HTML (and in fact my phone, the  
Sidekick II, doesn't even bother with WML support).  I think the idea  
of a parallel web just for mobile devices was always a non-starter.  
The best way to support mobile devices, IMO, is to provide a no-
frills, no-ajax version of your site with very simple markup, few  
images, etc.  WML is a waste of time.

It's possible I'm coming from a biased perspective, though - this is  
the kind of thing that can be very regional.  Anyone out there seeing  
heavy WML use?

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Well, that is certainly a good point and you have more experience doing
web sites then I do I'm sure.  But if you are 100% right and all mobiles
will use straight HTML, we still have the situation that those devices
have to get a different view of the same page.  In other words, the
final HTML, etc. a client gets depends on what type of client they are.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Avi
Bryant
Gesendet: Donnerstag, 10. August 2006 19:42
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: [Seaside] WML (was Re: Seaside Installer)


On Aug 10, 2006, at 7:24 AM, Jason Johnson wrote:
>
> But I really believe that at some point WML devices are going to start
> gaining ground.  They wont eliminate the browser or anything, but  
> get to
> the point that saying your websites support phones on delivery will
> decide if you get the contract or not.

How many WML-only phones are out there anymore?  Most of the devices  
that I see people use support HTML (and in fact my phone, the  
Sidekick II, doesn't even bother with WML support).  I think the idea  
of a parallel web just for mobile devices was always a non-starter.  
The best way to support mobile devices, IMO, is to provide a no-
frills, no-ajax version of your site with very simple markup, few  
images, etc.  WML is a waste of time.

It's possible I'm coming from a biased perspective, though - this is  
the kind of thing that can be very regional.  Anyone out there seeing  
heavy WML use?

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Typically though you would be rendering not just a different look, but a
very different workflow altogether given the harsh limitations of a smaller
screen. We've looked at our future plans as far as our web portal goes and
it was pretty clear the "mobile" version is really a different application
running off the same backend, so in all likelihood we'd just forward the
mobile clients over to a different URL.

Just my $0.02,

But I also think the nature of your original question/concern has been
distorted a bit, could you clarify what it is we're all talking about here?
;)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jason
Johnson
Sent: Thursday, August 10, 2006 10:48 AM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: AW: [Seaside] WML (was Re: Seaside Installer)

Well, that is certainly a good point and you have more experience doing
web sites then I do I'm sure.  But if you are 100% right and all mobiles
will use straight HTML, we still have the situation that those devices
have to get a different view of the same page.  In other words, the
final HTML, etc. a client gets depends on what type of client they are.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Avi
Bryant
Gesendet: Donnerstag, 10. August 2006 19:42
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: [Seaside] WML (was Re: Seaside Installer)


On Aug 10, 2006, at 7:24 AM, Jason Johnson wrote:
>
> But I really believe that at some point WML devices are going to start
> gaining ground.  They wont eliminate the browser or anything, but  
> get to
> the point that saying your websites support phones on delivery will
> decide if you get the contract or not.

How many WML-only phones are out there anymore?  Most of the devices  
that I see people use support HTML (and in fact my phone, the  
Sidekick II, doesn't even bother with WML support).  I think the idea  
of a parallel web just for mobile devices was always a non-starter.  
The best way to support mobile devices, IMO, is to provide a no-
frills, no-ajax version of your site with very simple markup, few  
images, etc.  WML is a waste of time.

It's possible I'm coming from a biased perspective, though - this is  
the kind of thing that can be very regional.  Anyone out there seeing  
heavy WML use?

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> It's possible I'm coming from a biased perspective, though - this is  
> the kind of thing that can be very regional.  Anyone out there seeing  
> heavy WML use?

Well today I demoed a seaside app to two large investors which uses WML.
Acually I have a 'Seasbreeze' (corny, I know) extension to Seaside if anyone cares.

Let me know

Brent
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

No, I don't think it has been distorted.  Just "fleshed out" a bit. :)
Your observation about it being basically a different app is certainly
valid.

My comments come from looking into building a web site and going through
many of the tools.  Some systems out there are very good recieving a
client request and dispatching it to the appropriate place based on
various rules (e.g.  Is this a mozilla client, is it an IE client with a
set of bugs we have to adjust for, is it a mobile device).  Of course
the rest of the technologies with these systems were not so good.  But
I'm all for lifting the good ideas from other products and integrating
them into the right solution, and this seemed like low hanging fruit for
Seaside.

But if it doesn't need it then it doesn't need it.  If the over all
consensus is that this is just one of those theoretical needs that never
actually comes up in practice then I will forget about it and move on.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Boris
Popov
Gesendet: Donnerstag, 10. August 2006 19:58
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: RE: [Seaside] WML (was Re: Seaside Installer)

Typically though you would be rendering not just a different look, but a
very different workflow altogether given the harsh limitations of a
smaller
screen. We've looked at our future plans as far as our web portal goes
and
it was pretty clear the "mobile" version is really a different
application
running off the same backend, so in all likelihood we'd just forward the
mobile clients over to a different URL.

Just my $0.02,

But I also think the nature of your original question/concern has been
distorted a bit, could you clarify what it is we're all talking about
here?
;)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jason
Johnson
Sent: Thursday, August 10, 2006 10:48 AM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: AW: [Seaside] WML (was Re: Seaside Installer)

Well, that is certainly a good point and you have more experience doing
web sites then I do I'm sure.  But if you are 100% right and all mobiles
will use straight HTML, we still have the situation that those devices
have to get a different view of the same page.  In other words, the
final HTML, etc. a client gets depends on what type of client they are.

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Avi
Bryant
Gesendet: Donnerstag, 10. August 2006 19:42
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: [Seaside] WML (was Re: Seaside Installer)


On Aug 10, 2006, at 7:24 AM, Jason Johnson wrote:
>
> But I really believe that at some point WML devices are going to start
> gaining ground.  They wont eliminate the browser or anything, but  
> get to
> the point that saying your websites support phones on delivery will
> decide if you get the contract or not.

How many WML-only phones are out there anymore?  Most of the devices  
that I see people use support HTML (and in fact my phone, the  
Sidekick II, doesn't even bother with WML support).  I think the idea  
of a parallel web just for mobile devices was always a non-starter.  
The best way to support mobile devices, IMO, is to provide a no-
frills, no-ajax version of your site with very simple markup, few  
images, etc.  WML is a waste of time.

It's possible I'm coming from a biased perspective, though - this is  
the kind of thing that can be very regional.  Anyone out there seeing  
heavy WML use?

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside