Discussion:
Xaraya Aruba 1.2 roadmap open for comments
Marty Vance
2009-03-30 03:58:42 UTC
Permalink
The PMC, as Aruba (1x) Team Lead, has published a tentative roadmap (
http://www.xaraya.com/index.php/xarpages/development/aruba_roadmap )for
the next Aruba release, 1.2.

Please refer to the Terminology (
http://www.xaraya.com/index.php/xarpages/development/terminology ) and
Development Cycle (
http://www.xaraya.com/index.php/xarpages/development/cycle ) pages in
the new Development section (
http://www.xaraya.com/index.php/xarpages/development ). Xaraya Aruba 1.2
is a Minor Release.

This roadmap describes what we feel should be done in 1.2, and we are
now seeking feedback and suggestions from the community for additional
items.

Please reply here with detailed proposals, or links to specific bugs. If
there is not a bug already in Bugzilla which describes an issue,
enhancement, or new feature you wish to see added, please file a file a
new bug targeted at version 1.2, at http://bugs.xaraya.com/enter_bug.cgi

The discussion period for this roadmap will be open until Midnight GMT
on 14 April 2008. At that time, the roadmap will be updated to reflect
the results of the dicussion period, then locked.

Let's make 1.2 the best Xaraya release yet.

See: http://www.xaraya.com/index.php/xarbb/topic/3378
Marty Vance
2009-03-30 04:29:28 UTC
Permalink
Post by Marty Vance
The discussion period for this roadmap will be open until Midnight GMT
on 14 April 2008. At that time, the roadmap will be updated to reflect
the results of the dicussion period, then locked.
Oops, that date should be 14 April 2009.
Marcel van der Boom
2009-03-30 12:35:35 UTC
Permalink
I have a couple of questions/remarks:

- general: i think i dont understand the relation between the name
'aruba', the 'minor version' and the 'roadmap'. I am used to a roadmap
which transcends 'versions', 'releases' and 'line names'. Am I to
interpret this roadmap as a task list for minor version 1.2 release
completion, part of the 1.x series which are all called 'aruba'? [the
page says "Xaraya Aruba 1.3.0" for example]

- M2 is mentioned twice, typo?

- given the icon handling proposal, perhaps an RFC would be
appropriate and determine how we would do this? The 2.x core could use
a similar technique, I think it would be smart to create something
which is applicable to both series.

- the roadmap is somewhat 'thin' on functionality and 'thick' on
presentation, which is fine obviously,but what are the functionality
priorities, perhaps one abstraction level higher than the roadmap shown?

- what are the plans with respect to the two series of development we
have? Are we keeping the two separate?

- is this list in sync with the roadmap? ⇢ http://www.xaraya.com/todo
[open bugs to target 1.2]

More a remark than a question, but given the scenarios that went into
2.x starting with 1.x:
- db middle layer (creole)
- exceptions (M7 ?)
- object rewrite of core API
- DD overhaul
- php5only constructs
- performance improvements
- blocklayout corrections
- compiler rewrite
- mls changes
- xd⇢xt changes (M2 ?)
- db modelrefactoring
- db transaction support
- directory layout changes in preparation for deployment/multisite
- 
 (probably a bit more, but the above is by head)

Some, or maybe many, could be backported to 1.x. Apart from the PHP4
limitation which is now gone(?) I've always been hesitant to do that
because it means duplication of work for the most part, but seeing 1.x
and 2.x grow further apart over time does no good to anyone (community
wise).

If the wish is to *NOT* backport many of these scenarios to 1.x, it
may be better to formally split 2.x off perhaps?

If we *DO* want to backport most of what is there, why not start with
those? They're easy wins and have seen a good portion of testing
already.

marcel
Post by Marty Vance
The PMC, as Aruba (1x) Team Lead, has published a tentative roadmap (
http://www.xaraya.com/index.php/xarpages/development/
aruba_roadmap )for
the next Aruba release, 1.2.
Please refer to the Terminology (
http://www.xaraya.com/index.php/xarpages/development/terminology ) and
Development Cycle (
http://www.xaraya.com/index.php/xarpages/development/cycle ) pages in
the new Development section (
http://www.xaraya.com/index.php/xarpages/development ). Xaraya Aruba 1.2
is a Minor Release.
This roadmap describes what we feel should be done in 1.2, and we are
now seeking feedback and suggestions from the community for additional
items.
Please reply here with detailed proposals, or links to specific bugs. If
there is not a bug already in Bugzilla which describes an issue,
enhancement, or new feature you wish to see added, please file a file a
new bug targeted at version 1.2, at http://bugs.xaraya.com/enter_bug.cgi
The discussion period for this roadmap will be open until Midnight GMT
on 14 April 2008. At that time, the roadmap will be updated to reflect
the results of the dicussion period, then locked.
--
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV -- http://www.hsdev.com
So! web applications -- http://make-it-so.info
Cobra Replica build -- http://cobra.mrblog.nl
Marty Vance
2009-03-30 20:52:41 UTC
Permalink
Post by Marcel van der Boom
- general: i think i dont understand the relation between the name
'aruba', the 'minor version' and the 'roadmap'. I am used to a roadmap
which transcends 'versions', 'releases' and 'line names'. Am I to
interpret this roadmap as a task list for minor version 1.2 release
completion, part of the 1.x series which are all called 'aruba'? [the
page says "Xaraya Aruba 1.3.0" for example]
1x == Aruba
2x == Jamaica

These roadmaps will evolve over time. Toward the end of the development
cycle for 1.2, the 1.3 planning will begin.
Post by Marcel van der Boom
- M2 is mentioned twice, typo?
Yes, fixed.
Post by Marcel van der Boom
- given the icon handling proposal, perhaps an RFC would be appropriate
and determine how we would do this? The 2.x core could use a similar
technique, I think it would be smart to create something which is
applicable to both series.
When an RFC or something similar is produced, for icons or anything
else, it will be considered. "I want to use sprites instead of separate
files" is nowhere near detailed enough to warrant consideration.

However, our historical RFC format may be thrown out in favor of some
other means which is easier to work with.
Post by Marcel van der Boom
- the roadmap is somewhat 'thin' on functionality and 'thick' on
presentation, which is fine obviously,but what are the functionality
priorities, perhaps one abstraction level higher than the roadmap shown?
IIRC, 1.1 was thinner than this in general. Functionality is no longer
defined only by what happens in PHP on the back end.

We will assess all the input at the end of the discussion period. What
can be planned out and get done in a timely fashion will be included.
There is no clear timeline for a final release of Jamaica yet, so Aruba
will continue until Jamaica gets closer. We know jamaica is coming, so
we're not going to make far reaching plans for Aruba.

There is no higher level roadmap.

M2 (icons) is represented in the iconify scenario, and I have mostly
completed M1 (installer rebrand) on top of that.
Post by Marcel van der Boom
- what are the plans with respect to the two series of development we
have? Are we keeping the two separate?
They have always been separate, why change that now?
Post by Marcel van der Boom
- is this list in sync with the roadmap? ⇢ http://www.xaraya.com/todo
[open bugs to target 1.2]
Where did that list come from? Are you nominating those bugs for 1.2?
Post by Marcel van der Boom
More a remark than a question, but given the scenarios that went into
- db middle layer (creole)
- exceptions (M7 ?)
- object rewrite of core API
- DD overhaul
- php5only constructs
- performance improvements
- blocklayout corrections
- compiler rewrite
- mls changes
- xd⇢xt changes (M2 ?)
- db modelrefactoring
- db transaction support
- directory layout changes in preparation for deployment/multisite
- … (probably a bit more, but the above is by head)
Some, or maybe many, could be backported to 1.x. Apart from the PHP4
limitation which is now gone(?) I've always been hesitant to do that
because it means duplication of work for the most part, but seeing 1.x
and 2.x grow further apart over time does no good to anyone (community
wise).
The intent is to move 1x forward from what it is now, because 1x and 2x
are too different now to backport some, if any, 2x changes. I'm not
interested in duplucation of work unless it is new work that can be
applied to both lines.

The PHP4 limitation will remain until there are people willing to comb
through everything and fully remove it.
Post by Marcel van der Boom
If the wish is to *NOT* backport many of these scenarios to 1.x, it may
be better to formally split 2.x off perhaps?
IMO, 2x was formally split off when it began. Based on that, it's too
late (and not worth the effort) to go back and incrementally transform
1x into 2x. 1x will continue on its path parallel to 2x on its path,
until 2x is ready for a formal 2.0.0 release.
Post by Marcel van der Boom
If we *DO* want to backport most of what is there, why not start with
those? They're easy wins and have seen a good portion of testing already.
If any of those get backported, only the easiest wins will happen, such
as xd -> xt.

The people who are going to do the work get to define what work gets
done and when.
Post by Marcel van der Boom
marcel
Post by Marty Vance
The PMC, as Aruba (1x) Team Lead, has published a tentative roadmap (
http://www.xaraya.com/index.php/xarpages/development/ aruba_roadmap )for
the next Aruba release, 1.2.
Please refer to the Terminology (
http://www.xaraya.com/index.php/xarpages/development/terminology ) and
Development Cycle (
http://www.xaraya.com/index.php/xarpages/development/cycle ) pages in
the new Development section (
http://www.xaraya.com/index.php/xarpages/development ). Xaraya Aruba 1.2
is a Minor Release.
This roadmap describes what we feel should be done in 1.2, and we are
now seeking feedback and suggestions from the community for additional
items.
Please reply here with detailed proposals, or links to specific bugs. If
there is not a bug already in Bugzilla which describes an issue,
enhancement, or new feature you wish to see added, please file a file a
new bug targeted at version 1.2, at http://bugs.xaraya.com/enter_bug.cgi
The discussion period for this roadmap will be open until Midnight GMT
on 14 April 2008. At that time, the roadmap will be updated to reflect
the results of the dicussion period, then locked.
Marcel van der Boom
2009-03-30 21:26:55 UTC
Permalink
Post by Marty Vance
Post by Marcel van der Boom
- is this list in sync with the roadmap? ⇢ http://www.xaraya.com/
todo
[open bugs to target 1.2]
Where did that list come from? Are you nominating those bugs for 1.2?
Nope, that list has been generated from bugzilla, i just changed 1.1.0
to 1.2 basically in the script doing that
--
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV -- http://www.hsdev.com
So! web applications -- http://make-it-so.info
Cobra Replica build -- http://cobra.mrblog.nl
Petr Vorel
2009-03-31 21:45:49 UTC
Permalink
Hi all,

my FR would be
1) to define encoding for database connection - not only because MySQL has still stupidly default encoding as Latin1.
There are several resources about this problem in Xaraya (the best link I just can't find)
http://bugs.xaraya.com/show_bug.cgi?id=2758
http://bugs.xaraya.com/show_bug.cgi?id=6109
http://www.xaraya.com/index.php/xarbb/topic/2589

Basically there would be parametter defined in var/config.system.php:
$systemConfiguration['DB.Encoding'] = 'encoding_name';
which would be used in query:
"SET NAMES encoding_name" (don't know if there is better way how to accomplish it with adodb).
in function &xarDBNewConn($args = NULL) defined in includes/xarDB.php

Next step would be adjusting installer to allow setting this parametter.

I'd skip collation settings as it seems to be more difficult (according to Dracos adodb does NOT support collation).
This would be at least for mysql and postgresql. I have no idea how is encoding used in sqlite.



2) only ASCII characters in Short-URLs
In talks about ASCII characters in Short-URLs in articles I've heard that is has to be defined generally for xaraya.

So, it would be good to have only ASCII characters in Short-URLs.
E.g. In Czech "žlutě" would be "zlute", but "zlute" would be also "zlute".
So is that possible? I mean decoding from short url wouldn't be one way :-( ("zlute" could be "zlute" or "žlutě".) If not, it should be somehow achieved avoiding NON-ASCII characters in Short-URLs.

There is a bug about this issue:
http://bugs.xaraya.com/show_bug.cgi?id=3138



3) test more with PostgreSQL (several problems with MySQL put me off from ideas to switch from MySQL to my favourite PostgreSQL).


Pev
Marty Vance
2009-03-31 22:39:24 UTC
Permalink
Post by Petr Vorel
Hi all,
my FR would be 1) to define encoding for database connection - not only
because MySQL has still stupidly default encoding as Latin1.
There are several resources about this problem in Xaraya (the best link I just can't find)
http://bugs.xaraya.com/show_bug.cgi?id=2758
http://bugs.xaraya.com/show_bug.cgi?id=6109
http://www.xaraya.com/index.php/xarbb/topic/2589
$systemConfiguration['DB.Encoding'] = 'encoding_name';
"SET NAMES encoding_name" (don't know if there is better way how to
accomplish it with adodb).
in function &xarDBNewConn($args = NULL) defined in includes/xarDB.php
Next step would be adjusting installer to allow setting this parametter.
MySQL's default charset settings are one of the most ludicrous things
I've ever seen.

ADOdb has a SetCharSet method in both the mysqli, oci8 and postgre7 drivers.

While we're at it, we're running 4.93, should upgrade to 4.990.
Post by Petr Vorel
I'd skip collation settings as it seems to be more difficult (according
to Dracos adodb does NOT support collation).
This would be at least for mysql and postgresql. I have no idea how is
encoding used in sqlite.
SET NAMES takes care of several things, details in this thread in the
adoDB forums: http://phplens.com/lens/lensforum/msgs.php?id=12467&x=1

Collation has to do (mostly, I think) with how MySQL orders records
during sort/order by operations involving varchar and text fields. If
the charset settings are in sync, I think collation takes care of itself
for the most part (which may be why adoDB doesn't support setting it).

Speaking of the installer, I've been thinking about expanded db-specific
settings for a while. I doubt it would be hard to do.

I'm also considering creating an installer theme so that Xaraya_Classic
doesn't need to be kept around all the time. One page template, one
stylesheet, and images necessary to dress up the output. I already have
a hack in Xaraya_Classic/pages/installer.xt that can detect if the
current script is install.php or upgrade.php.
Post by Petr Vorel
2) only ASCII characters in Short-URLs
In talks about ASCII characters in Short-URLs in articles I've heard
that is has to be defined generally for xaraya.
So, it would be good to have only ASCII characters in Short-URLs.
E.g. In Czech "žlutě" would be "zlute", but "zlute" would be also "zlute".
So is that possible? I mean decoding from short url wouldn't be one way
:-( ("zlute" could be "zlute" or "žlutě".) If not, it should be somehow
achieved avoiding NON-ASCII characters in Short-URLs.
http://bugs.xaraya.com/show_bug.cgi?id=3138
The url encoding process would need to differentiate the "zlute" and
"žlutě" urls somehow when they are both converted to "zlute": "zlute"
and "zlute2" or something.
Post by Petr Vorel
3) test more with PostgreSQL (several problems with MySQL put me off
from ideas to switch from MySQL to my favourite PostgreSQL).
Few of us know/use Postgres, so whatever testing it gets can probably go
a long way.
Post by Petr Vorel
Pev
Petr Vorel
2009-04-01 05:20:32 UTC
Permalink
Post by Marty Vance
MySQL's default charset settings are one of the most ludicrous things
I've ever seen.
ADOdb has a SetCharSet method in both the mysqli, oci8 and postgre7 drivers.
While we're at it, we're running 4.93, should upgrade to 4.990.
Btw according to http://phplens.com/adodb/change.log.html it's version 4.990 from 11 Jul 2008, but on http://sourceforge.net/project/showfiles.php?group_id=42718&package_id=34890 is a version 4.991 as a last version supporting php 4 (http://sourceforge.net/project/shownotes.php?release_id=636415&group_id=42718)
Post by Marty Vance
Post by Petr Vorel
I'd skip collation settings as it seems to be more difficult
(according to Dracos adodb does NOT support collation).
This would be at least for mysql and postgresql. I have no idea how is
encoding used in sqlite.
SET NAMES takes care of several things, details in this thread in the
adoDB forums: http://phplens.com/lens/lensforum/msgs.php?id=12467&x=1
Collation has to do (mostly, I think) with how MySQL orders records
during sort/order by operations involving varchar and text fields. If
the charset settings are in sync, I think collation takes care of itself
for the most part (which may be why adoDB doesn't support setting it).
Speaking of the installer, I've been thinking about expanded db-specific
settings for a while. I doubt it would be hard to do.
Great :-).
Post by Marty Vance
I'm also considering creating an installer theme so that Xaraya_Classic
doesn't need to be kept around all the time. One page template, one
stylesheet, and images necessary to dress up the output. I already have
a hack in Xaraya_Classic/pages/installer.xt that can detect if the
current script is install.php or upgrade.php.
I'd agree to dismiss dependency of Xaraya_Classic during upgrade (and install).
Post by Marty Vance
Post by Petr Vorel
2) only ASCII characters in Short-URLs
In talks about ASCII characters in Short-URLs in articles I've heard
that is has to be defined generally for xaraya.
So, it would be good to have only ASCII characters in Short-URLs.
E.g. In Czech "žlutě" would be "zlute", but "zlute" would be also "zlute".
So is that possible? I mean decoding from short url wouldn't be one
way :-( ("zlute" could be "zlute" or "žlutě".) If not, it should be
somehow achieved avoiding NON-ASCII characters in Short-URLs.
http://bugs.xaraya.com/show_bug.cgi?id=3138
The url encoding process would need to differentiate the "zlute" and
"žlutě" urls somehow when they are both converted to "zlute": "zlute"
and "zlute2" or something.
I have no idea how :-(. Is there any possible way?
I case we wouldn't be able to differentiate them I'd be for adjusting just articles as I know about this use just in particular case of articles with short urls enabled. In this case "žlutě" and "zlute" would be considered as a same titles (there is a setting howto handle the same titles).
There could be on way map for languages, e.g.
cs_CZ.UTF-8:
'ž' => 'z'
'š' => 's'
'ě' => 'e'
...
Post by Marty Vance
Post by Petr Vorel
3) test more with PostgreSQL (several problems with MySQL put me off
from ideas to switch from MySQL to my favourite PostgreSQL).
Few of us know/use Postgres, so whatever testing it gets can probably go
a long way.
Post by Petr Vorel
Pev
Loading...